embassy-stm32 support g0 second flash bank

[chanterheld]

Integration of changes made in embassy-rs/stm32-data/pull/556: Addition of dual flash bank support for G0.

• Setting of bank select for erase bit in erase sector
• Waiting for both busy flags

Would be nice to have some feedback on how to deal with the now diverging options/registers other than the conditional compilation

[Dirbaio]

thank you!

Would be nice to have some feedback on how to deal with the now diverging options/registers other than the conditional compilation

conditional compilation is the way to go. it's a giant pain but there's no better alternative really :(

[chanterheld]

It has occurred to me that there might be an issue with this code for dual bank 256kb or less devices. The way the idx variable is calculated in the page erase method does not take into account the dual flash banks. This is 'fixed' for 512kbit devices by the 7bit bit mask for the page number. Another device will for example attempt to erase bank 2 page 64, instead of bank 2 page 0. This was an issue that arguably existed before already as bank 2 was just unavailable.

I will read up on the full set of available G0/G4 variants and see if i can come up with a more general solution. In the meantime could you elaborate on:

1. Why is the idx value being recalculated instead of using the index_in_bank variable available in FlashSector. Using this value instead of idx would probably solve the issue.
2. If and how would you want to deal with ic varients that can operate both in single and dual bank mode

[chanterheld]

From what I can tell this will be an issue for

• G0x1 256kb devices operating in dual bank mode (no supported by stm32-metapac)
• G0x0 512kb devices. This however has never worked
• G4C3 devices with 256kb or less in dual bank mode (not supported also)

Ill come with a proper solution that works for these devices once I'm back from vacation.

[Dirbaio]

Why is the idx value being recalculated instead of using the index_in_bank variable available in FlashSector. Using this value instead of idx would probably solve the issue.

I don't know, maybe the person who wrote the code wasn't aware of it.

If and how would you want to deal with ic varients that can operate both in single and dual bank mode

this is something that Embassy should definitely support and is currently a bit lacking. Currently embassy-stm32 assumes single-bank for some chips and just breaks in dual-bank mode (for example G4, in dual bank it has a hole in the address space between the two banks). It's possible it assumes dual-bank for other chips, not sure.

I think what would make most sense is a dual-bank Cargo feature.

It also has implications for stm32-data, because the memory map changes depending on the mode. G4 has the hole, also G4 and others change the sector size.