cancel
Showing results for 
Search instead for 
Did you mean: 

M4 libc startup code crashing using nosys.specs

marcusdufrane
Associate III

Trying to run some test code on the M4 core of a custom stm32mp151a board and can't seem to get far. I have been successful in getting u-boot working on the A core, so the majority of the board has been proven functional.

I will attach my make file as well as a simple project that fails. The board is configured to boot in engineering mode.

gdb indicates the crash is in memset from _start. I double checked it was pulling in the right version of thumb code for the library, and the .map file says it is.

I used the bss loop to write a known value and then verified the startup code was clearing the bss section. The crash appears to happen after that is complete.

I've also tried skipping the c _start function and calling __libc_init_array directly and it crashes in there. Skipping the _start altogether on the simple project runs without incident.

The indication from gdb at crash with the backtrace is...

Loading section .text, size 0x3f4 lma 0x10000000
Loading section .rodata, size 0x4 lma 0x100003f4
Loading section .ARM, size 0x8 lma 0x100003f8
Loading section .init_array, size 0x8 lma 0x10000400
Loading section .fini_array, size 0x4 lma 0x10000408
Loading section .data, size 0x42c lma 0x1000040c
Start address 0x100000b4, load size 2104
Transfer rate: 293 KB/sec, 350 bytes/write.
(gdb) c
Continuing.
stm32mp15x.cm4 -- clearing lockup after double fault
 
Program received signal SIGINT, Interrupt.
0x10000190 in memset ()
(gdb) backtrace
#0  0x10000190 in memset ()
#1  0x1000005e in _start ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I have also tried with 2 different versions of the arm-none-eabi toolchain. 2020-q2-update and 2019-q4-major

I must be missing something, linking something wrong, or using the wrong lib. Any help tracking this down is appreciated.

1 ACCEPTED SOLUTION

Accepted Solutions
marcusdufrane
Associate III

In case anyone else runs across this. In my case it was me overlooking something simple. The stack pointer was not being set in the startup file I was using. I dug into the Repository folder from stm32cube and found a functioning version.

View solution in original post

1 REPLY 1
marcusdufrane
Associate III

In case anyone else runs across this. In my case it was me overlooking something simple. The stack pointer was not being set in the startup file I was using. I dug into the Repository folder from stm32cube and found a functioning version.