2025-02-24 3:01 PM
I have on my desk an STM32F407 Discovery board and an STM32U083 Nucleo board. My intent is to write software for the F407 to bootload the U083 via I2C. As far as I can tell, these are the general steps:
Problem is, I can't even seem to do step 1. I have a logic analyzer verifying NRST and BOOT0 at the U083 chip, but regardless of the state of BOOT0, if I reset the U083, it boots from flash (i.e. I see my debug output on the UART).
Looking at RM0503, section 2.5 Boot configuration, Table 6 Boot modes, there are two ways to boot into system memory. Summarizing the table's logic conditions:
Here are the option bytes and their factory default values:
BOOT_LOCK, naturally, defaults to 0, so that's fine. But all of the other bits default to 1, including nBOOT_SEL, which needs to be 0 to allow BOOT0 to do, well, anything.
Am I correct in that it's not possible to bootload a U083 device via I2C unless you've touched it at least once with a programmer and cleared the nBOOT_SEL bit? (If so, that's extremely annoying for our rev. A prototype.)
Dana M.
2025-02-24 3:23 PM
Some STM32 models have special device to allow first time programming by the built-in bootloader: if the user flash is "empty" (few first bytes are 0xFF) the MCU starts the built-in bootloader no matter what is state of BOOT0. Test whether your U0's behave this way.
2025-02-24 3:55 PM
As @Pavel A. suggests, the chip will boot into the bootloader if flash is erased. Per AN2606, relevant table entry for STM32U071 is Pattern 11. Third match is what happens on a fresh chip.
2025-02-25 8:38 AM - edited 2025-02-25 8:39 AM
... those sneaky gits. They updated the app note.
AN2606 revision 63/64 (I have a partial printed copy here):
AN2606 revision 65 (February 14, 2025):
Reading the revision notes, apparently this rates as "Minor text edits across the whole document". However... I'm not convinced it was a correction. If I chip erase my U083 Nucleo, put nBOOT_SEL back to 1 (as it would be from the factory), and then try to engage the bootloader, I still can't do it; I get NAKs on I2C. If I set nBOOT_SEL to 0 and retry, I get the bootloader version just fine.
So I guess my question now is... was ST correct the first time, and the U083/U073 really is Pattern 15, with no allowance for empty flash? Or am I still doing something wrong? A chip erase via ST/LINK is all that's needed to qualify as "empty flash", yes?
Dana M.
2025-02-25 8:57 AM
Pretty sure the "flash erase check" is done on power-on, not at reset, and requires a power cycle to refresh. Just erasing won't trigger it.
2025-02-25 9:02 AM
Yeah, still doesn't work after a full erase and power cycle. I think ST made a mistake, and it really is Pattern 15, not Pattern 11. Does ST read these forums, or do I need to file a ticket somewhere?
Dana M.
2025-02-26 8:30 PM
OK, after further testing, I am confident that the STM32U073CC does NOT conform to Pattern 11, as shown above by @TDK in revision 65 of AN2606. Specifically, I have a board here with one main controller (STM32F407) and eight U073 devices. We touched the first U073 with a programmer, cleared the nBOOT_SEL option bit, and programmed firmware into it. But the other seven U073 devices are untouched. I am unable to invoke the bootloader on any of the "untouched" U073 devices; only the one where we have cleared the nBOOT_SEL bit. We have another board where we used gold needle probes to connect an ST/LINK and clear the nBOOT_SEL option bit on all the U073 devices, and I can invoke the bootloader on every U073 on that board.
ST, it is factually incorrect to state that if flash is blank on a U073 and the option bits are in a factory state, the BOOT0 pin can be used to invoke the bootloader. I believe you were right the first time (revision 64 and earlier) when you tagged the U083 family as being Pattern 15, not Pattern 11. There does not appear to be any allowance for empty flash on these U073 devices on this board.
ST, please confirm that you made a mistake in rev 65 of AN2606 and that U073/U083 devices are Pattern 15, not Pattern 11. Thanks.
Dana M.
2025-02-26 8:39 PM
@Amel NASRI or @mƎALLEm could you take a look?
2025-02-28 1:35 AM
Hello,
Internal ticket 204219 opened for follow-up. Not accessible by the community users.