Debugging issues on STM32H750 when code is relocated to RAM

[xhpohanka]

Hello,

I don't know if this is a bug or my misuse.

I have a project based on zephyr 3.1 (we will upgrade in future, but now it's not an option). The STM32H750 has quadspi flash for storing and running the firmware and for speedup parts of the code are relocated to RAM using zephyr's cmake support. Unfortunately the relocated parts cannot be easily debugged with openocd/GDB. Breakpoints are hit, but then the code cannot be resumed again.

I suspect MPU can be causing this. Can anyone give some advice?

thanks
Jan

[erwango]

@FRASTM

[FRASTM]

What is your usecase @xhpohanka ?
when relocating a driver in SRAM of the stm32h750b_dk disco kit, I can run a samples/basic/blinky with gpio_stm32. c relocated in RAM

0x24000004 in gpio_stm32_flags_to_conf (pincfg=<synthetic pointer>, flags=393217)
    at /local/home/frq09495/zephyrproject/zephyr/drivers/gpio/gpio_stm32.c:50
50		if ((flags & GPIO_OUTPUT) != 0) {
(gdb) info reg $pc
pc             0x24000004          0x24000004 <gpio_stm32_config+4>

This is with SRAM0 defined as follows in the stm32h750.dtsi

	sram0: memory@24000000 {
		reg = <0x24000000 DT_SIZE_K(512)>;
		compatible = "zephyr,memory-region","mmio-sram";
		zephyr,memory-region = "SRAM0";
		zephyr,memory-attr = <( DT_MEM_ARM(ATTR_MPU_IO) )>;
	};

[xhpohanka]

Hello,
have you tried to debug and step the blinky example with openocd and gdb?
I have no problem running, but the debugging.

This is how I do the relocation in CmakeLists.txt.

file(GLOB app_sources src/*.c )
zephyr_code_relocate(FILES
	${app_sources}
	LOCATION SRAM1_TEXT)

[FRASTM]

ok, (plus CONFIG_CODE_DATA_RELOCATION=y)
then did you try change to sram0: memory@24000000 ?
where the sram0 is declared as a mpu region :

		compatible = "zephyr,memory-region", "mmio-sram";
		zephyr,memory-region = "SRAM0";
		zephyr,memory-attr = <( DT_MEM_ARM(ATTR_MPU_IO) )>;
	};

[xhpohanka]

Ah, sorry
I have missed the line with memory-attr in your first message.
It seems that DT_MEM_ARM(ATTR_MPU_IO) is not available in zephyr 3.1 yet. Don't you know if there is any similar support? I will try it with uptodate zephyr, but now it's not so easy for me.

Later edit:
I have found this for older zephyr's

&sram1 {
		// zephyr,memory-attr = <( DT_MEM_ARM(ATTR_MPU_IO) )>;
		zephyr,memory-region-mpu = "IO";
};

It indeed seems to help at least somehow. Now I'm able to do stepping in GDB in relocated code :). Breakpoints set before the cpu was started are not hit, I need to set them later, strange but maybe can be caused by some init of relocation or the MPU?? I also met some behavior where the gdb shown wrong memory content, but it could be caused by some other staff, it is not reproducible in repeatable way...

[FRASTM]

this is probably a previous method for declaring the MPU regions,
The stm32H7 serie also has https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/arm/st_stm32/stm32h7/mpu_regions.c

[xhpohanka]

Can you please tell me, what has to be set up in MPU for debugging access and what is the "IO" attribute for? By the name it would not be my first guess to try :)