STM32G0B1 Device lock?

[Schue]

Hi, I am currently trying to develop a DFU using the chip's dual bank feature.

After bricking my second prototype (only recoverable by exchanging the G0) I am out of ideas what could be the problem.

I could at least track it down to manipulation of the option bytes but do not see a problem there. My modification sequence looks like the following.

// No previous flash errors exist
// FLASH as well as OPTLOCK are unlocked
// I am only manipulating the bank swap bit
  if (targetBank == Bank::Bank_1)
  {
    SET_BIT(FLASH->OPTR, FLASH_OPTR_nSWAP_BANK);
  }
  else
  {
    CLEAR_BIT(FLASH->OPTR, FLASH_OPTR_nSWAP_BANK);
  }
// Wait while flash is busy
// Start modification by setting OPTSTRT
// Wait while flash is busy
// Launch option bytes (forces reset)

My test routine is just modifying the option bytes X times with a random bank selected (without a reset/OBL) and that works fine until I reset the device. Could it be a problem to write/modify the option bytes without actually changing them previously?

BOOT_LOCK is not set and I am aware of the errata (Device lock upon mismatch of option bytes) but like I mentioned do not see why there should be an option byte mismatch at all in my setup.

best regards

Tobias

[waclawek.jan]

> After bricking my second prototype (only recoverable by exchanging the G0)

How do you know? What did you try?

> My test routine is just modifying the option bytes X times with a random bank selected (without a reset/OBL) and that works fine until I reset the device.

How do you know that that works fine? Isn't nSWAP_BANK's only purpose to select bank on which to perform the empty test *upon reset*?

> Could it be a problem to write/modify the option bytes without actually changing them previously?

Maybe, but only ST can answer this authoritatively, so you may want to contact them directly, maybe through the web support form. If you do so, please come back with the solution.

JW

[Schue]

>> After bricking my second prototype (only recoverable by exchanging the G0)

>How do you know? What did you try?

Nearly all proposed solutions I found to get a device back to work.

Including

• all reset/connection modes the STM32CubeProgrammer provides.
• checking the SWD and reset line connections
• checking the boot0 pin (even though it should be defined by the boot0 option byte bit)
• checking if the device boots into the system bootloader somehow by trying to connect via UART

>> My test routine is just modifying the option bytes X times with a random bank selected (without a reset/OBL) and that works fine until I reset the device.

> How do you know that that works fine?

For that I am not 100% sure but the bank swap itself was working when I just switched to the other bank once per session (and not again until issuing a reset). Now the mechanism requires me to change it multiple times (select bank1, revert it to bank2, ...).

> Isn't nSWAP_BANK's only purpose to select bank on which to perform the empty test *upon reset*?

As far as I understood yes, but for this it also handles the remapping of bank1/2 to 0x8000000.

>> Could it be a problem to write/modify the option bytes without actually changing them previously?

> Maybe, but only ST can answer this authoritatively, so you may want to contact them directly, maybe through the web support form. If you do so, please come back with the solution.

Good point, will do that additionally.

Cheers

Tobias