[ell-i-developers] Re: Hard fault handler

  • From: jigsaw <jigsaw@xxxxxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Mon, 26 May 2014 15:50:45 +0300

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
>>
>>
>

Other related posts: