Debugging toolchain issues

[jsgf]

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

[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

[tobias]

Great find, you clearly know your way around embedded systems, thanks!