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

  • From: Pekka Nikander <pekka.nikander@xxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Sat, 24 May 2014 07:53:12 +0300

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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Other related posts: