[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
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
>>>
>>>
>>
>
Other related posts:
