Gp32 Ext<->Serial Cable For Gdb Debugging.

[slaanesh]

Does anyone have a GP32 EXT <-> Serial cable they want to sell me? I'm trying to do some debugging with the GP32.
I've tried the USB port - not really sure what's wrong.

Steps:
1). Build my app
2). Included USB version gdb-stub
3). Include the following code when starting up:

#ifdef GP32_GDB
void trap()
{
 __asm__ __volatile__
(" \n"
 " mov    r0, #0x01 \n"
 " ldr    r1, [r0] \n"
 " \n"
 :
 :
 :"r0", "r1");
}
#endif

#ifdef GP32_GDB
        /* GDB Stub debugger */
        OpenUSB();
        InstallISR();
        trap();
#endif

4). Built app using devkitARM r26.
5). Run app - crashes. Great!

Other preparations:
1). GP32 bios flashed with MultiFWv2
2). Built gdbserv for cygwin (couldn't get it built under Mac OS X, libusb issue.)
3). Installed libusb-win32. Installed the device driver. Built a GP32 .inf file.
4). Tested gdbserv for cygwin - works wonderfully. Fully recognized and waiting for connection.

DEBUG: usb_init()
DEBUG: usb_find_busses()
DEBUG: usb_find_devices()
DEBUG: Vendor eb6 Product 3232
GDB thread is starting...
Opening socket, please wait.
Socket successfully opened.
Socket successfully bound to port 2334.
Started to listen at:2334
Waiting for connection...

Okay, now I though I was ready.
1). Run app, crashes. Great, GP32 doesn't reboot but sits there, presumable waiting for some GDB action.
2). Start arm-eabi-gdb.exe
3). From arm-eabi-gdb.exe - gdb: file app.elf
Everything loads fine.
4). Start gdbserv. Seems to connect fine, see above log.
5). From arm-eabi-gdb.exe - gdb: target remote localhost:2334
We have some action! But it's not good?

Got connection
Waiting for data
Sending data [14] $qSupported#37
Data send result: [-22]
Sending data [14] $qSupported#37
Data send result: [-22]
Sending data [14] $qSupported#37
Data send result: [-22]
Sending data [14] $qSupported#37
Data send result: [-22]
Sending data [5] $?#3f
Data send result: [-22]
Sending data [5] $?#3f
Data send result: [-22]
Sending data [5] $?#3f
Data send result: [-22]
Sending data [5] $?#3f
Data send result: [-22]
Sending data [9] +$Hc-1#09
Data send result: [-22]
Sending data [8] $Hc-1#09
Data send result: [-22]
Sending data [8] $Hc-1#09
Data send result: [-22]
Sending data [8] $Hc-1#09
Data send result: [-22]
Sending data [7] +$qC#b4
Data send result: [-22]
Sending data [6] $qC#b4
Data send result: [-22]
Sending data [6] $qC#b4
Data send result: [-22]
Sending data [6] $qC#b4
Data send result: [-22]
Sending data [13] +$qOffsets#4b
Data send result: [-22]
Sending data [12] $qOffsets#4b
Data send result: [-22]
Sending data [12] $qOffsets#4b
Data send result: [-22]
Sending data [12] $qOffsets#4b
Data send result: [-22]
WARNING: Lost connection, waiting for new connection

:-(

All those "Data send result: [-22] don't look very good...

What's wrong?

Anyway, I thought the UART cable would be better.

So anyone got a GP32 UART cable? It's going to a great cause. The app in question is MAME4ALL GP32.

 

[kidchaos2k6]

Okay, now I though I was ready.
1). Run app, crashes. Great, GP32 doesn't reboot but sits there, presumable waiting for some GDB action.
2). Start arm-eabi-gdb.exe
3). From arm-eabi-gdb.exe - gdb: file app.elf
Everything loads fine.
4). Start gdbserv. Seems to connect fine, see above log.
5). From arm-eabi-gdb.exe - gdb: target remote localhost:2334
We have some action! But it's not good?


Anyway, I thought the UART cable would be better.

So anyone got a GP32 UART cable? It's going to a great cause. The app in question is MAME4ALL GP32.

Hi there,

Its been a while since i touched my gp, but i used to debug my code with the usb cable...

I cannot test it right now but i think the steps are almost the same in different order...

1) turn on gp32 with usb cable connected
2) Start gdbserv, should open the gp32 usb port
3) run the app on the console until trap (white screen)
4) arm-eabi-gdb file.elf
5) target remote localhost:2334, the gdbserv should show some lot of output and the gdb should connect
6) i cannot recall the gdb commands now (c- to continue execution, and s-step crashed the console), i managed to install arm-eabi-insight in msys which worked great and easily allowed me to breakpoint, watch variables...

I agree that an UART cable would be much better but i did not have the skill to build one myself (there were some diagrams at the cobbleware site)
and never found a place to buy one... With the usb cable the debug process is painful: Can crash at anytime, loses the connection on great amounts of data,... But its better than nothing

Are you using the latest version of dkarm? I couldnt manage to debug newlib code as libraries were compiled without debugging information and i tried several times to compiled myself but the resulted compiler didnt work...

Hope this helps and keep us informed!

@B^)>

 

[slaanesh]

Hope this helps and keep us informed!

Thanks for the information.

I just can't get the gdb-stub to work correctly.

However, I've found another way that works quite well for me.
With the right firmware, when I get a crash, the GP32 will display the BIOS monitor. MultiFWv2 does it and one of the Slubman variants I have does it too.
This provides very useful clues as to where the crash occurred. In particular, the LR register and also R13 and R14 provide clues to what was the last thing on the stack.
Noting the values, you can then use 'arm-eabi-objdump -t app.elf' to determine where the crash has happened. Make sure that the app.elf was compiled with '-g' and not stripped ('-s').
Basically a manual way of doing a back-trace. It worked for me, I've found the bug and fixed it.

 

[slaanesh]

Still after the serial cable if anyone wants to sell one.