Dual bank issue on stm32G0B1RCT6

[TSÉNA.1]

Recently I went from a stm32G0B1RET6 (512kB flash in dual bank) to a stm32G0B1RCT6 (256kB flash in dual bank) and I came across a strange behaviour (at least to me). The Firmware I work on is approximately 180kB in size, which means it can be stored in one flash bank of the previously used stm32G0B1RET6 but not on the stm32G0B1RCT6. Anyway I went on to test my FW on the RCT6 only to find out the FW was getting hardfaults that seemed to happen anytime the execution address was situated in the Bank B and something (maybe an interrupt) was called from bank A. The issues was solved by modifying the option bytes of the mcu to switch back to a single bank. Also when the mcu stalled in hardfault for such a reason it was not possible to debug it anymore and I had to mass erase the flash with cube programmer

So my question is : is there any reasons for the dual bank flash to cause such problems ?

[Andreas Bolsch]

I've made only some very simple test for programming flash on the 'trimmed' flash version, i.e. RC: In contrast to most (all?) older STM32 types where the 'trimmed' flash variants in fact have the full amount of flash (maybe partially defective or untested) implemented and mapped into address space, that's different on the RC: Here the address decoder is modified so that only access to the advertized amount of flash is possible (not strictly true, by playing with DUAL_BANK and nSWAP_BANK bit it is possible to access more that 256 kByte, but at any one time only 256 kByte), and without address gap between both banks. It's quite possible that this causes some side effects.

Hence: Did you actually verify whether your image had been written successfully and completely to flash where it is supposed to be written too? I mean, by checking some bytes in every flash page? I wouldn't be surprised if some flash programmer software might have trouble with that. In particular as the address decoder for read and write access is affected by those two option bits whereas the page number register for page erase is not.

[TSÉNA.1]

You raise quite a lot of intersting points here. I did not know about those trimmed older version. I indeed checked the FW flashed on the chip and did not find any specific differences between the two. I could have been more thourough in that research though so I am not 100% sure there were no difference at all. Moreover using a custom bootloader that I could follow precisely during the flashing process I could not find any glaring issues on that front.

There might indeed be some side effect that I did not fully understand however, as going back to a single bank setup seems to resolve the issue I did not go further on the investigation. I just wanted to have more insight about how this dual bank flash was supposed to behave.

Anyways thank you for your answer.

[Albert Fan]

I met similar issue and solved by disable PRFTEN bit in FLASH_ACR (__HAL_FLASH_PREFETCH_BUFFER_DISABLE()). Maybe you can also have a try.

[Albert Fan]

I met similar issue and solved by disable PRFTEN bit in FLASH_ACR (__HAL_FLASH_PREFETCH_BUFFER_DISABLE()). Maybe you can also have a try.

[SHuds.2 · Accepted solution]

I have met similar problems in my project for the STM32G0B1VCT6 and agree with Albert. I tried this solution because I read through the errata found here STM32G0B1xB/xC/xE device errata - Errata sheet and saw they have an issue with dual bank and prefetch enabled. My project works with either the prefetch enabled or with single bank mode, but not when both are enabled.

[TSÉNA.1]

That is the answer I was looking for. At the time I could not find anything in errata sheets and having tried the prefetch enable trick without success I was quite puzzled. Looking back I had probably already set the memory to single bank which made the prefetch trick fail.