Hola! Cuando arranca la consola, nos tira una linea que nos llamó la atención, no entendemos mucho que quiere decir. Alguien tiene una idea de que esta diciendo? Además por momentos cambia a lo que hace referencia y eso nos deconcierta más.
Adjunto imagen. Saludos.
Anaclara:
se puede ignorar ese mensaje, no hay problema.
Para el que tenga curiosidad, el mensaje lo da el gdb al conectarse al sistema destino con el comando "target extended-remote localhost:8000" que se le da al gdb cuando se lo invoca desde el notepad++. El mensaje indica qué estaba haciendo el sistema destino cuando se realizó la conexión.
Cuado te conectás al sistema que corre en la placa DE0, normalmente estaba ejecutando parte del código del monitor en la dirección 0x0206. Cuando se conecta con el sistema en el simulador QEMU normalmente es la dirección 0x0000. En los dos casos pone "in ??" porque el gdb no tiene información sobre cuál es el programa que se estaba ejecutando.
Saludos,
julio
Julio, corriendo en el GDB la preueba de hexa7seg. Luego de ejecutar la subrutina cuando va a ejecutar RET nos vuelve a dar el error in?? con 0x0206, no se si es porque estamos usando mal algo, pero no entiendo mucho porque me salta el error en la mitad de todo.
Muchas gracias.
mmm, eso suele pasar cuando por algún motivo (stack desalineado, que entren a ejecutar una subrutina sin llamarla y entonces RET retorna a cualquier lado, que entren a ejecutar variables o la tabla) la ejecución se va al diablo, sigue ejecutando todo lo que hay en RAM y termina volviendo a entrar en el código del monitor que está cargado en ROM a partir de la dirección 0x0000.
Revisen que el punto de entrada al programa quede en 0xb000, revisen la tabla de símbolos que se despliega al terminar la compilación y vean si todas las etiquetas que definieron quedan en lugares razonables, ...
Revisamos bien lo que hace al llamar a la subrutina y al llamarla (esta en un archivo aparte y el archivo preincipal tiene un .include) el PC contiene las direcciones de las instrucciones que se estan ejecutando pero cuando se ejecuta RET el mismo no vuelve al valor que debería sino que a 0x206 por lo que no ejecuta lo que nosotros tenemos a continuación en el programa principal. Luego de ejecutado el RET es SP si vuelve a b000.
No sabemos en que nos estamos equivocando que ejecutado el RET el PC no vuelve a contener la dirección que necesitamos contenga.
Estuvimos revisando más profundamente en el GDB como se afectaban las memorias del stack. Es decir, cuando hacemos el call a una subrutina se supone que en el stack se guarda la dirección a la que debe volver a estar en el PC cuando se retorna de la rutina. Revisamos los contenidos de la memoria antes de la dirección del SP y observamos que no guarda lo que deberia. Lo mismo pasa con el PUSH que encabeza la subrutina hexa7seg. Pero cuando hace el pop si recupera los datos que antes no habia guardado por lo que recupera cualquier cosa. En nuestro caso particular además de guardar cualquier cosa en os registros HL lo que hace es que retorna con el PC a una dirección muy baja Creemos que por eso nos da el error antes mencionado, pero lo que no sabemos es porque se produce todo esto con el stack.
Anaclara,
recordaron inicializar el SP al arranque? No sea cosa que el SP esté apuntando a una dirección de memoria mapeada en ROM (o peor, en RAM del monitor que no está disponible para ustedes (0x8000-0xAFFF))
Saludos,
Leonardo.