cancel
Showing results for 
Search instead for 
Did you mean: 

Is there any problem when boot0 pin is floating?

KKIM.6
Senior

Unfortunately, I wrongly designed the PCB board So, the boot0 pin is currently floating (no connectable evenif temporaliy because of BGA pin layout).

I'm getting trouble with programming. So,

I want to know whether the programming error is happening due to the boot0 pin.

Is there any problem when boot0 pin is floating?

1 ACCEPTED SOLUTION

Accepted Solutions

I think the pin state issue can be addressed with suitable configuration of the option bytes.

I think the debugger issue can be resolved with a debug script, or walking some configurations, mappings, and vector table address, such that the primary code of interest runs under the debugger.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

8 REPLIES 8
Peter BENSCH
ST Employee

BOOT0 must have a fixed logical potential and is normally connected via a resistor or, if necessary, directly to GND. With a floating BOOT0, the pin would read in unforeseen random states during power-up.

Regards

/Peter

In order 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.

In most STM32 designs, ie those lacking specific control via the Option Bytes, floating BOOT0 will result in unpredictable operation related to start-up and supply rise times.

Usually a pull-down facilitates predictable operation, and the ability to control the state on a programming or test fixture.

The STM32WB looks to allow for programability via the option bytes, but you'll need to ensure that occurs because it's not the default state of the options.

Large related thread on this topic https://community.st.com/s/question/0D53W00001rBMwiSAG/break-at-address-0x1fff5e8c-with-no-debug-information-available-or-outside-of-program-code-error

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

I will order new PCB board but I also don't want to waste time. 

So, I need to sure all the problem happens due to the boot0 pin.

Currently, my design can make manual drill beneath the boot0 pin if I sacrifice Tx pin.

I'll try this one. 

But before doing this, I tried apply positive bias on the TX pin to induce negative bias on the boot0 pin using capacitive charging. (becasue TX pin is currenly passing beneth the boot0 pin) and I can start debug using SWD and STM32CubeIDE.

But still, My programming has same error issue like below and the microcontroller only works one time and do not do next cycle (Turn-on GPIO pin and ADC start, send DMA data through USART). After restarting, still the microcontroller doesn't work properly.

"Break at address "0x1fff5ee0" with no debug information available, or outside of program code."

I think this problem happen due to not only on the PCB layout, but also in the programming.

Is there any idea on this and do yo know how to solve the above issue?

I'm currently using STM32WB55VGYTR6 microcontroller and programming it using ST-LINK inside the Neucleo-WB55 board.

I will order new PCB board but I also don't want to waste time. 

So, I need to be sure all the problem happens due to the boot0 pin.

Currently, my design can make manual drill beneath the boot0 pin if I sacrifice Tx pin.

I'll try this one. 

But before doing this, I tried to apply positive bias on the TX pin to induce negative bias on the boot0 pin using capacitive charging. (becasue TX pin is currenly passing beneth the boot0 pin) and I can start debugging using SWD and STM32CubeIDE.

But still, My programming has the same error issue like below and the microcontroller only works one time and does not do next cycle (Turn-on GPIO pin and ADC start, send DMA data through USART). After restarting, still the microcontroller doesn't work properly.

"Break at address "0x1fff5ee0" with no debug information available, or outside of program code."

**This problem is what you are already commenting many times in another session.

I think this problem happens not only in the PCB layout but also in the programming.

Is there any idea on this and do you know how to solve the above issue?

I'm currently using the STM32WB55VGYTR6 microcontroller and programming it using ST-LINK inside the Nucleo-WB55 board.

I think the pin state issue can be addressed with suitable configuration of the option bytes.

I think the debugger issue can be resolved with a debug script, or walking some configurations, mappings, and vector table address, such that the primary code of interest runs under the debugger.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

It's more of a VIL/VIH threshold for a floating signal at whatever voltage the CMOS MCU becomes viable.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

I can start programming the microcontroller.

I tried to use the internal clock of the microcontroller and it worked.

And then, I tried programming it using the external clock and it also worked.

So, I don't know why it doesn't work before.

Maybe, there was an initialization problem.

Still, my board has the floating boot1 pin but it is working well.

Thanks, man.

I feel a need to reply to this thread.

I have a custom PCB using STM32L432KB. I forgot to tie PH3 low, it floats.

I experienced this pain,  but a strange variant of it. Sadly I debugged it myself over a few hours before finding this thread...

The weird thing for me was that it would boot and run and get to the while(1) loop in CUBEIDE, and then it would loop around a bunch of times hitting a breakpoint on __NOP(); but as soon as I let it run free, it would go to a system memory address and cease to respond to the SWD, even to reset.

 

Since it was hitting a system memory address, I concluded it was some oddity with the floating break zero and set the option byte for nSWBOOT0 (unchecked in Cube Programmer).

This solved all the issues.

The bizarre thing was that it was booting from flash memory into my program and starting execution before breaking to the bootloader (system memory). This, I do not understand. There was no brownout or other obvious cause of reset - I reduced my program to literally booting and going to

while(1){__NOP();)}

with a few __NOP()s before the while 1 to break onto if it was indeed bugging and resetting for some reason (it was not) 

No peripherals atall enabled and an internal MSI clock at 72MHz.

Any idea why this would be? No big deal now I know how to fix it on both proto boards and on the final rev, but bleurgh.

 

DMolo_0-1708991205307.png