Ported CubeIDE project misses access to certain memory areas

[zainka1]

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 below

c = *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 passes

I 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 refference

Youst 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

[Tesla DeLorean]

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.

[zainka1]

Wonder if, Stm32 team altered the std gcc library somehow? I mean, Cube uses arme-none-eabi as I do, but the gnu compiler Cube use is nested into the Cube sw package as is the libs. Just wondered if they have changed like _sbrk() compared to the standard lib you get when downloading any other version of arm-none-eabi-gcc....

This is however my Memory Configuration

Name       Origin       Length       Attributes

FLASH      0x08000000     0x00200000     xr

DTCMRAM     0x20000000     0x00020000     xrw

RAM_D1      0x24000000     0x00080000     xrw

RAM_D3      0x38000000     0x00010000     xrw

ITCMRAM     0x00000000     0x00010000     xrw

RAM_D2      0x30000000     0x00048000     xrw

*default*    0x00000000     0xffffffff

 Edit:

In CodeIDE, or more correctly, Eclips... I found the propertie page named "Preprocessor include paths, Macroes etc., and for GNU C there was a list of settings entries .

I am a bit unsure if these only affects the Eclipse settup or the project build itself.

Atleast there where a quite long list of definitions

Anuone know if these settings are used during a build? Cause I do not have these as part of my ported project...

[zainka1 · Accepted solution]

!

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