[ell-i-developers] Re: Hard fault handler
- From: jigsaw <jigsaw@xxxxxxxxx>
- To: ell-i-developers@xxxxxxxxxxxxx
- Date: Fri, 23 May 2014 16:33:42 +0300
It turns out that the very basic GDB stub takes no more than a couple of
hundred of C code. I've got it working with mbed M0 board.
The definition of "very basic" is the capability of peeking registers and
memory, so that GDB remote can check registers, stack, heap, and do disasm.
No poking, attaching, debugging, tracing, etc. is taken in the scope at
this moment.
A further step is make the hard fault handler work when stack is broken,
i.e., when $sp is not in proper range. The problem under this circumstance
is that the C code won't work unless the stack is re-established.
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)
thx &
rgds,
-qinglai
On Wed, May 14, 2014 at 10:42 AM, jigsaw <jigsaw@xxxxxxxxx> wrote:
> Considering that I'm not familiar with SWD, and there's not much time left
> before hackathon, I will start with GDB stub over serial, providing a very
> limited scope of features, namely registers info and stack dumping.
> Backtrace may be available as well, but before it is committed I have to go
> over ARM arch, which I haven't played for a couple of years.
> I can use my own mbed-M0 with breadboard to code some prototype.
>
> BTW, I have a feeling that a sophisticated GDB-over-serial is able to
> provide all functions that SWD can provide. Is that correct?
>
>
> On Wed, May 14, 2014 at 10:27 AM, Pekka Nikander <pekka.nikander@xxxxxx>wrote:
>
>> > Yes the gdb remote protocol is the best option. Either over serial or
>> over SWD is fine for me, though I know few about SWD. But I don't get why
>> we need a Blackmagic. All we need are a serial cable and whatever gdb
>> frontend, right?
>>
>> SWD has hardware support, so it makes it possible to trace execution,
>> stop it, etc. Hence, if we have something like blackmagic that speaks SWD
>> directly to our board, and connect it with GBD using the GDB remote, then
>> we would have full debugging capability.
>>
>> OTOH, having a minimal GDB stup speaking directly serial would also be
>> very useful, as it would allow to do "core dumps", i.e. figure out what
>> went wrong, even when SWD might not be available.
>>
>> Still another, different idea might be to write a minimal TFTP server
>> that would serve the whole memory contents in the case of a crash, allowing
>> one to slurp the memory contents after a crash.
>>
>> --Pekka
>>
>>
>
Other related posts:
