Webinar – Secure Bootloader Design Techniques for MCU’s

The webinar recording can be accessed at the link below:

Watch Recording

Download the Slides

Webinar Description:

A major challenge facing embedded software engineers today is designing and implementing a secure bootloader solution. Secure bootloaders require specialized knowledge in disparate disciplines such as driver software, middleware, cryptography, security and cloud computing just to name a few. In this webinar, attendees will explore the major components and processes necessary to implement a secure bootloader.

This webinar will utilize hands-on demonstrations using the STM X-CUBE-SBSFU Secure Boot and Firmware Update solution on an Arm Cortex-M4, STM32L476 Nucleo board using KEIL MDK.

Topics covered in this webinar include:
· The secure boot process
· Creating a Root of Trust
· Secure bootloader components and process
· Cryptography Fundamentals
· Secure firmware update with examples
· Attack vectors and prevention mechanisms
· Best Practices

Access the webinar recording below:

Watch Recording

Download the Slides

Below are the questions that were asked during the webinar along with the answers to those questions. Feel free to post further questions as comments to this post.

Questions Answers
are there other commercial, preferably better,  SBSFU frameworks ? Good question. “better” is subjective. There are frameworks like that provided by SEGGER or by Secure Thingz. I have not done a direct comparison though to determine benefits between them.
Does the secure engine capability to store x.509 certificate? This version,SB/SFU ver 2.0 does not support/handle/parse x509 certificates.  The ECSDA we use only uses the public key to authenicate.  In the key.txt file, called by the pre build build action, has a public/private key pair, only the public key is actually stored in the STM32L4.  No certificate is stored.  I have had customers, add private key and certificates on their own, using the PCROP to protect them at rest and put them behind the firewall too to protect them during runtime.  One note for you, If you PCROP a FLASH section, and put that same section behind the firewall.  Staticly the PCROP protects meaning you’d get a fault, and not a reset.  Once the firewall is enabled of that PCROP area, now an access will generate a RESET and not a fault… just FYI.  In addition to STM32, we can, under NDA with direct engagement with customers, do have working SB/SFU with the ST-Safe-A100 (secure element companion) which does support X.509.  The ST-Safe-A100 does have the parsing and commands to support X509.  There is a wrapper library intefface to the STM32.  We have working versions, for AWS/Google/Azure which uses this  SB/SFU but the PCROP protection is change to protect a pairing key.  The certificate and private/public keys are stored in the ST-Safe-A100 and used by the STM32 SB/SFU .   When you add certificates, there is also SSL/TLS stack in volved, the idea is to be able to revoke things, so the private key is need to sign things.  So adding certificates can be done, has been done.    Remember, this is a Framework, as question above.  Things can be added, crypto schemes can be changed, as there seems to be no too security requirements ever alike.
Do you know if some or any of the secure features (for example the firewall) take CPU resource during application runtime? The firewall is a physical PC of IP sitting on the AHB between the FLASH and the CPU.   So when the firewall is enabled, there are two states closed and open.  The CPU tries to execute code from the FLASH or SRAM section behind the firewall, hardware will generate the RESET.  So having the firewall sit open all the time, not good because remember ISR will generate a RESET just like illegal entry into the firewall, or firewall trying to acccess code outside its bounds.  While the Firewall is closed, after SB/SFU authenicates, illegal access RESET the system.  So you start, close, move to open, and then back to close.  It is possible to continue to use the firewall during runtime.  Some changes would need to be made.  For example, once the AES-GCM authenication is done, firewall closed….but say you want to communicate with a host over the USART and use AES-GCM… as long as the key is different from the SE_Corebin, you could open the firewall under runtime and have the same protection as during the SB Authenicatoin… so you’d have other fermeral keys PCROP used for this….Firewall does not use CPU resources other than being between the CPU and the FLASH/SRAM.
Is keeping private keys on MCU a viable option considering how inexpensive it is to get protected MCUs read?  https://russiansemiresearch.com/en/service/ Notice though that the STM32L4, etc are not on the list. The option bytes and protection mechanisms in the MCU can make it so that the part cannot be read over a debugger when place in RDP-2.
Is there any unique serial number or ID available on the STM32 platform via silicon? Yes. Each device has a unique 96 bit ID
Cryptography will increase bootloader time. How deal with that? Only the header would be encoded? Yes the time will increase. As we briefly discussed, security is not free. That is not just monetary but also it requires extra overhead for processing. The headers are signed if I remember correctly to validate and then the image is encrypted. If the header passes, then the rest of the firmware is examined in more detail. Yes, agree, plus… the ECSDA has the HASH-256 stored in the header, so when we boot, the HASH has to be calculated…takes time.  When doing AES-GCM, we use the MAC of the final encryption in the header, so for AES-GCM auththenication, no HASH, but we take the application AES-GCM encrypt, check it with the MAC of the header, then go…. so this takes time.  IF time is important, we do have STM32L4 with AES accelerators and SHA-2 HASH.  Our AES are about a 7/1 cycle speed up and the HASH is about a 10/1.  Currently the SB/SFU is all sofware.  I have had customers add the accleration, for this very reason.
PDF of slides available ? They will be posted to Jacob’s secure bootloader blog on beningo.com . Jacob will also send out a detailed update email tomorrow with links for everything.
So, from “Secure Firwmare Update”, the server should keep different keys for all devices? Yes
What do the yellow, green, white and grey represent? Green shows it is present on the part. Yellow that it is used in the SBSFU
Is this only available on the stm32L4 at this time? Yes at this time the reference code is available for the STM32L4. Undoubtedly it will be available on more parts in the near future. Ver 2.0 is only L4.  There is an update coming, by end of this year, you can say that, will include F4, F7 and H7 devices.  These devices don’t have firewlal, so the MPU is used to protect the SE_Corebin and SB/SFU.  All have PCROP used to protect the keys.  Also note the H7 will have a secure memory area, this will replace the firewall.
Please answer about the audio The pdf slides will not have audio. The recording will be sent out shortly.
Will the Slides have the associated audio? no
Can firmware keys be updated with this example code? Yes. You can generate your own keys and then use the python scripts to encrypt and build your deployable image.
Can we get access to this webinar after it is over?  I would like to watch it again later! Yes. The recording will be sent out about an hour after this webinar concludes.
What happens if the device loses power or resets (e.g. watchdog) while updating the option bytes? It would depend where the reset occurred and the resulting setting.
Following up on the power loss while updating option bytes, I’ve run into a case on the STM32F429 where a watchdog reset while doing that led to the DB1M and BFB2 bits being set, messing up the bootloaders flash memory mapping causing the application to not be valid Hmmm interesting. My understanding, which should be double checked, is that once you move into RDP-2, you can no longer change the option bytes. I would guess that you weren’t at that security level?
Correct, I was only in RDP-1.  I’m too big of a wuss to enable the RDP-2 which is a one-way street. Ok. Yea in RDP-1 you can still go back and reset the option bytes which could give you the issue you saw. The idea with the secure SBSFU is that you would run the end product in RDP-2.
Is the slidedeck available as well? Yes
Excellent presentation! Thanks
which cryptographic algorithms and signature shemes are supported by STM32? The SBSFU uses crypto software libraries so you can use nearly any scheme that you would like to use. It’s designed to be a flexible solution to meet many needs.
Does STM has any cryptographic accelerators? Yes. There are hardware accelerators on many chips. The SBSFU doesn’t use them right now but the code can be modified to use them. You just need to be careful due to the way the hardware shares the memory bus.
What if we find a bug in the secure bug? Will it be possible to ever update it by OTA updates? If a bug occurs in our immutable code then we would not be able to update it. We could create a new version that went out on new products but we would not update them on the old ones. That said, I would double check with an STM FAE. I believe that once the RDP-2 is set, there is no going back.
Can we store the user code on external FLASH and direct the Secure Boot to look there for the actual code? Yes, but done by the customer.  What I’ve done with several customers. The cost of ST internal FLASH is more expensive than putting a SPI NOR device outside the STM32.  So custtomers up for the lower FLASH size that can hold the application, pay less for the STM32.  The Ymodem interface is menat to be change.  It uses a 1k block of interface FLASH…You can redirect that to external NOR FLASH, which is nos SLOT 1 storage and off board.   You need a swap area of SRAM to bring in the SPI code, which is stored encrypted.  It take longer becuase you HASH/Authenicate the entire SPI file in NOR FLASH, then if good, you bring in in chunks, decrypt and store into runtime slot.  This also works for dual image as well.  The only drawback of off board and single image… you are vunerable much longer for a power hit during the switch over.  Using off board with dual image means you can have multiple versions off board…. but what you do different is move the ENTIRE SPI image into open slot, then works just like normal…. Once the file is Authenciate in dual image the only exposure time int he switch is for the boot address.. which is a couple cycles……So offboard with dual slot is best solution.  Off board with single slot… works.. the risk of power loss is higher becuase the switch takes longer.
If a hacker inject code on the RAM, the secure boot won’t be able to detect the integrity of the RAM right? So we will only be secure again after a full reset, right? Yes. RAM integrity is not checked during run-time. However, if the malicious code in RAM does something that the secure engine does not like, it will cause a reset which will wipe it from RAM and then develop a chain of trust again at start-up.
What are the things the secure engine won’t like? Access to protected data, code, tamper pins, etc. We saw an example when we saw the list in the SBSFU demonstration.
How much time does it usually takes to complete the secure boot process? I want to estimate the additional startup delay that’s going to be added to my product It does depend on if ECSDA or AES-GCM and the size of the application.  The USER APP we use is about 17K is size.  So to Authenciate and get to the Go/NOGO, have to HASH 17K file or AES-GCM encrypt to caluclate the MAC… the L4 allows for a 476K file with dual image…. So this is the deal. Software HASH-256 and AES-GCM encrypt, are given in our cyrpto library, https://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-cryptolib.html, which is what’s in the SB/SFU.  In the docs folder are benchmark data all given in clock cycles.  The L4 software HASH-256 takes, ~3462 clocks to HASH a 16byte block.  The L4 AES-GCM encryption takes ~1275 clocks for a 16byte block.  Using hardware acceleration, will improve the HASH by abut 10/1  and the AES-GCM by about 7/1.
What’s the purpose of the Firewall? I am thinking about an Internet Firewall and can’t see how this relates to a MCU The purpose of the firewall is to create a secure execution environment where no one can see into the executing code and associated memory or manipulate or interrupt it in any way. This prevents anyone from sneaking a peak at the code, keys or injecting unwanted behavior at a critical time.
Don’t you know an approximation? Like “1ms for each additional 1kb on avarage for an ARM M0+” ? The cyrpto library for the L0, which is M+ core, so look at answer above, HASH-256 16 byte block takes 13277 clocks for a 16byte block.  AS for AES-GCM it is not in the M0+ library, but AES_GCM uses AES-CTR for the encryption.  AES-CTR on M0+ takes 2489 cycles per 16 byte blocks.  The user abb is 17K in the SB/SFU, so this will allow you to compare M4 core to M0+ core.
Thanks
Does your company only sell trainement on SBSFU? No. Beningo Embedded also does consulting and advisory work in addition to training.
So you know other secure boot solutions (as you stated before) any other that you like? Any other free that you like? If you had to choose one, which one will it be? As far as free secure boot solutions, you are really looking at solutions from the MCU manufacturer. I have not seen any open source secure bootloader. Most likely because they are extremely complex and vary dramatically based on application need. I really like SBSFU. I’ve also heard really good things about the Secure Thingz solution. (They are now owned by IAR). I have also rolled my own custom ones periodically for clients as well. Choosing any one solution though if I’m using STM I would go with SBSFU for my base and modify it from there. Other manufacturers, Secure Thingz or modify my own.
Thanks a lot for all the support Thanks for the ?’s and attention!
Will there be support for Atollic’s tool chain? ST purchased Atolic over the summer, so yes it is coming.  It may be in the next SB/SFU release coming in the next month or so.  if you need GNU there is a GNU version now, STM32Work Bench, https://www.st.com/en/development-tools/sw4stm32.html, By AC6.
I tried that approach. Significant changes were required to the sample code to get it working. ah ok. I’ve done the same thing using Atollic with Amazon FreeRTOS and it was quite the process to get it going. I’ll check with an STM FAE but right now I don’t believe they are planning to support it in Atollic.
ok, thanks!
Is the STM32xxx hardware functionality required to implement the “firewall” and “secure enclave” described in the SBSFU manual? There are different ways to implement the firewall and enclave. This example uses the onboard features to help facilitate it. There are other ways to do it as well if those hardware features are not avaiable.
Does SBSFU work with all STM32xxx processors, or does it require the STM32L4xx used in today’s seminar? The current release supports the L4’s but additional support for other parts will be available in the future.
“rollback to the previous valid Firmware version” – does that implies that there should be enough storage space on the MCU to download the update firmware image, without overwriting the existing firmware? Yes. The SBSFU has two modes that it can operate that will be discussed shortly. Spoiler Alert! SBSFU can be configured for dual image mode where a backup can be kept (application flash space is halfed) or a single image.
For development, does it make sense to have a simple bootloader (debug only) to allow downloading images via JTAG without requiring a post build step to encrypt the image?  If not, what is the best way to work around this?  Thanks. Yes. A lot of times you can just directly write your application without the bootloader (hopefully having it written in parallel) and using the JTAG and then once you near production bring it all together and start using the encrypted version.
Can you list the components of the SBSFU that rely on hardware attributes of the STM32? Yes. You’ll find them on slide 13, but they are: debug access port, reset register, flash WRP, tamper pins, crypto library support, MPU, flash RDP, TRNG, Flash PCROP, Firewall, SRAM RDP
Can I used just the ST solution instead the ATEC508A for security boot? Yes
Are certain RTOS better suited to secure boot and firmware updates?  Which ones? For secure boot, the best way to go is to minimize code size, attack surface, so we would want to avoid using an RTOS.
Can a hacker simply circumvent security to  “brick” the device but not actually take it over? Yes. An attacker could still use a denial of service attack with this solution to prevent proper operation.
Following up, secure boot and update must run on “bare-metal”, there are no secure RTOS available? Not in this SBSFU example. You could write one with an RTOS if you wanted. The highest security RTOS i know of is ThreadX
how do i get/download the slides? They will be posted later today/tomorrow. Jacob will send a detailed follow-up email tomorrow with links that are useful.
Why are some blocks yellow on this (STM32 Security Features) slide? Those are used by SBSFU
How do I get slides and more importantly source code presented? Good questions. The slides will be posted on Jacob’s blog at beningo.com on the secure bootloader post. The SBSFU can be downloaded at https://www.st.com/en/embedded-software/x-cube-sbsfu.html
Do I need a separate ecc chip to store private key? No. The private key can be stored on the MCU. There is a secure enclave included in the code libraries coupled with the option bytes and other security features that can protect the key and keep it private.
Does the f401 support the crypto library? Yes the crypto library, has support for the F401, link above.  There is a version os SB/SFU for F4 coming in the next release, next month or so.
Does the Secure Engine and SBSFU reside in the same FLASH sector? It resides in the same flash “section”. It may not be on the exact same sector. I would have to check the linker and see. But it does reside in the same protected flash region.
Is the App image kept in RAM in one big chunk before installing or is it done in pieces? The USER APP is sent via ymodem in 1k chunks.  It is store direct to FLASH encrypted. Once the physical download is done, the SFU calls the SB which then does it’s thing.  IT take header and authenicates, via HASH-256 or via AES-GCM.  If all is go, then it decrypts 1k bytes at at a time via SRAM and then stores that back into the FLASH.  Once all is done. the start vector, Slot 0 to Slot 1 is changed, so if the user app is interrupted, the SB would still think slot 0 is good slot and run that.
Is it possible for a bug in the application to be exploited in order to change the application permanently in flash or otherwise compromise the application? It could be possible. The secure boot itself is in a protected flash region that cannot be changed. However, someone could write code that is injected in RAM and then is able to erase and write to flash in the user application area. The secure boot should be able to detect that the application is not authentic and woudl stay in the boot sequence awaing new firmware.
What about an actual change in the device? Like causing it to return bad sensor values in certain cases. This will be dependent upon the user application so it is hard to tell what behavior to expect.
lost audio You may need to logout and come back in. I’m seeing that the general audio stream is okay. Sorry for the inconvenience
Very interesting seminar by the way. I have a question, how do hackers stole or get the private keys? It depends on what security holes and bugs there are in the code. It usually has to do with trying to read flash, monitor RAM or registers where the keys may be used.
Will the slides also be available after? Yes
Thanks
Regarding the demo how do you prevent a FW user application from overriding interrupt handling for a TAMPER event?  Or how does a FW user application perform logic from a tamper event and have the sbsfu code still kick in to restart the device? The tamper event is part of the RTC.  You cnfigure the tamper pins to do things.  You can record the event time via the RTC and put in Battery backuped SRAM or FLASH.  Or if you are using the battery backed up SRAM, RDP protected, to store live session keys, the tamper feature can also be configured to record and ERASE the battery backed up SRAM.  This erase takes 2 sysclocks becuase this battery backup SRAM is register SRAM.  The Tamper can also generate an ISR and you can do additional things.  The Tamper feature is to show how to configure and use in a security environment.  The ISR could set stickybits in FLASH, to reocrd….. or it could do a MASS erase of FLASH… this is always the $100 dollar question.. what to do.   I’ve had customers use it to erase the tamper keys and record the event when doing TLS.
Isnt the idea of embedding the AES key into the device and reusing the same key each time considered a terrible security hole? It is not considered to be ideal.
Thank you for the details You are welcome
1) do the Slides have the associated audio? 2) After reviewing the documents mentioned and the slides is there a forum or such to post questions? There is the ST community that is located at https://community.st.com/s/
Do any of these SBSFU examples take quantum computer hacking into consideration?  i.e. algorithms that hold up to the power of quantum computers For now, ST has sent the SB/SFU out to 3rd party for verification…. Remember, the idea of the SB/SFU is to prevent REMOTE hacks.  Using Quantum computeres to hack, to me, means you are physically attacking, steping computing, calculating, or doing something becuase the entropy of the SB/SFU has been breached.  This is not a SB/SFU meant to defend physical attackes.  The anology I like to use, to hack a true AES-128 key would take the same amount of joules as needed to boil all the water and then some on earth.  the STM32 SB/SFU is not ready to defend against a Quantum computing device.
Should each device be loaded with its own keys?  How does this work in production? If you want to have very tight security then yes you would have each device with it’s own key. That greatly increases the complexity for key management and firmware deployment.
can the boot loader be done without an OS? Yes
Do you see any solution for secure bootloader update on field? Yes this same solution can be used for in-field updates, OTA or any communication interface such as USB.
I missed the beginning of your presentation. Can I replay it? Yes the link will be sent out later today.
Will the slides be available after the webinar? The slides will be made available after the webinar. I’ll post them and the recording to my blog on beningo.com
Green is bad yellow is good? Its just colors to differentiate different block.
Sorry – audio not working at our end That is on your side. Please exit the webinar and rejoin
How does Atollic True Studio is also suitable? It comes free in in the Full version from STM. Yes you can you TrueStudio but you may need to setup the project yourself.
What needs to be considered, if you want to store keys, certificates, and data on an additional secure device controller, which is certified by cc. like infineon optiga As mentioned above, under NDA, we have STM32 and ST-SAFE A100 SB/SFU where the private/public and certficate are stored in the Secure element.  This is what Infineon has.  What needs to be done for this to work, the pairing process of the ST-Safe to the STM32 has to be done securly becuse the pairing key is expsosed, as are the atemil/infineion/cypess type devices.. this pairing key is PCROP and firewall protected…. but note, if the computing is done in the STM32, so if using say a secure EEPROM, the pairing key can be exposed during a physical type of attack…..The secure element or secure eeprom will protect the private key and OEM key and certificate, so make sure to derrine your keys.
Is there any Subtitile option available? Not at this time. Sorry.
How MCU will validate the encrypted file as it is encrypted by server? The MCU valides it using a signature and hash
On which protocol OTA works for STM32 ? This solution uses Y-Modem
Is there any option to lock the controller when someone tries to access the controller or inject? As far as I know, if someone tries to access, the system restarts in order to clear out whatever may have been done. A develoer would need to modify this reference code to behave however they want it to
What the secure enclave exactly? The secure enclave is basically a secure processing engine. This is where secure data and code can be executed without the feat that someone will be able to watch or access that data and code.
Where the secure enclave resides? It resides in boot rom in a locked down flash region.
Do you have resources also related to TI CC32xx controllers? Not for this webinar. You would need to check the TI site. For TI parts, secure boot/bootloader is very hit and miss.
How the keys are stored in the device – encryted or plaintext? That is up to the developer. They are stored in secure storage and only processed in the secure enclave
how do i store keys in encrypted format? what is the root key? where is it stored? That will depend on your application and there are several ways to implement it.
Think he mentioned in the start, but forgot what was the size/type of the MCU in this example? The MCU is a STM32L476
Looks like ths solution is based on a key stored on the device. One of the biggest treat to embedded devices is to have a fixed password/key, if this is somehow revealed, suddently all of our devices is unsecure. Any ides on how to manage a unique key on each device, or other methods to mitegate this? That is something that we will not be covering today. How that is handled greatly depends on how the company wants to do it and the resources available for the specific application.
Do you know if any of the STM micros, has a serial number or other uniqie value I can read from SW? Yes. Each micro has it’s own unique ID
Why bootloder run in secure environment? Only BOOTROM code is expected to run in secure environment the secure boot and bootloader code is in the bootrom. It runs securely
Firmware update require device reboot? Yes the application runs, then restarts into the secure boot/bootloader, then update is performed but then the code can immediately jump to the new application code
which has alogrithm is used? Its up to the developer to select the algorithm they want to use.
*which hash alrogithm is used? Its up to the developer to select the algorithm they want to use.
Is it possible to peform firmware update without device reboot?Lets say device is used for military application Yes. Reboot is just the simpliest way to get to a “clean slate”.
how to do you define clean sate? clean slate would be the processor is in a state that it would be at power-on
SBSFU application runs in interrupt or polling mode? The SB/SFU has interrupts, the CUBE HAL has a 500usec systick, but the tamper and FLASH and others have ISRs… Remember the SB, firewall can’t have ISRs running, so when using Firewall ISRs are disabled…. In more complex and with RTOS, you have to time slice firewall usage with RTOS to process data… but ISRs are used.
What happen if active area gets corrupted during firmware update? It depends on the operational mode selected. There is a dual image mode that allows for a rollback to previous firmware. For a single image solution, the secure bootloader would still function and basically just wait for a new firmware image.
Is there any specifications of secure firmware update for embedded systems? There currently are no industry accepted standard. Arm and several other companies have tried to push out a standard but they are not widely adopted at this time.
But corruption is possible being with write access in case of single image yes
In protected processing
what about cache inavlidate? Very few MCU’s have cache. Only the STMF7.
only zero SRAM is mentioned yes
Can you give me reference where ARM has proposed specifications I will need to look that up. You can email [email protected] and he will see if he can find them.
Thank you for your presentation
it was helpful
There are standards for secure firmware update, such as LwM2M. Does the STM library support that functionality? Not that I’m aware of.
Does the mentioned STM32 L476RG board offer hardware crypto (such as ECC crypto operations) or are those just run in software? The board has it, but the SBSFU currently uses software for the crypto.
Is there a clear reason to verify the authenticity of the application at each boot even if it is running from flash? I get that if it is running from RAM, the load from flash to ram can be an attack point, but in the case of running from flash, the image cannot be modified unless through secure firmware update. Then why check authenticity again at each power-on? This causes significant boot delays. If someone injected a RAM based application that then programmed code into flash, the application could be suspect. Since you don’t know what the attacker will try, it’s best to verify the application on each boot.
The same can be followed for STM nucleo STM32f091rc cortex m0? the SB/SFU will not be ported to the STm32F0 family.  This is the only ARM core that does not have a MPU.  The SB/SFU is being released for F4/F7/H3/L0 devices.  When the firewall is not available the MPU is used to segment and protect the SB_CoreBin and SB/SFU…. F0 devices can’t do this.  Now the user can take these authenication techniques used on the L4 and port them to the F0.. the crypto library supports the F0… the SB/SFU will not be ported, so if the risk analysis of the device can tollerate no protection…. one way to go RDP-2… I could see this working.

6 thoughts on “Webinar – Secure Bootloader Design Techniques for MCU’s”

  1. Hello,
    I would like to register for this webminar and I encountered a small issue while trying to do so: the State/Province drop-down list does not seem to contain names applicable to countries from Europe. I would like to know how can I proceed to avoid getting an error during registration due to not filling the State/Province field properly (since none of the names listed are applicable for my location).
    Thank you.

  2. Hi Jacob,
    Are you involved in the development of SBSFU?
    Do you have new information when the next SBSFU version will come out?
    Presumably version 3.0 will be supporting F4 F7 H7 etc.,
    and Q4 usually means end of year, which is very far away.
    Thanks for the slides and presentation,
    Dimi

    1. Thanks for the comment. I am not involved in the development of SBSFU. Bootloaders has always been an area of interest to me and I’ve developed a few dozen over the years. I was interested in the solution and thought it would make a good webinar topic. To get a little more information on release dates and features, I would contact your local ST Microelectronics FAE and they should be able to get that information for you.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.