cancel
Showing results for 
Search instead for 
Did you mean: 

STM32WB35 - Can't write or read flash memory (J-Link)

EJean.1
Associate II

Hello,

I'm a bit stuck and I am not sure what to do so I am asking for your help.

Here is the problem :

I have a custom board with a STM32WB35 that was working fine for a while. But after multiple (incomplete) boot when I was soldering the battery to my board it seems to have altered the STM because it doesn't boot anymore.

The other consequence is that I can't write a code anymode to this micro. I am using a J-Link and STMCubeIde and everytime I try it fails at the very beginning (compare 0%) then shows this error :

"ERROR: Timeout while calculating CRC, RAMCode did not respond in time."

At the beginning of the program the option bytes are modified to be able go in bootloader mode in some situations. That's why I was thinking that while writing the option bytes the STM32 got interrupted and it may have harmed the STM / the program.

I tried to start from fresh, erasing the flash using J-Link Commander v7.86.

0693W00000aHWaeQAG.pngBut I was not possible because the flash is locked.

0693W00000aHWoMQAW.pngI can't read the flash where the program is but I can read the Option Bytes at address 1FFF8000: 3D FF F1 AA.

0693W00000aHWf9QAG.png 

0693W00000aHWg2QAG.pngMeaning the read protection is not active.

In the meantime I was able to see what was the state of the nBoot0 (1), nSWBoot0 (1) and nBoot1 (1). So with this configuration and by pulling the pin BOOT0 high I should be able to go in bootloader mode but it doesn't. The STM is not visible anymore when connected via USB as it was before the incident...

0693W00000aHWf4QAG.png0693W00000aHWepQAG.pngWhat could prevent the reading and the writing of the micro if not protected?

Thanks for reading all this. I hope it makes sense to someone.

5 REPLIES 5
Piranha
Chief II

Use the "J-Link STM32 Unlock" tool.

EJean.1
Associate II

Hi Piranha,

Thanks for your help.

I didn't mention it but I already tried that.

Because I think it's just changing the RDP bits to have a read protection to level 0.

Piranha
Chief II

> Because I think it's just changing the RDP bits to have a read protection to level 0.

https://wiki.segger.com/J-Link_STM32_Utility

"it unsecures a read-protected STM32 device by re-programming the option bytes to factory defaults"

> I didn't mention it but I already tried that.

Does reading the memory work after the unlock and erase, but before loading any firmware?

> At the beginning of the program the option bytes are modified

Most likely that code is broken. Disable ir for testing.

The option bytes, which are actually loaded by device, must be checked at option byte registers, not at the FLASH memory. Check the contents of FLASH_OPTR and the OPTVERR bit.

Read the RM0434 Rev 11 section "3.4.2 Option bytes programming", especially the page 100.

EJean.1
Associate II

I tried again unlocking using the "J-Link STM32 Utility" and I can't read the flash memory either before or after a reset. I haven't been able to load any firmware since the incident so I can not deactivate it as far as I know.

0693W00000aHrAqQAK.png 

0693W00000aHrCrQAK.png> The option bytes, which are actually loaded by device, must be checked at option byte registers, not at the FLASH memory. Check the contents of FLASH_OPTR and the OPTVERR bit.

I can't read the content of those registers. I'm only able to read the option bytes.

Piranha
Chief II

FLASH_OPTR address is 0x58004000 + 0x20.

There are many protection options on your MCU, like PCROP and other. All of those should be checked.