2020-11-08 08:15 PM
If I try to put a method in the .data section using the below code, the microcontroller hangs when I try to call it. Is it a wrong way?
(When I check in the disassembly it appears indeed in the RAM)
__attribute__((long_call, section(".data"))) void my_ram_method() {
// Do something
}
2020-11-09 04:12 AM
Perhaps an alignment problem...
__attribute__((aligned (4), section(".data"))) void my_ram_method()
Why the long_call attribute ?
2020-11-09 04:24 AM
Actually, from the doc:
"
The CPU can access the SRAM1 and SRAM2 through the System Bus or through the I-
Code/D-Code buses when boot from SRAM is selected or when physical remap is selected
(Section 8.2.1: SYSCFG memory remap register (SYSCFG_MEMRMP) in the SYSCFG
controller). To get the max performance on SRAM execution, physical remap should be
selected (boot or software selection).
"
If I set SYSCFG_MEMRMP to 3 (to make SRAM1 appear to address 0) and then do the following, it is called successfully:
typedef void (*func)(void);
func prog = my_ram_method;
prog -= 0x02000000;
prog();
Still, it looks over-complicated
2020-11-09 04:30 AM
About long_call, I thought it would help since the address of the RAM function is far with respects to the others, but I'm not sure it is necessary.
2020-11-09 05:37 AM
A least recent gcc does not need longcall
2020-11-09 05:39 AM
As long as the device has no RAM originally located below 0x20000000 (CCM Ram), expect collision between data and command access.
2020-11-09 06:26 AM
Ok here is the actuel thing, I am using MBED as environment and I missed this page that basically explains two of my problems.
The MPU is pre-configured by the framework to disable both writing in ROM and executing of RAM. You need to declare explicitly if you want it to be possible using `ScopedRomWriteLock` or `ScopedRamExecutionLock`
https://os.mbed.com/docs/mbed-os/v6.4/apis/mpu-management.html