I am designing a PCB-Shield that uses the STM32L412CBU6 (without external crystal). This PCB is connected to another STM32 platform. I want to be able to flash the STM32L412CBU6 from within the other platform. I have already a I2C connection from one platform to the other, and I thought about having two more connections between those boards:

  • one to put the BOOT0-PIN high
  • one to toggle NRST-PIN to be able to perform a user-program flash via the internal (ROM) bootloader.

With that in mind, I was reading the documents AN2606 (system memory boot mode) and AN4221 (I2C bootloader protocol definition) and for sure the one for the controller itself "STM32L412xx".

I would like to ask, if I got things right:

  1. When the STM32L412CBU6 boots from system memory (its bootloader), I have to take care, that the hardware resources it uses are not making any electrical problems on my PCB. As this bootloader supports flashing from USART 1, 2 and 3, IC2 1, 2 and 3, SPI 1 and 2 and USB, there are actually something about 22 PINs it handles. Most likely they are not critical - but I have to recheck those PINs.
  2. As per Datasheet AN2606 the I2C3 bootloader uses I2C3_SCL pin and I2C3_SDA pin. In my case (STM32L412CBU6), this would be PIN PA7 and PB4, but the document writes PC0 and PC1 (you can have I2Cx on different PIN-Pairs), which are not present on UFQFPN48 package. If I understand this right, it just means, that the I2C3 bootloader will not be present/accessible on my package. There are no different bootloaders for different packages. Right?

1 Answer 1

  1. Correct. You can't have anything connected on those pins under normal mode, that would conflict the bootloader use. And vice versa, you can't have anything connected that would get disturbed by the bootloader mode. For example, some pins turn into outputs under bootloader. So there can be nothing driving against those outputs if they are inputs under normal use. The outputs and their state should be tolerated by the rest of the circuit, so you can't have these outputs accidentally turn on or off any circuits that should be in some safe state. And some pins are inputs that must be at some defined state, or at least they must not toggle, so care must be taken that e.g. pushbuttons, pull resistors or other circuits don't accidentally trigger a wrong bootloader interface instead of the one you want.

  2. Yes if the MCU package does not have the mentioned pins then you don't have that interface as the pins are missing. The AN2606 will tell what the pin names are.

  • \$\begingroup\$ Thanks for the review. That's a lot of PINs to take care about... Can I assume: - if I pull (for example) the SPI1_NSS pin low, that the bootloader will not occupy the other SPI1 Pins (because this interface is not active)? - there is actually no "real" output pin... not something driving current. Most Pins which are declared as an output pin have something like "Used in input pull-up mode". Actually I have no clue what it means when they have an output pin with comment: "Used in input no pull mode." (USART_TX). If the pin is in input mode, and no pull, how can it get HIGH? \$\endgroup\$
    – STeVe
    Dec 5, 2022 at 19:19
  • \$\begingroup\$ It does not really go into that deep knowledge. For example UART TXD would be an output, but is it configured at bootloader start or after bootloader has determined which specific UART will be used. Same for SPI, NSS low will activate the SPI interface, but is the MISO set to output after that SPI interface has been selected as boot interface. You need to figure it out. My experience is not for this chip, and those chips set all UART TXDs as output (I happen to have a LED on one bootloader TXD and it lights up so definitely an output). \$\endgroup\$
    – Justme
    Dec 5, 2022 at 20:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.