Skip to main content
E
erincyldz
Associate III
January 25, 2024
Solved

STM32F407 pulls up pins when debugging

  • January 25, 2024
  • 4 replies
  • 2601 views

Hello people, i am making a project using STM32F407VG and i am using a timer that drives a laser. The problem is, when debugging STM is probably pulling couple of its pins to High state before i start F8 (between pressing the 'Debug' button and F8 to stop the program waiting at HAL_Init() function after i run the code it switches back to LOW state ) and messes up with my laser circuit. I want to know which pins go to High state and why, and see if i can control it i really have to deny it pulling to high state. Thanks for the help. Have a great day !  

Best answer by TDK

No, there is no way to change the default pin states upon reset.

4 replies

TDK
TDK
Super User
January 25, 2024

A few pins are initialized as debug pins by default, but the vast majority of pins are initialized as input.

Which pins are you having issues with? Pins that are not in input mode after reset are PA13, PA14, PA15, PB3, PB4.

"If you feel a post has answered your question, please click ""Accept as Solution""."
    S
    Sarra.S
    ST Employee
    January 25, 2024

    This is typically due to the default configuration of these pins under reset or during boot

    If you are using JTAG for example, JTAG pins maintain their pull-up and pull-down resistor settings even under reset

     

    To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
      E
      erincyldzAuthor
      Associate III
      January 25, 2024

      is there any way to control this? i am using SW debug btw

      TDK
      TDKAnswer
      Super User
      January 25, 2024

      No, there is no way to change the default pin states upon reset.

      "If you feel a post has answered your question, please click ""Accept as Solution""."
        Tesla DeLorean
        Tesla DeLorean
        Guru
        January 25, 2024

        Probably going to need some better interlock / fail-safe mechanisms, so that dead-stopping in debug, fault or watch-dog conditions don't cause dangerous conditions to occur or persist.

        Watch also what DBGMCU does with suspending TIM, clocks, etc.

        Have your system be aware it's running under a debugger.

        Might also look under the MOTORs sections / docs as this might address similar situations

        Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
          Michal Dudka
          Michal Dudka
          Lead
          January 25, 2024

          How do you control state of used GPIOs when they are not initialised (MCU in reset state, or starting up) ? Are they equiped with some external pulldowns or left floating ?

          Andrew Neil
          Andrew Neil
          Super User
          January 25, 2024
          @Michal Dudka wrote:

          How do you control state of used GPIOs when they are not initialised (MCU in reset state, or starting up) ? 

          You can't - the reset state is defined by the hardware.

          As others have already said, most GPIOs default to being inputs.

          For full details, see the datasheet.

          A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
          Michal Dudka
          Michal Dudka
          Lead
          January 25, 2024

          Of course i can. For example by external pull-up/pull-down resistors. By my qustion i only want to rule out the possibility that his "laser control output" is left floating during reset/startup. Because in that case it can reach any value, due static charge, or by its "load" and can be misinterpreted as MCU intentional action.

            Terms & ConditionsAccessibility statement