2018-01-03 10:25 AM
Posted on January 03, 2018 at 19:25
I recently had a problem in one of our designs that was caused by assigning a GPIO with an external pull-up to PB2 on an STM32F413. It turns out that this pin has the additional function of being BOOT1, so the pullup caused the MCU to be unable to enter the system bootloader mode. I use CubeMX to plan my pin assignments, and this additional function isn't indicated anywhere in the user interface. Yes, I probably should have caught this by cross-referencing the report with the datasheet, but this is definitely an area where CubeMX should be able to help me out.
st.mcu
‌ can you please pass this feedback on to the CubeMX team?
2018-01-04 02:06 AM
Hi
Kisiel.Kamil
,I agree with you that BOOT1 pin has to be mentioned in CubeMX. Thanks for bringing this issue to our attention, we will take care of fixing it.
However, I don't understand how pulling-up PB2 leads to enter the system bootloader mode.
Based on RM0430 and AN2606, bootloader is activated if Boot0(pin) = 1 and Boot1(pin) = 0.
In your case, if BOOT1 is pulled up and BOOT0 is already 1, then you will boot from Embedded SRAM. In such case, pay attention to relocate the vector table in SRAM.
If your need to boot from flash in your application, BOOT0 has to be set to 0. BOOT1 value will not matter then.
-Amel
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.
2018-01-04 04:35 AM
Think he says he CAN'T get into the System Loader, not that it does.
2018-01-04 09:08 AM
Yes exactly. We have a boot switch on the BOOT0 pin to enable the bootloader, but it's causing a boot to embedded SRAM instead.
2018-01-04 09:21 AM
Yes, right. Re-reading the sentence, it is 'UNable'.
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.
2018-01-04 09:39 AM
The trick might be to remap the memory and jump to the System Loader. I'd dig up a thread but the forum is broken currently.
2018-01-04 09:55 AM
It's ok, we need to spin another rev of the board for other reasons anyway so I'm just going to move that function to another free pin.
2018-01-04 01:48 PM
I verified the issue (lack of indication of BOOTx function) on a few MCU.
For some MCU which have dedicated pin for BOOTx function (STM32F030F4, STM32F103C8) this label is shown in the GUI.
In the case of this MCU the BOOT1 function is shared with other PIN functionalities (GPIO, etc) and BOOT1 is not shown. On the other hand the BOOT0 function is dedicated to the pin (not shared) and is shown in the GUI.
It looks like a bug in CubeMX code and I think it should be fixed because of consequences during the design process when you are unaware of BOOTx functionality (assumed that the CubeMX is definitive source of information of pin functionality allocation).
2018-03-06 02:07 AM
Hello
Kisiel.Kamil
,Regarding the pinout config, the data sheet is our reference. If you have a look to the data sheet for the STM32F413 (
http://www.st.com/en/microcontrollers/stm32f413vh.html
), the PB2 pin is named PB2 and has BOOT1 as additional functions :So, the name of this pin is correct on CubeMX and you can find the information of where Boot1 is mapped with the data sheet.
For other MCUs as STM32F469, the name of the PB2 is PB2_BOOT1 as seen in the data sheet :
I hope I have answered your question.
BR. Jeanne
2018-03-06 11:58 AM
No, this absolutely does not address the issue. Look at this screenshot from CubeMX:
Nowhere does it indicate that PB2 has an additional function of being the BOOT1 pin. If you click on a pin which also serves as an ADC input (which is an additional function) that's indicated in the popup menu. But there's absolutely no indication that PB2 also serves as BOOT1. Yes, this can be looked up in the datasheet, but the purpose of the software is to assist you in the design of a pinout for the processor and it's omitting crucial information.