[ell-i-developers] Re: Hard fault handler
- From: jigsaw <jigsaw@xxxxxxxxx>
- To: ell-i-developers@xxxxxxxxxxxxx
- Date: Wed, 14 May 2014 10:42:43 +0300
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:
