Extending the STM32 Flash (Onboard) Module #1075
Replies: 2 comments 1 reply
-
Ah, I wrote an old blog post about that ;-P. There's no pressure to contribute everything you make back into modm. We chose the MPL license especially for that purpose, so that it's not a viral copyleft. So feel free to write your code in your application at the level you're comfortable with and maybe let yourself be inspired by some of the modm techniques. You can of course always contribute parts of your code as an example if you want to, then it'll be maintained and maybe someone else can refactor it in the future.
RM0455 has a section "4.3.13 FLASH one-time programmable area" that describes reading and writing the OTP at 0x08FFF000-0x08FFF3FC. Maybe that helps? |
Beta Was this translation helpful? Give feedback.
-
Which H7 devices are you using? The 1k OTP memory is exclusive to STM32H7A3/B0/B3. Other H7 variants don't have it. However, there might be an alternative. On some devices it is possible to write-protect flash sectors via the option bytes. |
Beta Was this translation helpful? Give feedback.
-
As I mentioned in a previous post, the project I'm using to test MODM is a secondary boot loader. I've modified the platform flash module to accommodate the H7 family, at least so that the basic stuff like erasing, writing, and of course reading flash is working. Now it's time to take make my old program use that module.
I tackled the UART code in my program first, since it was easier and I've always wanted to refactor it into a C++ class (it was some really good but repetitive C code that I inherited that was just begging to be "classified", if that's a word). Next I scanned my program's flash code, which I wrote about three years ago by cherry picking the necessary HAL flash modules (I didn't want to go all in on using HAL, and I figured out how to just snip out the bare minimum I needed just for flash).
Conceptually, I'm not sure that this code really needs to go in a C++ class, but I'm going to do so just for consistency and code organization / readability purposes. As I skimmed through this old code, I was struck by how much of it is auxiliary stuff like reading / managing protections, hooking into a timer ISR so it can timeout gracefully, setting up all those flash configuration registers, and handling the OTP memory (which seems to have disappeared in the H7 family, or maybe exists but is VERY poorly documented).
I'm torn between continuing to build a custom expansion of the existing MODM platform flash module, or giving up on that and just making it a application-only module.
The existing MODM flash module sets up the flash registers (those wait states). I'm not sure if it handles timeouts. And I can't find any examples from other micros where there are functions to control flash sector protection nor OTP bytes.
Also I'm fine now doing embedded programming using C++11 style, but just barely. Many features of "modern C++23" are way outside my comfort zone and experience. It was no big deal to make the small tweaks for in the flash.cpp.in files. But when I was digging through the code last night trying to understand the UART initialization function, like how to pass baud rate, I do not know how that code works at all. I can see how to USE it from the examples, but it looks like a steep learning curve of both MODM internals and C++23 to get to where I'd feel comfortable writing a major update to the existing flash module.
As you can see, all the above suggests that I'll pass on updating MODM flash module and will implement flash standalone in my application. I just wanted to post this here and see if maybe I'm missing something that might change my mind. Like, "oh, here's the API for random MCU XYZ that has all these abilities and you just have to modify it"
On the other hand, these mysterious 1000 bytes of user programmable OTP in the H7 may be a showstopper for my client if we can't learn the secret of programming / reading them. It's really bizarre that there is such clear mention of these in various ST data sheets and manuals, but absolutely zero details about how to use them. I may have to get them to add an external 256 byte EEPROM on the board.
-Chris
Beta Was this translation helpful? Give feedback.
All reactions