EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: Manul on November 25, 2024, 01:17:25 am
-
Can someone explain the logic, why many newer series are forcing bootloader execution if user memory is empty, even when boot0 is low? Leaving basically no convenient option to power a newly assembled board without bootloader going willy nilly with various IO (uart, spi, whatnot). You need to either preprogram before assembly or keep it under reset until connecting SWD and setting things up. Otherwise you risk bootloader driving random stuff in your design and possibly even causing damage.
Sorry for the rant, but really, what is this idiocy? What was wrong with previous, traditional scheme? Or it's just me, who does not understand progress? Kinda reminds me of absurd problems when laptop manufactures started phasing out S3 sleep. All my older laptops were working perfectly with S3, some easily sleeping 1 week on S3. Now only hibernation works, otherwise high drain, random wake ups and dead battery.
-
Which STM32 series is it?
-
As I understand, WB, F0, L0, L4, G0,
G4. Don't quote me on this list, but seems to be many.
https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf (https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf)
-
The way I read the document you linked to, is that you still have to provide the correct pattern before the device will actually start the boot loader.
Table 2 shows a large list of patterns that force starting with the boot loader.
For instance pattern 6 uses the check on main flash containing proper code when two other conditions are met. So it is not for sure that when the main flash is not programmed the boot loader will be activated.
I guess one will also have to read the datasheet and reference manual of the chosen STM32 version to see when the boot loader is activated.
-
Yes, on a surface these patterns give an impression that you must do something special to invoke bootloader.
In reality, on certain series, there is nothing you can do to NOT invoke it if flash memory is empty.
For instance, STM32G07x "pattern 11". Many others too. Those which implement a check for empty program memory.
-
Can someone explain the logic, why many newer series are forcing bootloader execution if user memory is empty, even when boot0 is low? Leaving basically no convenient option to power a newly assembled board without bootloader going willy nilly with various IO (uart, spi, whatnot). You need to either preprogram before assembly or keep it under reset until connecting SWD and setting things up. Otherwise you risk bootloader driving random stuff in your design and possibly even causing damage.
Your hardware design is not ok when an unprogrammed chip causes undefined behavior.
This behavior of automatic bootloader entry if often found in chips with multiple flash-banks, and USB DFU capable devices.
For many products this is the only way to get a program inside.
Keeping an ST in reset is not hard, just attach an unpowered ST Link.
-
> Keeping an ST in reset is not hard, just attach an unpowered ST Link.
And does it keep it in reset when you power it up? Guaranteed?
> Yes, on a surface these patterns give an impression that you must do something special to invoke bootloader.
No, they don't. The default state of the option bits is documented in RM. Yes, AN2606 might've warned more loudly. And, worse than just running the bootloader, some bootloaders pull some pins hard. Yes, I did write a gotcha [not yet, in the pipeline] and I did complain at the forum.
JW
-
Your hardware design is not ok when an unprogrammed chip causes undefined behavior.
I can deal with the issue, but it just pisses me off. Thus the rant. Secondly, I think it's normal to expect non programmed MCU to keep it's GPIO in High-Z. Yet bootloader runs and drives various GPIO high and low. This is very inconvenient in my opinion. I would like to meet a person who thought that it's a good idea.
-
I wish all chips did this. It saves so much time in production. No more need for progammers or special jigs or handling.
Just plug in and load code.
-
I wish all chips did this. It saves so much time in production. No more need for progammers or special jigs or handling.
Just plug in and load code.
So you think what ST did is good? To be fair, I also think that having a bootloader is a wonderful thing, my issue is that they don't leave a CHOICE of preventing it to run. Which complicates things in certain situations without a reason. And it was not like that with many older series.
-
Iirc most have an option byte when set the booloader is eliminated.
-
Iirc most have an option byte when set the booloader is eliminated.
Yes, but when it's fresh from factory on first power up it runs the bootloader. And boot0 does essentially nothing. I think that it should be configurable through pins like boot0 or some other hardware mechanism. Now it's like "you want it or not, you will run my bootloader at least once" type of situation.
-
I just checked a random board with an STM32G431 on it that was just assembled and not programmed. The bootloader did NOT run by default: I had to raise the BOOT0 pin during reset/power-up.
-
Yeah, I haven't experienced this with ST parts yet. But I only use ancient ST parts (F1 anf F4).
But I know of NXP parts that do this, there it's even "worse", the must be a checksum (https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/LPC-Image-Checksums/m-p/471035)written in the vector table ta validate customer code is loaded.
I read the STM32G07x does it, but that silicon also comes with variants that have USB (DFU).
-
I just checked a random board with an STM32G431 on it that was just assembled and not programmed. The bootloader did NOT run by default: I had to raise the BOOT0 pin during reset/power-up.
Yes, apparently STM32G431 does not do empty memory check. Pattern 15 according to AN2606. Well, I haven't researched extensively, but I just noticed, that the trend is there. Maybe it's more common on their lower tier MCUs? Not sure. I read somewhere that all G0 does that. Maybe not all G4. I've also seen people mention this issue with some L0 and L4.
-
https://community.st.com/t5/stm32-mcus/empty-check-mechanism-on-stm32/ta-p/49369
STM32L4+
STM32WB
STM32G0
STM32F04x
STM32F09x
STM32F070x6
STM32F030xC
STM32L011x/ STM32L021x
STM32L41x/ STM32L42x
STM32L43x/ STM32L44x
STM32L45x/ STM32L46x
JW
-
This shows it is important to always read the manual first. :-DD
There is something to say for a MCU that, when not programmed, starts with an option to easily program it without "special" hardware, but the, as an example mentioned, STM32G07xxx devices do force you to make sure 7 interfaces are properly connected to what ever hardware to not destroy the MCU. A bit over the top I say.
5 pins that become push pull outputs when the boot loader is activated. So at least a series resistor in the line to avoid over current.
-
5 pins that become push pull outputs when the boot loader is activated.
No, they don't. IMHO boot loader starts in 'slave' mode - it passively waits for incoming communication on any of supported interfaces. When it received 'incoming' packet from any of them it activated TX path on it and disables all other interfaces. So you only have to ensure in design not to pass some garbage to any on incoming pins.
-
This shows it is important to always read the manual first. :-DD
There is something to say for a MCU that, when not programmed, starts with an option to easily program it without "special" hardware, but the, as an example mentioned, STM32G07xxx devices do force you to make sure 7 interfaces are properly connected to what ever hardware to not destroy the MCU. A bit over the top I say.
5 pins that become push pull outputs when the boot loader is activated. So at least a series resistor in the line to avoid over current.
I knew about this behaviour for a while now. My issue is mostly psichological, I'm coming from old school, I like things low level, in control and clean. Overall I like the G0 series, but such intrusive boot loader feature is repulsive, even insulting to some extent. Thus I was asking a question, where is the progress here? Maybe I don't understand? What was wrong with boot0 control?
-
5 pins that become push pull outputs when the boot loader is activated.
No, they don't. IMHO boot loader starts in 'slave' mode - it passively waits for incoming communication on any of supported interfaces. When it received 'incoming' packet from any of them it activated TX path on it and disables all other interfaces. So you only have to ensure in design not to pass some garbage to any on incoming pins.
:-DD I should have taken my own advice and read the manual a bit better. :palm:
It does seems to do so for the UARTS going on the flow chart in figure 59 "Bootloader V11.0 selection for STM32G07xxx/G08xxx", but for SPI it is not so clear.
According to the foot note the MISO line is set to 3.3V after SPI initialization as soon as the DMA is enabled. Where that is done in the flow chart is not clear.
Maybe you are right and if so it is not such a problem as the initial post made it out to be.
-
According to the foot note the MISO line is set to 3.3V after SPI initialization as soon as the DMA is enabled. Where that is done in the flow chart is not clear.
This is strange, because SPI initialized in slave mode. MISO should be in high impedance as long as SS externally held in 1. Forced 1 here could be only if STM do not tristate MISO line at all (I'm not sure)
-
According to the foot note the MISO line is set to 3.3V after SPI initialization as soon as the DMA is enabled. Where that is done in the flow chart is not clear.
This is strange, because SPI initialized in slave mode. MISO should be in high impedance as long as SS externally held in 1. Forced 1 here could be only if STM do not tristate MISO line at all (I'm not sure)
You have a point there. It should be controlled by the NSS line.
With the output being push pull and set to 3.3V it would cause problems if a multi slave setup controlled by NSS is used. Maybe they did do it right, but this manual is not clear about it.
I guess it depends on the configuration of the peripheral. The NSS control is part of it, so with the correct settings it should automatically do the proper thing, DMA being used or not.
-
I had that related issue with the G0B1. When the chip is blank, upon *first* flashing it, if you then reset it without a power cycle, it will not boot to your flashed firmware but to the bootloader. :-DD
(I found out there is a register you can write to for it to take the first flashing into account without having to power cycle it, but by default this is what it does.)
I wasted a good hour on this.
-
I had that related issue with the G0B1. When the chip is blank, upon *first* flashing it, if you then reset it without a power cycle, it will not boot to your flashed firmware but to the bootloader. :-DD
(I found out there is a register you can write to for it to take the first flashing into account without having to power cycle it, but by default this is what it does.)
I wasted a good hour on this.
This is probably feature of all bootloaders activated by the "FLASH empty" check (see list above), maybe with exception of 'F042 which has an explicit check for this in the bootloader.
(btw. the "FLASH empty" check in fact checks only the first word in the FLASH)
JW
-
I could understand this feature for very pin constrained devices that have no BOOT0 pin. Otherwise than that, it makes absolutely no sense; if there is the pin, why complicate the process? What drugs are they using? The same drugs when they changed H743 on-the-fly binary-incompatible without changing part number so that you could not know which parts you are ordering or your CM is using?
I wish all chips did this. It saves so much time in production. No more need for progammers or special jigs or handling.
Just plug in and load code.
Just strap BOOT0 to enable this feature, when wanted, and load code. That's exactly why the control pin is there. No need to force-enable it for those 99.9% who don't need it. And then, you can, gasp, do stuff like reprogram if you, for example, accidentally fail programming midway. No need to rely on empty-flash detection.
(SWD is faster in production anyway than ST's craploader which I refuse to call bootloader because it's not a bootloader.)
And don't get me wrong, I like the idea of UART/SPI/I2C/CAN/etc. based factory-programmed flasher and have used it extensively in the past but I pretty much prefer the way it is entered by an external pin, thank you.
-
(SWD is faster in production anyway than ST's craploader which I refuse to call bootloader because it's not a bootloader.)
If your definition of a bootloader is that it loads a main program to the memory and starts it, than you are totally right.
But you should then also use another name for what is used in the Arduino world. (And maybe you do :) ) The so called bootloader there allows you to make a connection at startup to (re) program part of the FLASH, and when no connection is made it jumps to the actual main code if present.
For something that needs to work in the real world, I myself would get rid of it directly. Have actually done so for an extension I made for my central heating system. Needed to control a mixing valve servo and an Arduino mini board was more than enough processing power to do the job. (All gone now by the way. The geothermal heat pump system is up and running and works like a charm.)
I agree that the automatic start when FLASH is empty is not really necessary. In each case (selected by pin or automatic) you still have to connect something to program your device.
For devices that do not have a BOOT0 pin, I see another problem. As soon as you have programmed the device it won't start in this programming code (bootloader) anymore, so you have to implement something in your own code to take care of reprogramming, or it has to have SWD pins and you still have to have a ST-link programmer.
Best option seems to be to always use a SWD or JTAG based programmer.
-
If your definition of a bootloader is that it loads a main program to the memory and starts it, than you are totally right.
Or to be more generic, something that runs first, and executes the actual application. Maybe just jumps there if it does not need copying to memory. Which Arduino bootloader does, hence it's a bootloader.
ST's "bootloader" is just a name, it does not boot first and it does not execute the application. It has absolutely nothing to do with a bootloader in any common or uncommon meaning whatsoever, except ST's own meaning.
-
If your definition of a bootloader is that it loads a main program to the memory and starts it, than you are totally right.
Or to be more generic, something that runs first, and executes the actual application. Maybe just jumps there if it does not need copying to memory. Which Arduino bootloader does, hence it's a bootloader.
I like to disagree on this. For me it is in the name. "boot" yes, that indicates starting as the first thing. But "loader" to me means actually loading something and not just jumping to code that is already there.
I know, it is semantic nitpicking. >:D
Maybe bootprogrammer would have been a better fit.