Where and how are some SYSCFG registers stored?

Mr_M_from_G · ‎2019-04-30

Hello,

I read ref manual part about SYSCFG (STM32H7 in my case). There are some regs that have an undefined reset value and the meaning of the regs is so that the contents is important at HW reset (BOOT_ADDx, BANK_SWAP). These regs are marked read only.

I couldn't find anything, how to set the values and where they are stored. Can I change them somehow from my software, ie change the boot address or swap the banks for the next reset?

General topic is to design a custom bootloader that will also be called after reset when BOOT0 is set. Also a fall back to the previous version after a corrupted firmware upload would be nice.

Thanks a lot

Martin

Andreas Bolsch · ‎2019-05-11

Cross check with flash option bytes/registers: You will see the bits in question (with unspecified reset value) are duplicated in the option bytes (well, havent't check this for every bit, but at least most of them). Possible reason: For security reasons, it might be useful to block accesses to the whole flash controller (and consequently option bytes) but still being able to access some of these bits.

If you want to modify the read-only bits in SYSCFG, modify the corresponding option bits via the flash controller (and initiate a reload of the option byte registers). Whether the writable bits "survive" reset, see table 41 in the RM: For a power-on reset there is FL_OPTB, so the option byte *registers* (and the corresponding SYSCFG bits) are loaded from the option bytes *in flash*. However, for a reset by NRST pin, there is no FL_OPTB, so the registers retain their current setting. Makes sense: You can temporarily change the boot address, issue a reset, and the new/alternative firmware starts cleanly ...

Regarding BKS in SYSCFG_UR0: see SWAP_BANK_OPT

View solution in original post

Ozone · ‎2019-04-30

All the non-vendor specific stuff is found at http://infocenter.arm.com/help/.

Just select the proper core architecture.

> Also a fall back to the previous version after a corrupted firmware upload would be nice.

This would require twice as much Flash, and position-independant code.

An alternative would be to add e.g. a checksum to the flashed image, check the application at each startup (or just after flashing it) by calculating the checksum, and remain in the BL on mismatch.

Or swap the default image in, if you want to spend the Flash space.

Mr_M_from_G · ‎2019-04-30

Hi Ozone,

are you sure SYSCFG is an arm core register? I couldn't find it in the arm docs. Please give me a closer link if you have. Also it contains some STM32 specific stuff like EXTI settings.

Needing twice the flash is clear, I use STM32H7 which has a lot (2MB). My understanding was that switching the banks is exactly for this purpose, but as I said I couldn't find any details. Maybe there is an application note that I didn't find yet.

Any help is welcome

Thanks

Martin

Ozone · ‎2019-04-30

> are you sure SYSCFG is an arm core register? I couldn't find it in the arm docs. Please give me a closer link if you have. Also it contains some STM32 specific stuff like EXTI settings.

Do you mean the system control registers, like there (in chapter 3): https://developer.arm.com/docs/ddi0489/d

> Needing twice the flash is clear, I use STM32H7 which has a lot (2MB). My understanding was that switching the banks is exactly for this purpose, but as I said I couldn't find any details.

I do not have an example that includes bank switching.

The MCUs my company uses for it's ECUs are not "switchable", and the application is built for fixed addresses.

Being able to switch banks to the same base address should ease the task considerably. However, I have no experience with the H7 devices.

Before starting to impllement, I would check if a fallback firmware is actually a desired use case for the customer/application.

In our case, it is not. Corrupted applications force the device in the bootloader, waiting for a firmware download.

thanks4opensource · ‎2019-04-30

I have very little useful knowledge to add to this discussion, but it seems to me that Mr_M_from_G is referring to the STM "System configuration controller (SYSCFG)" component and its associated registers, not the ARM core "System Control Register, SCR".

I believe the former, particularly the SYSCFG_MEMRMP register does at least partially control the functionality being requested, but unfortunately at this point my understanding comes to a dead halt. The ST/ARM boot sequence, with the BOOT0 and BOOT1 pins and registers, FLASH/RAM remapping, bootloading over USART/I2C/SPI/CAN, and how SWDIO takes control is all Harry Potter magic to me. If anyone has a clear flowchart documenting all this I'd be very interested.

Apologies if this post is of no value. Please feel free to delete it if so.

thanks4opensource · ‎2019-04-30

Humorous (to me) aside: I tried to post the above with the text "Harry Potter black magic" and got "Your message was rejected because it contains a banned word."

I don't know if ST is protecting us from racism or satanism or both. Will see if this gets through.

Tesla DeLorean · ‎2019-04-30

>>I don't know if ST is protecting us from racism or satanism or both.

Indian Astr0loger Spam

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Piranha · ‎2019-04-30

AN2606 has descriptions and flowcharts of system bootloaders. CPU core functionality is described in particular series "programming manual".

Mr_M_from_G · ‎2019-05-02

Hello everyone,

thanks for your contributions.

It seems I have to clarify some of my questions.

I asked about SYSCFG = System configuration controller, for H7 it is desribed in RM0433 chapter 11
I am not in trouble about *how* to get into bootloader, I used it a lot and I know AN2606 well.
In SYSCFG there are a number of registers that with regard to their description only make sense if their value is stored over reset. The corresponding bits give a reset value X. These registers are eg.
- SYSCFG_PMCR, bits PC3SO, PC2SO, PA1SO, PA0SO (could make sense also with a fixed reset value but shows X)
- SYSCFG_UR0, bit BKS and RDP. For my understanding BKS decides which bank corresponds to which address range, so at reset from which bank the program is executed. BKS is also marked read only.
- SYSCFG_UR2 and _UR3, BOOT_ADDx. Depending on BOOT0 pin at reset these define which address is called, these are marked read write
- there are more SYSCFG_URx with bits with reset value X that deal with protection and security features

My questions in general are:

Where are these bits stored? Do they survive a power off ? (I assume yes)
Which is their value for a brand new silicon?
How do I trigger a permanent (over reset and power off ) storage? Is it enough to simply write the register? Is there a timing to final storage.
What is the precise meaning and intended use of bit BKS in SYSCFG_UR0 Why is it read only? How can I change it?

And my special intention at the moment is to design a custom bootloader that will be called after reset when BOOT0 is set (instead of the one that comes with STM32 silicon). Also a fall back to the previous version after a corrupted firmware upload would be nice. I think I have a clear understanding how this can be done but ref manual gives me too few details how to do it on a STM32(H7).

So a clue to an app note would be great or some answers to the questions above.

Thanks a lot

Martin

Mr_M_from_G · ‎2019-05-10

Gently pushing this one up again.

ST members, can you help?

kind regards

Martin