gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Soft debugger project

#44392 - herrjones - Wed Jun 01, 2005 7:20 am

Hello all,

Please 'tell me if I am crazy or not, or if what I will write about is possible or not.
Since it seems there is no debugging possibility for code on the (GBA) target (don't know for the DS), I've seen a few questions on a software debugging stub to connect to GDB (the GDB remote protocol). I've been writing such a thing in the past for my ARM7TDMI project board (from Atmel, with a JTAG interface), but since a few other people were working on the same, I gave up and used their code.
The idea is to let the stub do all the work on the host (the PC/laptop/ whatever) and to let that stub communicate with a much smaller stub on the GBA (the target) (via the multiboot cable). So the stub on the GBA should be able to replace the instruction at a certain address with a jump instruction to the debugging routine, or a SWI instruction. This has then to be communicated with the debugger on host. This - I think - is a reachable goal, the more I already got part of the code.
Next thing to think about is how to implement/include it in code. There are 2 different approaches:
1) make a small ROM with the stub code in it, able to place and replace code at a certain address in memory (to start with, let's only talk about RAM). The stub is then able to accept incoming code and fill up the memory (download the code to debug directly in memory).
2) include the whole stub code into your new project you want to debug (via a few #defines, so you can easily leave it out in the final project).

The general idea is to just install an interrupt for the communication channel in UART mode (interaction with the host) and let the actual stub code be in FIQ mode (or another privileged mode).

Could someone give some comments on this one?

Kind regards,

Jan

#44423 - Miked0801 - Wed Jun 01, 2005 6:27 pm

Oh, but debugging is possible on the GBA. No$GBA (pay for it version) has wonderful debugging capabilities (emulator). VBoy also allows decent debugging. THere are also hardware dev kits from Nintendo for debugging, but that requires big money...

#44433 - Quirky - Wed Jun 01, 2005 8:07 pm

VBA with GDB/Insight is great. You can see some odd things in thumb mode due to the branch limits, but generally it has saved me many a headache.

#44490 - herrjones - Thu Jun 02, 2005 6:55 am

Yeah, I know you can use the emulators and connect GDB/Insight to it. But from my (professionnal) experience I know that in most cases there can be a difference between an emulator and the real target.
That's the reason why I want to try to implement a software stub.

Greetzz,

Jan

#44500 - FluBBa - Thu Jun 02, 2005 9:45 am

The reasson to have a good debugging enviroment is to save time, right?
The time you can save by using a good emulator in the first place and hardware as a second choice is quite big, flashing your application can take a couple of minutes.
I've only done real debugging with No$GBA (home version) but I can't see how you would do everything it does, on a normal GBA plus some debugging stub.
I think you can use the XBOO cable (is that the one?) to allow your PC to act like a console output if you want simple debugg output from the real hardware (if you find something on the emulators that doesn't work the same way as on the hardware).
And if you do find something that doesn't work as expected on the emulators you can probably get it fixed for the next version.
Edit: Oh, and this is from my own (unprofessional) experience ;)
_________________
I probably suck, my not is a programmer.

#44522 - josath - Thu Jun 02, 2005 4:22 pm

GDB can work remotely over tcp/ip, where the app is running on a different machine than gdb, i've used this before. I don't know how easily this would be to adapt to gba + a mb cable

#44562 - Miked0801 - Thu Jun 02, 2005 10:15 pm

Speaking with professional experience, I can say that I use No$GBA for 99.99% of all my debugging work. The differences between it and hardware are very small. It doesn't do RFU, and it is esoteric to use, but I love it. I have actual hardware debuggers on my desk next to me collecting dust as no$ is easier and faster to use than teh hardware.

#44797 - herrjones - Sun Jun 05, 2005 12:08 pm

The main reason why I'd like to start this projectis just "the challenge" to do it. And yes, I d realize that it'll be slower than emulators and even the hardware emulator you are talking about.
Other people like to write games with splendid graphics and sound. I'd like to start with something smaller ;-)

Kind regards,

Jan