Skip to main content
J
jt94093
Visitor II
August 27, 2025
Solved

Is SPI MISO tristated with NSS high when STM32U575 is in bootloader mode?

  • August 27, 2025
  • 2 replies
  • 401 views

I am using the STM32U575 on a custom board and see that AN2606 indicates PG10 becomes a SPI MISO output in bootloader mode. I would like to connect this same SPI port to another device with the STM32 in master mode for the user application. In order to avoid contention on this signal, I am hoping that in bootloader mode the SPI MISO output is tri-stated if the associated NSS is negated (high). I have seen a couple of posts that touch on this question but I have not been able to confirm the behavior. For example:

https://community.st.com/t5/stm32-mcus-products/spi-pin-states-during-bootloader-detection-phase/m-p/696205

Another post for a different part mentions that the SPI port can be setup to support multiple slaves by tri-stating MISO when not selected, but I don't know if this is the default behavior in bootloader mode for this device.

Thank you for any feedback.   -Jason

    This topic has been closed for replies.
    Best answer by waclawek.jan

    The state of various pins in bootloader is documented poorly.

    In some STM32 it's known that the bootloader pulls the SPI-bootloader-MISO pins hard immediately upon bootloader entry, regardless of whether given interface is or is not used during bootloading. I'm not sure if the related NSS is active but I believe it is. According to AN2606 NSS is weakly pulled internally down, so you'd need to pull it externally up, to avoid MISO being actively pulled.

    You can actually debug the bootloader, even if there are no sources available, and thus observe the state of relevant GPIO and SPI registers yourself.

    JW

     

    2 replies

    W
    waclawek.janAnswer
    Super User
    August 27, 2025

    The state of various pins in bootloader is documented poorly.

    In some STM32 it's known that the bootloader pulls the SPI-bootloader-MISO pins hard immediately upon bootloader entry, regardless of whether given interface is or is not used during bootloading. I'm not sure if the related NSS is active but I believe it is. According to AN2606 NSS is weakly pulled internally down, so you'd need to pull it externally up, to avoid MISO being actively pulled.

    You can actually debug the bootloader, even if there are no sources available, and thus observe the state of relevant GPIO and SPI registers yourself.

    JW

     

    J
    jt94093Author
    Visitor II
    August 27, 2025

    Thank you for the prompt reply and the note about the NSS weak pulldown. I agree that observation of actual HW tends to be the most reliable approach. Unfortunately I don't have the time to observe or debug the behavior on an eval board.

     

    I am going to  wait a bit to see if anyone has additional feedback, then I will mark your reply as the solution.

     

    I do find it a bit odd that the part would be designed in such a way that it contends with a SPI slave on any of the SPI ports, given the undesirable effects of the HW options for dealing with that.

     

    Regards  -Jason

    W
    waclawek.jan
    Super User
    August 27, 2025

    It is what it is.

    I am not ST and cannot explain their design decisions. In many cases it's better to use a custom bootloader exactly because of the limitations and unwanted/poorly documented details of the behaviour of the default one.

    JW

    Terms & ConditionsAccessibility statement