Thanks for the advice. I will try porting blackmagic to LPC11u24. The only problem then is I can't test it until this Wed =/ On Mon, May 26, 2014 at 3:57 PM, Teemu Hakala <temmi@xxxxxx> wrote: > Hi > > Some of the stm32 discoveries have a f103 for usb that can be used for > running the swd probe. > > Sorry bein so terse, I'm on a phone. > 26.5.2014 15.51 "jigsaw" <jigsaw@xxxxxxxxx> kirjoitti: > > Finally I start to understand why SWD is needed and how it is more >> interesting than USART based GDB protocol. >> Only with SWD are we able to to set break points, step into the code, >> i.e. "dynamic" debugging. While with USART based GDB we can do "static" >> debugging only. >> And finally I understand why another MCU is needed (Black Magic for >> instance), coz there has to be a interface between GDB and SWD of the >> target. >> >> -----------enough BS------------------ >> >> Since I have a mbed LPC11U24 at hand, I wonder if it is feasible to make >> a GDB--GPIO--SWD bridge with it, as a generic debugger for any Cortex M >> chips. I'm uncertain, however, whether it will fits in 48 hours, and >> whether GPIO is the best option, given that mbed has other pins such as >> ACD, SPI, etc. >> >> Any comments? Thanks. >> >> -qinglai >> >> >> On Sat, May 24, 2014 at 5:45 PM, jigsaw <jigsaw@xxxxxxxxx> wrote: >> >>> Yes it is supposed to be linked for debug purpose only. I've tested with >>> dedicated stack for fault handler, and it works fine. Thanks. -qinglai >>> >>> >>> On Sat, May 24, 2014 at 7:53 AM, Pekka Nikander >>> <pekka.nikander@xxxxxx>wrote: >>> >>>> > This problem can be resolved in 2 ways: >>>> > 1. Code everything in assembly in such a way that no stack is needed. >>>> > 2. Setup a stack by giving $sp an arbitrary address, after which >>>> point C code can start working. >>>> > >>>> > Pros and cons of both approach are obvious. I personally would like >>>> to have option 2 implemented in that I'm not very comfortable writing >>>> thousands lines of assembly. >>>> > The only shortcoming of option 2 is that the newly created stack may >>>> overwrite existing data which may be useful for locating the fault root >>>> cause. >>>> > >>>> > But again this issue can be resolved by allocating a private and >>>> small piece of memory in linker script. It can be as small as 512 or 256 >>>> bytes, which is usually big enough for not-deep-nested C routines. >>>> > >>>> > My questions is, is it acceptable to rob 256 bytes just for fault >>>> handling? (OK, the size is negotiable) >>>> >>>> I think the original idea was that the GDB hard fault handler would be >>>> a compile-time option that could be linked into the image or not? If so, I >>>> think 256 bytes is perfectly fine. Furthermore, quite often when >>>> developing embedded software the MCU used in the development environment >>>> has more memory than what is available in the actual production MCU. >>>> >>>> --Pekka >>>> >>>> >>> >>