I'm trying to investigate options for debugging on the Teensy3. I know real programmers shouldn't need to debug, but not being able to tell what's going on at the hardware level is making me a little sad. I'm intrigued by the claimed support for GDB debug over JTAG in the galago. But since it's still vaporous and I'm holding the teensy3 in my hand...
HID raw debug
Right now I'm struggling with trying to get the HID raw debugging stuff working. I also haven't had luck with serial, but that might be because of the mess I've made in the usb descriptor tables. Working with those things is such a pain.
JTAG
This is a hardware debug/programming interface. As has been pointed out elsewhere, the Teensy3 doesn't expose JTAG headers. I imagine some future version could do this. It's also not clear to me how much the JTAG would benefit us without some serious hardware and software support. I found a project that claims to have a software layer that translates GDB serial protocol to and from JTAG for ARM. I wonder if that's what the galago is using. On the hardware side I'm wondering if I could use the bus pirate to make my mac talk JTAG. Commercial JTAG units seem to be spendy (like $300+).
GDB in software
I'm wondering how feasible it would be implement GDB support in software. I'm basically thinking about a set of interrupt handlers that would talk GDB serial protocol over USB. Use the ARM Data Watchpoint and Trace (DWT) support (Arm 7M Ref Manual section C1.8.) to trigger interrupts at a certain PC value, specifically the DWT_COMP registers. It seems like the Teensy3's chip allows up to 4 hardware PC watchpoints (see K20 Sub-Family Reference Manual, Rev. 2 page 188 and ARM 7 ref manual C1-37). Install fault handler ISRs that send PC, register, and memory data to GDB over USB whenever an error occurs.
I have some questions about what happens, for instance, when my user program generates a fault (say by dereferencing 0x0) and then the fault interrupt handler returns. Say I enqueue some USB data for sending, but once I return from my fault interrupt handler, what happens? Does the hardware retry the last instruction in my user program (which, absent any change in values, will probably fault again immediately)? Does the hardware continue to run lower level interrupts like the USB interrupts? This is probably all trivial processor operation stuff that I've just never been exposed to before. Any references would be most helpful.
I know this is very handwavey, I'm just looking for some input as to feasibility and suggested direction I might take.
Thanks,
-c
HID raw debug
Right now I'm struggling with trying to get the HID raw debugging stuff working. I also haven't had luck with serial, but that might be because of the mess I've made in the usb descriptor tables. Working with those things is such a pain.
JTAG
This is a hardware debug/programming interface. As has been pointed out elsewhere, the Teensy3 doesn't expose JTAG headers. I imagine some future version could do this. It's also not clear to me how much the JTAG would benefit us without some serious hardware and software support. I found a project that claims to have a software layer that translates GDB serial protocol to and from JTAG for ARM. I wonder if that's what the galago is using. On the hardware side I'm wondering if I could use the bus pirate to make my mac talk JTAG. Commercial JTAG units seem to be spendy (like $300+).
GDB in software
I'm wondering how feasible it would be implement GDB support in software. I'm basically thinking about a set of interrupt handlers that would talk GDB serial protocol over USB. Use the ARM Data Watchpoint and Trace (DWT) support (Arm 7M Ref Manual section C1.8.) to trigger interrupts at a certain PC value, specifically the DWT_COMP registers. It seems like the Teensy3's chip allows up to 4 hardware PC watchpoints (see K20 Sub-Family Reference Manual, Rev. 2 page 188 and ARM 7 ref manual C1-37). Install fault handler ISRs that send PC, register, and memory data to GDB over USB whenever an error occurs.
I have some questions about what happens, for instance, when my user program generates a fault (say by dereferencing 0x0) and then the fault interrupt handler returns. Say I enqueue some USB data for sending, but once I return from my fault interrupt handler, what happens? Does the hardware retry the last instruction in my user program (which, absent any change in values, will probably fault again immediately)? Does the hardware continue to run lower level interrupts like the USB interrupts? This is probably all trivial processor operation stuff that I've just never been exposed to before. Any references would be most helpful.
I know this is very handwavey, I'm just looking for some input as to feasibility and suggested direction I might take.
Thanks,
-c