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

  • From: Teemu Hakala <temmi@xxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Mon, 26 May 2014 15:57:47 +0300


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

Other related posts: