Debugging toolchain issues

[jsgf]

Hi,

I'm trying to build the crazyflie firmware with the default Fedora 20 arm-none-eabi toolchain, as its my preferred Linux environment. It is based on the Codesourcery 2013.11-24 release. It compiles successfully but installing the resulting cflie.bin on the crazyflie itself doesn't work: it just sits there flickering the red led and doesn't talk on the radio.

I can successfully reflash with the stock firmware, and I can build from source in the vm version of the toolchain.

Any pointers on how I can go about debugging this? I'm guessing the problem is one or more of

• linker is generating a bad image
• gcc is generating instructions for the wrong architecture by default
• something in the C code is undefined and the newer compiler is generating different non-working code

Thanks, J

[tobias]

Are you building the FW with the CLOAD=1 flag set? Else the addressing will not be correct with the bootloader still in the flash (or the other way around).

Code: Select all

make CLOAD=1 DEBUG=0

[jsgf]

Are you building the FW with the CLOAD=1 flag set? Else the addressing will not be correct with the bootloader still in the flash (or the other way around).

Code: Select all

make CLOAD=1 DEBUG=0

I was using the default (CLOAD=1 DEBUG=0) and flashing via the radio. I've since got a jtag interface, so I'm using "make flash" to flash with openocd and I can attach gdb and see that its getting a fault.

When I use CLOAD=0 it still faults, but I'm getting reasonable backtraces:

Code: Select all

^C0x080071e6 in uartSendData (size=size@entry=1, data=data@entry=0x20004f6c "[") at hal/src/uart.c:328
328	    while (!(UART_TYPE->SR & USART_FLAG_TXE));
(gdb) bt
#0  0x080071e6 in uartSendData (size=size@entry=1, data=data@entry=0x20004f6c "[") at hal/src/uart.c:328
#1  0x08007206 in uartPutchar (ch=91) at hal/src/uart.c:335
#2  0x0800cd58 in evprintf (putcf=0x80071f9 <uartPutchar>, fmt=0x800d217 "Hard fault handler]\n", 
    fmt@entry=0x0, ap=..., ap@entry=...) at utils/src/eprintf.c:150
#3  0x0800cd78 in eprintf (putcf=<optimized out>, fmt=0x800d216 "[Hard fault handler]\n")
    at utils/src/eprintf.c:164
#4  0x080079b0 in printHardFault (hardfaultArgs=<optimized out>) at drivers/src/nvic.c:110
#5  <signal handler called>
#6  0x080061da in prvPortStartFirstTask () at lib/FreeRTOS/portable/GCC/ARM_CM3/port.c:211
#7  0x080062fe in xPortStartScheduler () at lib/FreeRTOS/portable/GCC/ARM_CM3/port.c:244
#8  0x00000000 in ?? ()

It looks like the faulting instruction is the "svc 0" at prvPortStartFirstTask line 217.

Is the bitcraze vm toolchain using float-abi=hard or softfp? Would that make a difference?

Thanks,
J

[tobias]

This is really strange and nothing I have seen before. I will try to replicate and find a solution.

[tobias]

I can not replicate you error. I tried building and flashing both from Eclipse and the command line in the VM 0.5. Did you get this error when using the VM?

The toolchain should use softfp as the STM32F103 does not have a FPU.

[jsgf]

I can not replicate you error. I tried building and flashing both from Eclipse and the command line in the VM 0.5. Did you get this error when using the VM?

No, it works fine with the VM toolchain - sorry if that was unclear. I'm trying to replicate the VM toolchain's results with the newer version of the Codesourcery arm-none-eabi tools that come with Fedora 20. In principle they should be interoperable, and the resulting cflie.elf does look very similar - except that mine gets a HardFault and yours works fine :/...

The toolchain should use softfp as the STM32F103 does not have a FPU.

OK, thanks for clarifying.

[tobias]

OK, that is interesting that the Codesorcery tools in Fedora 20 doesn't work. If you find out why please let us know.

[jsgf]

OK, that is interesting that the Codesorcery tools in Fedora 20 doesn't work. If you find out why please let us know.

What I have so far:

If I set a breakpoint on HardFault_Handler, I see that the faulting instruction is the "svc 0" in prvPortStartFirstTask.

The saved registers are:

Code: Select all

(gdb) x/8x $sp
0x20004fe0:	0x20005000	0x0000008f	0x00000007	0x20000010
0x20004ff0:	0x0800d270	0x080062ff	0x080061da	0x61000000

so thats:

• r0 = 0x20005000 - matches msp in 0x0
• r1 = 0x0000008f
• r2 = 0x00000007
• r3 = 0x20000010
• r12 =0x0800d270
• lr = 0x080062ff = xPortStartScheduler just after call to prvPortStartFirstTask
• pc = 0x080061da = nop after svc 0
• xpsr = 0x61000000 - apsr=NZ, epsr=T

HardFault status register at 0xe000ed2c contains 0x40000000 - "Forced" - and Configurable fault status register 0xE000ED28 is 0x00020000 - usage fault bit 1 "INVSTATE" "Invalid combination of EPSR and instruction, for reasons other than UNDEFINED instruction. Return PC points to faulting instruction, with the invalid state."

And that's where I'm stuck, because I don't see what's wrong with EPSR that would cause INVSTATE. The Cortex M3 manual only lists T being clear as a cause of INVSTATE, but it is clearly set in the exception frame. And why does the compiler make a difference?

If I set a breakpoint on the "svc 0" and check the register state, its very similar between the F20 and the VM-compiled code: same r0, same sp, same xpsr.

Any thoughts?

[jsgf]

Ah, I overlooked something: it looks like it is reaching the SVC_Handler, and the HardFault is resulting from the bx lr returning out of it. Hm.

[tobias]

Yeah, this is all strange. Does it mean that the stack has been corrupted maybe?