[ell-i-developers] Re: Hard fault handler
- From: jigsaw <jigsaw@xxxxxxxxx>
- To: ell-i-developers@xxxxxxxxxxxxx
- Date: Mon, 26 May 2014 16:54:31 +0300
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
>>>>
>>>>
>>>
>>
Other related posts:
