Cannot connect gdb almost code empty rom.

[Montserrat]

Hi to all.  Dont know if this is still active, but i will try....

So, i can debug other comercial roms, but when i try my own rom whith almost no code... i only get this:

Remote debugging using localhost:7000
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Bogus trace status reply from target: timeout

I've read about the other thread about the Vblank routine residing in WRAM, but i think its not the case, there is no such routine....there is no code at all, WRAM is cleared, just the usual initialization.

Any ideas?

[Montserrat]

Ah, forgot to include a wireshark file... i dont know how to interpret the data...

https://drive.google.com/file/d/1BrM6ra1sjz222jeOWhcdskRQtpvKKuAr/view?usp=sharing

[Chris McClelland]

Notice that the gdb.sh script has two branches: https://github.com/makestuff/umdkv2/blob/master/scripts/gdb.sh

One branch assumes you're debugging your own code (i.e an .elf file) that has been built with symbol information, etc, and puts a breakpoint at the head of the main() function in order to interrupt execution as soon as gdb starts.

The other branch deals with the case where you're debugging something that has no symbol information (e.g a commercial game). In this case it cannot know where to put a breakpoint in order to interrupt execution, so the UMDK convention is to put a breakpoint at the vblank address.

So in order to use gdb, you must either:

(1) use gdb.sh with two args in order to load your code as an .elf file as I demonstrate in the third video, or

(2) have a ROM loaded that regularly calls the vblank routine, which will allow gdb to interrupt execution and return control to the monitor program.

If you're at the early stages of development and don't yet have a vblank routine, and just want to observe what your init routine does, you could just run it without debugging, and look at the trace-log. That will tell you what's happening at the CPU level (i.e what instructions and data are being fetched, and from which addresses).

Chris

--
You received this message because you are subscribed to the Google Groups "UMDKv2 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umdkv2-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/umdkv2-dev/e606a13f-2bb1-4fe8-8d87-2c36ef72e4ebn%40googlegroups.com.

[Montserrat]

Thank you Chris, it worked, i opted for the second option, just  calling the VblankInterrupt routine in a loop.