the sort of bugs that keep you up at night - ripping your hair out

Ok so I figured Id test this $50 investment real quick, before I get back to work I am doing with the Xilinx Xcv3 Spartan board. Figured Id modify the my stm32 firmware/linker scripts for the different I/O ports on this board. Figured Id get it to where I was originally with USB access - didnt think it would take three days ...

I had encountered a serious error right off the bat. Where the code was generating hard faults with fault #3 in execution and systick handler #15 pending and never running (after the first time).

The cortex m3 pushes 8 registers on the stack whenever it takes an exception. So I modified stm32_nvic_fault_handler as follows

asm ("mrs r0, msp");
asm ("ldr   r1, [r0, #24]");

The value returned was something like 0x2000 0887. Checked the map file flash.map and found that was a line of code in the stm32_uart_puts() routine. I tried to disassemble it from within gdb and it balked after address 0x2000 0888.

I used monitor mdw 0x20000888 3 to look at the three words immediately after loading the file "load" and before setting a break point and running to main. I noticed that the value was changing when I got to main ... it made no sense.


I started to wonder why the stack (monitor reg sp) held a value other than the 0x20010000 I wanted it set to. After all the first instruction in main was forcing the stack with

asm ("ldr sp, =(0x20000000 + (64 * 1024) - 4)");

Thats when I noticed that when arm-linux-gnueabi-gdb ./usb_test.out runs it prints out

xPSR: 0x01000000 pc: 0x0800125 msp: 0x20000890

Where was it getting this value? The command
monitor reset halt
Should be placing it in a known state. But where was that. I checked the map file and found nothing that would lead me to believe it was using information I provided. I checked the openocd scripts for odd initialization parameters.

Then I remember that on the arm7 board I had a similar problem because the board would start up running from flash. So when I dumped the value of 0x0 it was 0x2000 0890.

EUREKA!!!

Jtag still allows it to boot from eeprom on reset before it grabs control and the stack value was corrupting my program in ram.

So the solution would have to be the same I did with the arm7 and other cortex-m3. I will wipe out the contents of flash.

I did it with.

monitor flash probe 0
monitor flash protect 0 0 127 off
monitor reset halt
monitor stm32f1x mass_erase 0

monitor flash protect 0 0 127 on 

Now arm-linux-gnueabi-gdb ./usb_test.out starts off with

xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc

No where near my program at ram address 0x2000 0000 (64k of it on this ZET)



No more hard faults and my systick stay-alive-LED blinks once a second. Next Ill tackle uart and usb  ... if I have time

I purchased The Definitive Guide To Arm cortex-m3 this morning as well. It should shed a little more light on some gotchas - not necessarily listed or described well in the arm cortex m3 and the stm32 manuals