SRAM3 clock not enabled on power up

[Dylan_P]

An issue has suddenly popped up on my custom boards using a STM32U575CIT6. It manifests as the MCU appearing to not run code that was successfully flashed. Viewing the registers with CubeProgrammer seems to show it repeatedly running the reset handler. Attaching to the running process with CubeIDE shows hard faults occurring in the first instruction of `__libc_init_array` which is `push    {r4, r5, r6, lr}`. The hard faults are a precise data access violation and a stacking error. That instruction is the first instruction that utilizes the stack. When attached, CubeIDE cannot read any data from SRAM3. It appears as all ?’s. I found that the RCC_AHB2ENR1->SRAM3EN bit is 0, which is the clock enable bit for SRAM3. This would explain why SRAM3 appears inaccessible. Putting a breakpoint on the first instruction of the `Reset_Handler()` shows that this bit is unset even then. All other SRAM clock enable bits are set. According to the Reference Manual, that bit’s reset value is 1. 

All that is to say, how is it possible that that bit is unset seemingly upon power up when it’s reset value is 1? 

Some further context: This is not solved by a reset or power cycle. It does not matter what code is put on the board. Even old, definitively working, code does this. It does not matter how it is flashed, CubeProgrammer or IDE. Strangest of all, this issue seems to just “happen” to our boards and once it does we cannot fix it. It has not happened to all of our boards and we have not nailed down exactly what seems to start this issue on our boards. 

[mƎALLEm]

Hello,

I did a simple test on nucleo-u575zi-q board and didn’t face any issue. SRAM3 bit still set.

I even created a project with CubeMx for the device you are using STM32U575CIT6 and run it on nucleo-u575zi-q board SRAM3 bit in RCC is set to 1. 

Could you please use the attached project and see if you are facing the same behavior?

[Dylan_P]

Thank you for looking into this. 

I took two boards. One with this issue and one without. Your project did not change the outcome. I still saw that bit unset on the board that was having issues and the one that was working is still working fine.

[mƎALLEm]

That’s indeed strange. Are the boards the same?

 

[waclawek.jan]

Do you use any custom bootloader?

​@mƎALLEm may want to post a binary/elf to run.

JW

[Dylan_P]

I do but it happens to the bootloader as well. Even happens when running any project, including ​@mƎALLEm’s in debug. d

[Dylan_P]

I do but it happens to the bootloader as well. Even happens when running any project, including ​@mƎALLEm’s in debug.

[mƎALLEm]

Could you please provide a picture of each board where the STM32 part number is clearly seen?

[waclawek.jan]

My understanding is, that all the boards in question are identical, but some of them “develop” this problem over time.

I may be wrong of course.

JW

[waclawek.jan]

And what’s in the option bytes?

Can’t be the default bootloader running after reset for some time?

Of course, I’m just shooting blindly.

JW

[Dylan_P]

I exported a JSON of the option bytes from CubeProgrammer. 

 

{
  "deviceId" : 1109,
  "bitNameToValue" : {
    "RDP" : 170,
    "BOR_LEV" : 0,
    "TZEN" : 0,
    "nRST_STOP" : 1,
    "nRST_STDBY" : 1,
    "nRST_SHDW" : 1,
    "SRAM_RST" : 1,
    "IWDG_SW" : 1,
    "IWDG_STOP" : 1,
    "IWDG_STDBY" : 1,
    "WWDG_SW" : 1,
    "SWAP_BANK" : 0,
    "BKPRAM_ECC" : 1,
    "SRAM2_ECC" : 1,
    "SRAM2_RST" : 1,
    "nSWBOOT0" : 1,
    "nBOOT0" : 1,
    "PA15_PUPEN" : 1,
    "IO_VDD_HSLV" : 0,
    "IO_VDDIO2_HSLV" : 0,
    "NSBOOTADD0" : 1048576,
    "NSBOOTADD1" : 1569280,
    "WRP1A_PSTRT" : 31,
    "WRP1A_PEND" : 0,
    "UNLOCK_1A" : 1,
    "WRP1B_PSTRT" : 31,
    "WRP1B_PEND" : 0,
    "UNLOCK_1B" : 1,
    "WRP2A_PSTRT" : 31,
    "WRP2A_PEND" : 0,
    "UNLOCK_2A" : 1,
    "WRP2B_PSTRT" : 31,
    "WRP2B_PEND" : 0,
    "UNLOCK_2B" : 1
  }
}

 

[waclawek.jan]

  "deviceId" : 1109,

thats 0x455

and the “little” ‘U535/545 does not have SRAM3 at all.\

JW

[Dylan_P]

I looked at the rest of my boards closer and as it turns out, it is just one board that has had this happen to it. I really thought it was multiple but either they fixed themselves or there were other issues that were manifesting similarly. My guess is that this specific chip must be damaged. Still curious how it would bootup with an incorrect bit set...