STM32G0: Remapping address 0x00000000 to SRAM does not work

[DaMCU]

Hello,

I'm using a STM32G0B1CC and I'm trying to remap address 0x00000000 to SRAM like this:

 __HAL_RCC_SYSCFG_CLK_ENABLE();
 __HAL_SYSCFG_REMAPMEMORY_SRAM();

Unfortunately this does not work and 0x00000000 is still mapped to FLASH.

If I try to remap to system memory it works just fine:

 __HAL_RCC_SYSCFG_CLK_ENABLE();
 __HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH();

Remapping back to FLASH is working just fine, too...

This is just baffling me because this just works with my original application using the STM32F030CC. Is there a restriction related to remapping SRAM?

Thank you for your kind help!

[waclawek.jan]

Read out content of SYSCFG_CFGR1.MEM_MODE and check/post.

JW

[DaMCU]

I have already done that:

• Remapping to FLASH: 0
• Remapping to system memory: 1
• Remapping to SRAM: 3

So, just like the description in the RM...

[waclawek.jan]

Humm.

What's the state of  BOOT_LOCK option bit of the FLASH_SECR register?

JW

[DaMCU]

Do you mean FLASH->SECR.BOOT_LOCK? Its value is 0.

The value of FLASH->OPTR is 0xFFFFFEAA.

[DaMCU]

I think I found the solution by experimenting.

I simply just copied the vector table from FLASH to SRAM and remapped 0x00000000 to SRAM. Then I tested the code and it worked! Then I changed the address for USART1 interrupt vector to a test function only containing a breakpoint instruction. Then I tested again and voila the debugger stopped in that test function. Consequently the remapping is indeed working as intended!

Before that little experiment, I only looked at the contents of the memory window roughly showing addresses 0x00000000 to 0x000000FF. There I could see the changes of the remapping just as it happend. For the remap options FLASH and system memory the contents of the memory view matched the content of FLASH or system memory respectively. But for the SRAM remap option, the contents of FLASH was shown instead!

It seems that reading 0x00000000 using the debugger simply doesn't work when remapping to SRAM. I have tried with SEGGER J-Link Ultra+ using STM32CubeIDE, KEIL uVision and SEGGER J-Link Commander tool.

[waclawek.jan]

Hummm... :)

Debuggers can be deceiving at times, indeed. Thanks for coming back with the solution.

JW

(Please select your post as Best so that the thread is marked as resolved).

[DaMCU]

Seems to be a problem of the SEGGER J-Link debugger because when using a KEIL ULINKpro debugger the memory view is populated correctly :grinning_face_with_sweat:

Well, there are always problems like that with relatively "new" chips, e.g. the current STM32G0xx device family package from KEIL is old and incomplete. I had to grab the newer system view description of the STM32G0B1CC from STM32CubeIDE and "transplanted" it into the device family package :flushed_face:

Thank you for your time and help!