Hi,

Hopefully of interest to some of you wanting to do things like powerdown the mbed interface, perform whole system resets, and get the unique MAC address we allocated for every mbed.

• http://mbed.org/handbook/Beta

Shout if you have any problems.

Simon

It appears that the mbed_interface_disconnect() API is asynchronous. I notice that it takes some time for C_DEBUGEN to go low after calling this API.

Hi Adam,

Yes; do you think it should perhaps be synchronous?

Simon

I have the opinion that everything should be synchronous by default

Simon, thanks for the response!

I had expected it to be synchronous but I was able to get my software to work by just waiting for the asynchronous disable to occur in a loop.

I would have personally preferred synchronous but a comment about the function's asynchronous nature in mbed_interface.h would have helped me diagnose my problem more quickly.

-Adam

Simon,

Thanks so much for this interface chip firmware update. The mbed_interface_disconnect() routine is exactly what I needed. It allows me to enable the debug monitor mode but still keep the USB based serial port for communication back to the desktop machine.

Based on your new firmware, I have been able to get a certain little tool to give me some output that I have been wanting to see for a while from my little mbed device:

Reading symbols from /depots/mri/samples/HelloWorld/HelloWorld.elf...done.
(gdb) target remote /dev/tty.usbmodem412
Remote debugging using /dev/tty.usbmodem412
0x00000dd8 in __MriTestRegisters (this=<value optimized out>, __in_chrg=<value optimized out>)
(gdb) bt
#0  0x00000dd8 in __MriTestRegisters (this=<value optimized out>, __in_chrg=<value optimized out>)
#1  0x000001a6 in __main () at ../../src/gcc4mbed.c:94
#2  0x00000000 in ?? ()

Still much more work to be done before I push it up to github but it is already starting to show some promise.

Thanks,

Adam

Nice to see someone recognises why I put it there :)

This interface firmware really appears to do the trick. The below sample shows a bit more of what it is enabling:

/depots/mri/samples/HelloWorld$ arm-none-eabi-gdb HelloWorld.elf --baud 115200
Reading symbols from /depots/mri/samples/HelloWorld/HelloWorld.elf...done.
(gdb) target remote /dev/tty.usbmodem412
Remote debugging using /dev/tty.usbmodem412
__main () at ../../src/gcc4mbed.c:97
97	    __debugbreak();
(gdb) bt
#0  __main () at ../../src/gcc4mbed.c:97
#1  0x000014f4 in Reset_Handler ()
(gdb) break main
Breakpoint 1 at 0x736: file main.cpp, line 24.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at main.cpp:24
24	    volatile int IterationCount = 0;
(gdb) n
28	        myled = 1;
(gdb) p IterationCount
$1 = 0
(gdb) n
29	        wait(0.2);
(gdb) 
30	        myled = 0;
(gdb) 
31	        wait(0.2);
(gdb) 
32	        IterationCount++;
(gdb) 
26	    while(1) 
(gdb) p IterationCount
$2 = 1
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00011348 in wait ()
(gdb) bt
#0  0x00011348 in wait ()
#1  0x0000074c in main () at main.cpp:29
(gdb) 

Perfect. Nice work!

Simon

Simon,

As I have been working on the monitor code, a few ideas for potential future changes to the interface chip firmware that could make the debugging experience even better have come to mind. I thought I would run a couple past you:

• Cascade unknown events from JTAG to debug monitor - You mentioned this in a past posting. Rather than disable the JTAG portion, just place it in a mode where if it gets a debug event that it doesn't recognize then it would pend a call to the debug monitor on return from halt mode by setting the MON_PEND bit in the Debug Exception and Monitor Control Register. There might be some corner cases with such a feature:
  • If the exception handler wouldn't run immediately after returning from halt mode due to elevated priority then maybe it would be best to just eat the unknown debug event since I don't know how well I could get my monitor to handle the resulting async callbacks.
  • What does the current interface firmware do with the bits in the Debug Fault Status Register? Are they cleared? During a cascade, it would probably make sense to leave these bits in their current state so that the monitor can query them and it would be responsible for clearing them.
  • Whatever else I have missed :)
• CTRL+C over USB serial bridge to assert NMI pin - How possible would it be to put the interface chip into a mode where it actually watches the data passing through the USB to serial bridge? It would be great if when I knew that there would be no binary data going across the link, I could put it into a mode where a CTRL+C (0x03) byte would assert the NMI pin (which I believe is connected to the interface chip). This would allow a developer to at least get a call stack and look at some variables when a hang occurs that doesn't allow a UART0 interrupt to catch the CTRL+C break request from GDB. This functionality would either require the first item in this list so that the monitor could turn this mode on and off (using semi-host calls) or the interface firmware would have to be intelligent enough to parse gdb packets to know if the CTRL+C is just packet data or a break request (A 0x03 character sent after a '#' character but before a '$' character).

Thanks,

Adam