Page 2 of 2

Re: Debugging toolchain issues

Posted: Tue May 20, 2014 12:38 am
by jsgf
tobias wrote:Yeah, this is all strange. Does it mean that the stack has been corrupted maybe?
It looks fine to me. Comparing the VM and F20 compiled versions, they have the same sp, and the critical saved state on the stack is the same (pc, flags, etc). They also have no pending interrupt on return from the svc, so there's no interrupt chaining - it looks to me like it should just return to the svc caller.

But the point of the svc is to kick off the scheduler, and that's what happens on the VM-compiled version - it never returns from the svc and all the threads fire up, etc. So I need to dig in more and understand how FreeRTOS is using the Cortex M3 exception machinery, because there's clearly something I don't understand here.

Thanks, J

Re: Debugging toolchain issues

Posted: Wed May 21, 2014 8:03 am
by jsgf
OK, I've root-caused it.

I was getting confused because the HardFault is always on the main stack, so there's no obvious context for the source of the fault. I'd been missing that it was actually starting systemTask and had started to initialize.

The problem came from the 3rd printf message to the console that shows the device serial number. The %X format string ends up calling "itoa" which calls __aeabi_ldivmod as a result of the '/' operators. For some reason, the Fedora arm-none-eabi-gcc-cs package has non-Thumb implementations of __aeabi_ functions in its thumb/libgcc.a. When the non-thumb instructions are executed as thumb, it ended up loading r2 with an even pointer and running "bx r2", which caused the INVSTATE Usage Fault.

If I copy libgcc.a from the VM installation and link against it, it all works (at least as far as propeller twitch; I haven't tried flying it yet). I also updated it to FreeRTOS 8.0.1, which was pretty trivial.

More details https://bugzilla.redhat.com/show_bug.cgi?id=1099782

Re: Debugging toolchain issues

Posted: Mon May 26, 2014 7:52 am
by tobias
Great find, you clearly know your way around embedded systems, thanks!