STM 32F4: any way to make it self program its FLASH from an external SPI FLASH? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: September 22, 2024, 09:35:22 pm
content: The factory boot loader supports UART, USB and CAN loading. Has anyone found a way to make it do SPI - like some other arm32 chips do (ESP32?)?The answer must be "not possible" since the boot loader cannot be reprogrammed.And if you are loading the FLASH via SWD then you may as well load the whole FLASH

author: langwadt
author_rank: Super Contributor
timestamp: September 22, 2024, 10:19:20 pm
content: Quote from: peter-h on September 22, 2024, 09:35:22 pmI believe it is possible to load a program in RAM and execute it using the bootloader

author: wek
author_rank: Frequent Contributor
timestamp: September 22, 2024, 10:20:01 pm
content: You can use a second mcu which reads the external flash and implements the SPI bootloader protocol.> like some other arm32 chips do (ESP32?)?Most chips which appear to boot from external FLASH or EEPROM in fact run a bootloader from internal ROM.JW

author: wek
author_rank: Frequent Contributor
timestamp: September 22, 2024, 10:24:16 pm
content: Quote from: langwadt on September 22, 2024, 10:19:20 pmSure, but the STM32 running bootloader is in the role of a slave, so again, there must be "somebody" (PC or a second mcu) implementing the bootloader's "master" portion on any of the available interfaces, to fill up that RAM.JW

author: peter-h
author_rank: Super Contributor
timestamp: September 23, 2024, 06:53:24 am
content: QuoteYes. Incidentally I recall an STM32 project (not mine) where the customer demanded aprovablynon-brickable firmware upgrade feature, and a 2nd CPU was the only way to do it.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 23, 2024, 07:09:26 am
content: Quote from: peter-h on September 23, 2024, 06:53:24 amThere is absolutely nothing magic in adding another MCU that makes it any more provably non-brickable: exactly same concerns still apply. Adding a second MCU only adds even more potential points of failure.

author: newbrain
author_rank: Super Contributor
timestamp: September 23, 2024, 07:19:30 am
content: Unless "provably" means "passing all the tests that that we managed to devise with our humanly limited fantasy".

author: peter-h
author_rank: Super Contributor
timestamp: September 23, 2024, 07:41:52 am
content: Well, obviously, there would be a presumption that the 2nd CPU has well tested code which the customer thinks is solid and which will never be upgraded. That 2nd CPU would waggle the /NRST and I guess the BOOTx pins, while feeding the data into the main CPU via one of the routes provided.There is a thread here describing the CAN mode is horrible, and USB is absolutely never going to be "provably" reliable, so I guess serial (at some decent speed) would be the way to do it.QuoteThat makes sense, as otherwise they would need hardwired logic to implement the loading. No point really.

author: Psi
author_rank: Super Contributor
timestamp: September 23, 2024, 07:49:13 am
content: What's wrong with just writing your own bootloader?Have I missed something?

author: fchk
author_rank: Frequent Contributor
timestamp: September 23, 2024, 08:02:33 am
content: Quote from: peter-h on September 22, 2024, 09:35:22 pmRead AN4286:https://www.st.com/resource/en/application_note/an4286-spi-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdffchk

author: Siwastaja
author_rank: Super Contributor
timestamp: September 23, 2024, 08:16:15 am
content: Quote from: peter-h on September 23, 2024, 07:41:52 amThis presumption indeed makes life easy, if it holds. You get the same result without the extra chip by running that solid non-upgradeable code as a bootloader, which is why I said there are no extra magical qualities in putting an extra physical part in the design.Of course, sometimes you hit a useful corner case where you almost have enough flash but not quite. Then maybe dedicating some part (such as update, but could be something else too like some IO task) to a separate microcontroller is not necessarily any worse than adding an external flash chip for more memory; especially if the offloaded part is trivially simple to never change.

author: peter-h
author_rank: Super Contributor
timestamp: September 23, 2024, 08:27:39 am
content: QuoteYes; the 32F4 is a slave. It can accept data via SPI (so indeed that might be the best way to load the data into it) but cannot be a master which extracts data from an SPI FLASH chip.There needs to be some CRC which gets checked and the process restarts if it is duff.I have a RAM based loader in my project (posted about it previously) and that has a brickable time window when it is rewriting the bottom 32k, but that takes only a fraction of a second, and it is extremely improbable that the problem would happen during that time (having successfully programmed and verified the other half a meg or so).

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 23, 2024, 08:29:45 am
content: Presumably this ST part can write its own flash under program control, so of course can write data read from an external SPI flash - you just need to write the code to do it.This is a good way to handle situations where a firmware update comes from some storage/comms interface that the end-product uses - e.g. wifi, bluetooth etc. Write the SPI flash, and only when the whole image has been downloaded and verified, copy from SPI to main MCU flash.Plenty of scope for added- extras like a fallback image in case of a bad update, encryption etc.Much more flexible than using the factory bootloader, and may offer a more user-friendly way to do updates.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 23, 2024, 08:32:34 am
content: Quote from: peter-h on September 23, 2024, 08:27:39 amOf course it can be a master, you just have to write your own code to do it. It is possible to make this bulletproof - as you say the window is short, but your bootloader can check flash integrity at startup and restart the SPI flash copy process if it got interrupted.

author: fchk
author_rank: Frequent Contributor
timestamp: September 23, 2024, 08:45:33 am
content: Quote from: peter-h on September 23, 2024, 08:27:39 amAll you need is an extra small uC (a 14 pin PIC16F18326 would do the job) that reads the firmware from a SPI NOR flash or a SD Card and feed it into the STM32. This should be unbrickable then.I remember ATmel having an extra AT90S1200 uC for recovery on an STK500 devboard.

author: peter-h
author_rank: Super Contributor
timestamp: September 23, 2024, 09:01:32 am
content: The "custom bootloader" is just normal user code, starting at 0x08000000 like any other code. The 32F4 does not provide for a "custom bootloader" as such. So this bootloader is nothing special. No BOOTx pin selection needed (both are 0). The lowest block, 16k, is erasable at 16k, so your loader ought to fit into that, which is easy. I did all that already (except my "boot block" is 32k).But this all assumes that code never gets overwritten by rogue code running elsewhere. It would really need program protection. This appears possible on a per-block basis via FLASH_OPTCR etc.QuoteThat's funny since I have used tens of thousands of the 90S1200 and while it is a great chip I would not call it 100% reliable. I reckon 1 in 1k to 10k corrupts its firmware. That is in addition to the documented bug of corrupting the 1st EEPROM location.

author: nctnico
author_rank: Super Contributor
timestamp: September 23, 2024, 09:24:33 am
content: Quote from: peter-h on September 23, 2024, 06:53:24 amI doubt that is true. I have implemented such systems myself and the way to do it is to have 2 images: active and update. You can even resort to having a third (backup) image in case everything else fails. But it is all driven by a fixed bootloader which never gets overwritten. ESP32 has such a system as well.

author: Jeroen3
author_rank: Super Contributor
timestamp: September 23, 2024, 09:29:43 am
content: Maybe you can modify the external loader programs to your needs?https://github.com/STMicroelectronics/stm32-external-loader/tree/mainThe external loader program is used by the toolchain to get data into the spi flash.

author: peter-h
author_rank: Super Contributor
timestamp: September 23, 2024, 09:42:00 am
content: Yes; the SWD debugger route is another way. Probably the most robust of them all.QuoteI think that depends on the error recovery you have. If you can download the OTA image only once, then yes. Otherwise you might have two firmware copies in the CPU FLASH but how do you select them? You have to assume 0x08000000 is corrupted which means any custom "boot loader" is also dead. The 2nd CPU has no way to select them via external pins.Actually 0x08000000 doesn't matter if you are loading SP in your startup code, but 0x08000004 definitely does matter

author: Siwastaja
author_rank: Super Contributor
timestamp: September 23, 2024, 11:06:22 am
content: Quote from: peter-h on September 23, 2024, 09:01:32 amFair enough, but then again what prevents your separate MCU from having a bug where "rogue code running elsewhere" overwrites it, or controls it to overwrite the main MCU, or both? Or both your main MCU and separate MCU having bugs that make them do weird things together?This all sounds like a very typical case "solve understandable surface area for bugs by adding more complexity until everything is so complex that we lose track on what kind of bugs could appear" engineering. I'm pretty sure in real world you arenevergoing to see a case where you have a bug causing runaway code to write magic flash unlock values, write correct erase bits and/or write to those correct areas. I mean, this is common enough concern that MCU vendors long ago implemented those magic unlock sequences and you can pretty easily just sanitize the inputs to your write_to_flash(void* addr, size_t n) function. Good old normal software engineering.Then again, an attacker who deliberately does this does not care, they will do whatever they want regardless of whether it's a 1- or 2-chip solution. With 2 chips they have the convenience of more surface area to grip to.You are blinded by the fact that the simple and usual solution is hard to prove completely failure-proof, and forget that no one is able to prove the alternative 2-chip solution any more failure-proof either.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 23, 2024, 11:10:34 am
content: Quote from: peter-h on September 23, 2024, 09:42:00 amThis sounds like a very arbitrary requirement, but sure, if you say so, then you will need a second chip. Let's not forget though that you mustalsoassume that its 0x08000000 is corrupted too, so you will need a third chip to recover the second chip... and so on.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 23, 2024, 11:24:50 am
content: There are ways to guard against (accidental, not malicious) rogue code - most MCU flash write mechanisms require one or more actions to unlock the write capability. You can arrange for the register values/actions required for this to not exist anywhere in the code, but be created by a specific sequence of actions performed by the bootloader.e.g. the value needed to write to a register is read from SPI flash as part of an update image, and erased after a successful update. That way there is nowhere that code can randomly start running from that can corrupt the flash.Some MCus have zone-based hardware write protections designed to protect bootloader code.

author: peter-h
author_rank: Super Contributor
timestamp: September 23, 2024, 11:28:24 am
content: QuoteUsually the code with the magic numbers gets put into a function, and a crashing program eventually ends up inside that function. I have seen this with the 28C256 EEPROM which uses magic values too... Hard to believe, yes.You get the same problem with watchdog triggering. A crashed program can still be doing it, unless you do something more complicated. But ultimately if the code is there (and it must be) it can get executed.QuoteThe idea is that the 2nd CPU is never put into a programming mode. Its firmware does not contain the FLASH unlock codes, etc. It only ever runs code placed into it using whatever production process was used (SWD etc).I am not keen on the 2nd CPU idea either, FWIW, but it seems to be the only way to load code from an SPI device, unless natively implemented.

author: Nominal Animal
author_rank: Super Contributor
timestamp: September 23, 2024, 11:49:02 am
content: Welp, the way Teensy LC, 3.x, 4.x and Micromod have successfully used NXP MKL02 and MKL04 chips for exactly this purpose – to load the firmware update program to the RAM of the main MCU, doing the actual new firmware upload stuff; seebasic schematic– indicates it is definitely possible to do this right. These buggers are surprisingly hard to brick (excluding actual electrical damage).Note how these are implemented: the bootloader MCU is connected only to a button initiating the firmware upload procedure, and to the JTAG interface, plus boot mode selection pins, DCDC_PSWITCH, and POR_B pin so that it can reboot and handle the power sequencing details on i.MX RT1062. It only transfers the bootloader code to RAM on the main MCU, which takes over the bootloading procedure.The only way I know software can brick this (without electric damage, that is), is disabling the JTAG interface. As the "bootloader chip" is one of the secure ones, it can also provide signature verification for the firmware image (in as large chunks as fit in the rest of the RAM).I do disagree somewhat with Siwastaja's"Adding a second MCU only adds even more potential points of failure"assessment, simply because it is not the number of potential points of failure, but the complexity in the points of failure, that tends to be the deciding factor in robustness or lack thereof.As an example, if you have say 3Npotential points of failure, but each one is simple, it is preferable to sayNpotentialcomplexpoints of failure, because the probability of complex point failure is more than three times that of a simple point failure.Here, using the secondary chip allows keeping the bootloader completely separate from the application on the main MCU. During normal operation, the bootloader is not on the main MCU at all; it is only loaded during firmware updates. This simplifies thingsa lot. Really, it boils down to how robust can you make the bootloader MCU and main MCU communications, the part that loads the firmware updater program to the main MCU RAM, and the firmware updater itself.Unfortunately, I do not have enough design or practical implementation experience to say whether that simplification is more significant than the number of added possible failure points. It just depends too much on the practical implementation.

author: nctnico
author_rank: Super Contributor
timestamp: September 23, 2024, 12:11:12 pm
content: Quote from: mikeselectricstuff on September 23, 2024, 11:24:50 amYes. And you can have some protection in software as well. In a recent implementation I did I put a small layer on top of the flash which divides the flash into sections: bootloader, running image, update image. The bootloader can only update the running image from the update image. The running image can only write to the update image. Neither bootloader or running image can write to the bootloader.

author: fchk
author_rank: Frequent Contributor
timestamp: September 23, 2024, 12:14:02 pm
content: Quote from: peter-h on September 23, 2024, 09:42:00 amI'd use the ROM bootloader and reserve JTAG/SWD for development only. You would have the option to disable SWD while keeping the non-brickable update. Plus the bootloader is easier to use.

author: peter-h
author_rank: Super Contributor
timestamp: September 23, 2024, 01:05:36 pm
content: I tend to agree - because a 2nd CPU which controls /NRST and BOOTx pins should always be able to wake up the 1st CPU, since the factory bootloader cannot be corrupted.Well, in reality the factory bootloader is almost certainly in FLASH as well, but with an undocumented way of reprogrammingI mentioned SWD earlier because - short of somebody having set RDP2 - it will always be able to bring up the CPU into a known state.And if the firmware contains code for setting RDP2 then the risk goes way up. Ideally, RDP2 should be selected only in the factory (ST Utility or whatever it is called now, has a tab for the various option bytes) and not in the firmware.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 24, 2024, 10:11:35 am
content: Don't forget that the ST's bootloader is a mysterious black box outside of your control. It might have bugs that pop up in some rare edge cases triggered by... something. And it's also subject of random changes between batches of chips. I'm specifically concerned on the mechanisms inside the ST's code which decide which interface they try to listen to. That could be triggered from some other peripheral (e.g. I2C/UART) pins having some unlucky activity. Say, some timing thing that after a certain delay after NRST some I2C device does something that causes the bootloader to enter I2C mode and stop listening to your desired SPI upgrade path. And maybe that never happens at lab, but with some oscillator start-up time changing or temperature shift or whatever now it starts to repeatedly happen at a customer -> device effectively bricked. And as your 2nd MCU is locked-down design you can't do anything about it, even if fix was simple in a lab.I'm not saying failure islikelybut we are talking aboutprovingthe non-brickability, and the alternative scheme was dismissed because some very improbable failure pattern (runaway PC hittingexactlyafter the function address input validation) to begin with, so I'm a bit sceptical this interface-to-ST-bootloader being any more robust than the usual single-chip single-bootloader solution.I'm always worried when some relatively simple and easily analyzable failure mode is replaced by a lot of extra complexity and unknowns.

author: peter-h
author_rank: Super Contributor
timestamp: September 24, 2024, 10:49:24 am
content: QuoteJust looked it up in the bootloader appnotehttps://www.st.com/resource/en/application_note/an2606-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdfThe 417 and 437 (I am using both of these) both look for 0x7f on either usart1 or usart3, and this is sufficient to make it look for the rest of the data. I am curious about what happens if a peripheral is not used, due to a lack of package pins. Its clock should not be enabled, obviously. In my project usart1 and 3 are both used but e.g. usart 4 and 5 are not. Now what happens if somebody is not using usart1. Could its RX pin be floating? Hopefully not!I am not using the factory boot loader but I agree there are lots of funny gotchas. Especially as ST change the way it works (though perhaps not for the uarts).

author: asmi
author_rank: Super Contributor
timestamp: September 24, 2024, 02:28:40 pm
content: Quote from: peter-h on September 23, 2024, 06:53:24 amThat actually makes the problem worse as you now have 2 different firmwares to manage and upgrade.The proper way to implement is to use a write-protected golden image (most QSPI flash devices allow to write-protect a portion of entire array), plus one/two/however-many-you-want update "slots" so that these new slots are attempted first, and "golden" image is only booted if new images fail to boot.

author: JPortici
author_rank: Super Contributor
timestamp: September 24, 2024, 02:37:44 pm
content: Quote from: Psi on September 23, 2024, 07:49:13 amI keep asking myself the same. I had to do a CAN bootloader once, then i went on reading other manufacturers, looking for inspiration. I stumbled upon thevariousST Bootloader APIs and i decided to look no more and do my own, again. It was as if CAN didn't define already in the standard a way to handle multipacket transactions (CAN-TP) and they had to make the most basic, stupid protocol they could think ofThen as other mentioned, by trusting the manufacturer provided bootloader you end up relying on a black box. Good luck. Your own bootloader has your own bugs, true, but also your own features.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 24, 2024, 03:07:14 pm
content: Quote from: JPortici on September 24, 2024, 02:37:44 pmHeh, last time I did a upgrade-by-CAN thing on STM32 I also thought about taking a look at ST's own bootloader. After all, it could be handy - maybe I could save time and find some command line tool already written by someone else.Go figure. ST thought that they don't have enough different protocols already and had a shiny new protocol on H7 series back then, not compatible with any existing code. And most funnily, the protocol was FD-only, so unable to flash the device using standard CAN frames. I didn't even have a CANFD adapter back then at my disposal. What do you need to smoke to come up with this kind of design limitation?The simple USART bootloader I have used a lot, but then again it also requires forking some of the many tool projects and making modifications in their codebases. Or use some Windows tool from ST. What PITA. Just simpler to decide on your own protocol and do both sides at once.

author: peter-h
author_rank: Super Contributor
timestamp: September 24, 2024, 03:15:25 pm
content: One advantage of the factory loader is that it "cannot" be corrupted by a runaway program.You can write protect your own loader (sitting at 0x08000000) but equally rogue code can remove that protection - unless the codes to do that are not present in your code

author: Siwastaja
author_rank: Super Contributor
timestamp: September 24, 2024, 03:19:46 pm
content: ... or just put a little bit of thinking how to protect the code parts that modify flash from things like Program Counter corruption/runaway or jumping to random function pointers. Just good old input validation on the function which does the write is 99.99% foolproof against those, you would need to accidentally jump at a very specific location with the accuracy of a few instructions, easy to do maliciously but very unlikely to happen by accident.

author: peter-h
author_rank: Super Contributor
timestamp: September 24, 2024, 03:53:12 pm
content: Well... the case I mentioned of the 28C256 EEPROM getting corrupted was on a box which a customer installed next to the piezo igniter of some huge industrial boiler. The stuff should have gone into a metal box, shielded cables, etc, but evidently not. So spikes reaching PCB tracks (via EM, or conducted via wires) crashed the CPU repeatedly, and eventually it did, evidently, execute the EEPROM write functionThere was a MAX706 hardware watchdog (1.6 sec fixed) but it didn't help.The product has been selling since 1995 and is super solid, zero bugs ever found, except for this one customer."Very unlikely"? Not if a bunch of your customers start controlling piezo igniters with your boxOne lesson - apart from customer education - is to avoid your firmware containing the magic unlock codes. Not always possible though. My firmware does not contain the RDP2 codes (depending on details, a great way to f**k your company if those got executed) but it does unavoidably contain codes for writing CPU FLASH (in the RAM loader for fw updates), codes for writing the Adesto SPI FLASH, etc.Thinking about it, one could wrap the FLASH write code with a GPIO pin test, and have a jumper in there. That would stop a runaway PC. But very inconvenient.

author: nctnico
author_rank: Super Contributor
timestamp: September 24, 2024, 04:25:43 pm
content: I have had similar issues a long time ago (back in the 8051 days). A protection scheme like the flash section layer I described earlier, fixed those problems. The closer the check is to the actual write action in code, the less likely you'll have unwanted write actions.Input checking in general is a very powerful way to halt rogue execution.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 24, 2024, 04:32:04 pm
content: Quote from: peter-h on September 24, 2024, 03:53:12 pmIf this is what you fear then surely this on-PCB exposed interface of NRST and SPI is orders of magnitude more likely to generate a valid programming pattern from EMI, than EMI coupling to inside of STM32 chip and corrupting Program Counter to hit within a few instructions of the 4 gigabyte address space. Specifically SPI is quite susceptible since it lacks UART-like filtration.You are just painting yourself deeper in the corner. In reality, you won't be hit by a corrupted PC. You will be hit by any other type of bug that can sneak in within the added firmware(s) of additional management devices and third party black boxes. Replacing an EMI resilient solution by one more affected by EMI because you fear EMI is ridiculous when at the same time you add more surface to other types of bugs, too.

author: nctnico
author_rank: Super Contributor
timestamp: September 24, 2024, 05:14:20 pm
content: Quote from: peter-h on September 24, 2024, 03:53:12 pmThe main question is: has this product been tested for CE compliance including immunity, surge and ESD? And how far did it got tested beyond the required limits? For consumer devices the immunity test level is like 3V/m for example. In my experience this is too low for a product to be reliable when deployed in the field. My preference is to get to at least 20V/m (with and without modulation) which shouldn't cause any problems (except for ethernet links going down). ESD is similar. Step it up a few kV over the limit during pre-compliance testing to see how much margin there is.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 24, 2024, 05:21:12 pm
content: Yeah and old designs with CPUs and memories on parallel buses on PCBs, especially when just 2-layer, are quite susceptible to EMI. Comparing that to similar corruption happening inside a single microcontroller chip is far-fetched. If even that is of concern, I would recommend looking at higher end safety-critical microcontrollers, like those used in automotive brake systems etc., but this is where my expertise stops so I'll let others give further recommendations.

author: peter-h
author_rank: Super Contributor
timestamp: September 24, 2024, 06:44:52 pm
content: Yes - CE tested of course, by multiple customer labs and a "proper" lab.It means very little. It's just an arbitrary figure. Something could produce 100V/m.That design runs code from the EEPROM, so there you go... a 32F4 uC should be way better.

author: JPortici
author_rank: Super Contributor
timestamp: September 25, 2024, 05:29:57 am
content: Quote from: peter-h on September 24, 2024, 03:15:25 pmwhich can't happen if the main program can't modify flash, or if any access (read/write/execute) from the application to the "boot" partition (however it's called on your microcontroller of choice, even PIC16 have it now) raises a security exception. True, F4 is old and may lack such feature

author: Siwastaja
author_rank: Super Contributor
timestamp: September 25, 2024, 06:04:00 am
content: As the threat model is EMI coupling inside the chip and corrupting internal CPU registers such as PC, usage of STM32F4 is wrong choice anyway, having no per-sector write-once flash locking fuses is least of the concerns. peter-h needs to look at some high reliability automotive or probably aerospace grade rad hard devices.

author: pcprogrammer
author_rank: Super Contributor
timestamp: September 25, 2024, 06:29:10 am
content: I don't know, certainly not an expert, but is it not possible that bits in a FLASH or EEPROM flip due to EMI?If so the only safe solution would be to have a bootloader in a mask programmed ROM. Without support to boot from an external memory not possible on lots of MCU's, which leads to the need to look for MCU's that do support this.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 25, 2024, 06:49:37 am
content: Quote from: pcprogrammer on September 25, 2024, 06:29:10 amNo, not really, in the context we are talking about.I mean, if you are developing an EMP device or something then surely you will be able to flip bits inside of FLASH. But for any legal device on market accessible to normal fields of industry this is not the case.And then of course bits can flip on their own without any EMI. This is called "reliability" and can be measured e.g. by metrics like MTBF. Every component has some failure rate.But if you expose a SPI bus on a PCB and do poor job on layout (e.g. lacking ground plane) then it's pretty easy to get data corruption from simple EMI. This is what needs to be tested at labs but as nctnico points out lab testing is not a guarantee of never having a problem, you may want to voluntarily test to higher standards.

author: peter-h
author_rank: Super Contributor
timestamp: September 25, 2024, 07:45:52 am
content: As I wrote, the EMC issue was probably corrupted program data being fetched from the EEPROM chip. Or anything else picked up on PCB tracks. This cannot be handled by software design. You need a shielded box!The point of my example was to show that a runaway PCcanbe created if you crash the CPU enough times and in enough random ways. Not different to the RDP cracking schemes actually - another recent thread! They put spikes on VCC, basically, and move them relative to the clock, with picosecond resolution, until they get lucky.All my CPU boards are 4 layer, 2 planes.

author: DavidAlfa
author_rank: Super Contributor
timestamp: September 25, 2024, 09:38:16 pm
content: Readan2606, that's all the embedded bootloader can do, no magic tricks.Either make your own bootloader or use a 2nd mcu like stated by others.Quote from: peter-h on September 24, 2024, 10:49:24 amNot that simple. You won't randomly perform erase or write operations, the frames have checksum, ack/nak, not in a million years it'll pick random noise and do something.an3155

author: peter-h
author_rank: Super Contributor
timestamp: September 25, 2024, 10:17:26 pm
content: Yes; I forgot. This came up in that "breaking RDP2" thread, where the VCC pulsing method was used to execute the memory read command in the boot loader.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 26, 2024, 06:38:27 am
content: Quote from: DavidAlfa on September 25, 2024, 09:38:16 pm... except if it has bug. And the point is moot anyway. Remember, in peter-h's scenario the threat model was EMI couplinginsidethe chip and corrupting program counter. It can as well happen to the 2nd MCU, jumping into the ST bootloader ofthat, right into handling an erase command, and wiping the 2nd MCU out. And I'm quite sure ST has not done any attempts to "rad-hard" the code of their bootloader, why should they. If you write your own bootloader, it is then at least possible to do very local error checking andnearlyeliminate runaway PC issues.But the main issue is peter-h's excessive threat model. ST very likely ignores the possibility of internal PC corruption, and that's a sane thing to do for a product line like this.And my point about the interface noise is that it is enough to pick up repeatedly that 0x7f on either UART. It won't erase anything, but it locks out and is therefore effectively bricked. If this is non-user accessible (no one to power cycle it), then one random noise event is enough.

author: peter-h
author_rank: Super Contributor
timestamp: September 26, 2024, 06:45:10 am
content: QuoteNo. Read again. It would be very hard to get EMIinsidea chip.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 26, 2024, 08:04:23 am
content: Quote from: peter-h on September 26, 2024, 06:45:10 amThat's what I have been saying all along, yet you bring the example of EMI coupling into external EEPROM bus causing wrong code to be run as some kind of example that same could happen within a single STM32 and jumping in the middle of flash code, writing to bootloader area. I don't think it's a valid concern at all: as I have been saying, just protect the flash erase/write operations by making them functions and adding input argument verification and you are as safe as it gets. Sure you can't prove it's 100% non-brickable but you can't prove any other solution either and I'm pretty sure every attempt to fix this by making things more complicated and adding second MCUs are only going to further increase risk of bricking, possibly significantly, for reasons already mentioned.

author: nctnico
author_rank: Super Contributor
timestamp: September 26, 2024, 04:05:31 pm
content: Quote from: peter-h on September 26, 2024, 06:45:10 amBut not impossible. At some point I designed a 1000W DC-DC converter and put a temperature sensor chip next to the switching transistors. With the converter on, the temperature measurement where allover the place. At first I expected the SPI bus but that was working just fine (I routed these on an inner layer as a precaution). The chip itself just stopped working (Microchip, no surprise).More recently I tested a camera product at 50V/m for radiated immunity; without any light, the interference patterns showed up at some frequencies in the noise coming from the image sensor.

author: peter-h
author_rank: Super Contributor
timestamp: September 26, 2024, 09:02:35 pm
content: The point was made in some article I read on EMC that the bigger pin count packages are worse because they have much longer bonding wires.Funny how far off topic we have gotThere is no way to make a 32F4 self load from an SPI FLASH.