Ported CubeIDE project misses access to certain memory areas

Question

Have a project that has been proted from CubeIDE to a more standalone project structure. This because I am requierd to have the project run from other IDEs like C:b or even from a comandline environment only. The project is based on the STM32H743 Porting the project was ok, using the same arm-noen-eabi as cubeIDE do and by using the compiler flags and linker flags as CubeIDE have, and by using the startup and memory map as generated by cubeMX. The project compiles fine and I am able to run the debugger with c:b and stlink/v2, but for some reason there are memory areas that no longer is accessible.I am able to start the debugger and most of the code runs just fine, and dissasembly shows that the two setups generates approximatly the same code, but accessing certain memory areas throws a hardfault.The code is simple enough, copy to local variable whatever the pointer points to.Both projects generates the very same code as seen belowc = *pC;
 
ldr	r3, [r7, #32]
ldrb	r3, [r3, #0]
strb	r3, [r7, #22]the initial value for r7 = 0x2407ff18 for both projects, i.e. when running the CodeIDE project or the ported one. But when running line 4 above, "load to r3 what r3 points to" the ported project always ends up in the hardfault handler, but the Cube based project passesI believe it must be related to the linker setup somehow, but I cant figure out what. Ore I have missed some security flags for the STM32H7 core, whatever that may be. The thing is, I am to dumb to understand whats going on :\ So some suggestions for where to look or which more info you guys need would be appreciated, Thanks in advance EDIT.:Added the makefile for refferenceYoust be aware that there are a few things in the makefile which is leftowers from previous projects, so don't judge me to hard. It is the compiler/linker flags that is of most interest, I need to do a cleanup sooner or later

zainka1 · Accepted Answer

!Fixed the problem.Found an rather embarising error in the code which resulted in memory beeing overwritten, due to an for loop error, and which altered the pointer value...Why this error, which was present also in the CubeIDE project, didn't cause the same issue when running the code as compiled by the CubeIDE project is pure luck i guess.Nevertheless, a nightmare is over

Tesla DeLorean · Answer

It's more about what's at r7 (0x2407FF18)

The linker script will determine where things end up. Look at the .LD file, and then at the .MAP file the linker generates

Watch what startup.s is doing, it is supposed to unpack the statics from ROM/FLASH into RAM, and zero empty structures. The GNU/GCC solution is pretty sad an ineffective compared to Keil/IAR which can unpack structures generated by the linker. Make sure the code you have is aware of all the memory regions the program uses, and the symbols the linker creates to bound those regions.

Watch the stack/heap, GNU/GCC also have a rather simplistic allocator in _sbrk() with expectation about the placement of the two structures.

The H7 has certain memory areas where the clocks need enabling.

Sign up

Click below to sign in

Login to the community

Click below to sign in