2020-04-22 09:18 AM
I am attempting to activate the bootloader mode on the STM32G050J6 (SO8N package). It is unclear to me from the documentation which pins are to be used. Currently, I am using pins 1 and 8 (USART1_RX and USART1_TX in the documentation respectively) as USART pins. Additionally, I am using pin 8 as BOOT0 pin. So what I do is as follows:
Then when I attempt at activating the bootloader through the STM32CubeProgrammer app, I get an error saying that the program did not receive an acknowledge and the bootloader could not be activated.
Alternatively, I have access to a ST-LINK v2 device. My objective really is to program the micro and be able to use UART, but the UART pins conflict with the SWD pins.
2020-04-23 12:01 PM
Hi,
according to AN2606 (STM32 microcontroller system memory boot mode) on STM32G03xxx You can use for UART bootloader on pins PA9/PA10 for USART1 or PA2/PA3 for USART2. So in Your case it should be USART1 on PA9 (TX) and PA10 (RX).
I hope it is clear now. Have a nice day.
2020-04-24 12:00 AM
Hi Tomas,
Yes I had seen that on the document, however, there was a little confusion on my side as to which physical pins actually mapped to those PA9 and PA10. Turns out it's pins 5 and 6 on the SO8N package. I subsequently managed to access the bootloader and upload a program that way.
However, after doing so I am no longer able to access the bootloader. Whenever I reset the chip while holding BOOT0 high, the chip just seems to run the main program I uploaded. I've also tried to hold BOOT0 low and reset, but with the same result.
In the meantime, I found out that I should be able to use my ST-LINK with the mode "Connect under reset" to program the chip that way even though the SWD pins are reassigned after reset. I will report back with my results.
2020-04-24 12:33 AM
I can confirm that using the "Connect under reset" option with a ST-LINK device works. I connect 3v3, GND, SWDIO and SWCLK to my microcontroller and hold nRST low as I press "connect" in the STM32 ST-LINK utiliy. I then "quickly" pull nRST high and the program is able to detect the device.
I'd till be curious to know why I can no longer access the UART bootloader.
2020-04-24 01:30 AM
Hi @Tomas SIRUCEK ,
Have you actually tried?
IMO the bootloader won't work on the remapped PA9/PA10 (i.e. on PA11/PA12 in the non-remapped, after-reset state), and the non-remapped "genuine" PA9/PA10 are not available on the SO-8 nor TSSOP-20 packages.
JW
2020-04-24 01:33 AM
@Community member I have actually tried that. I managed to upload a program by connecting my UART adapter to pins 5 and 6, which map to PA9 and PA10. Although now after uploading the first program, I can no longer activate the bootloader and I was curious if anyone knows why.
2020-04-24 01:45 AM
Hi @Community member ,
Yes I tried and it works. Bootloader FW is remapping those pins to PA9/PA10.
Have a nice day.
2020-04-24 01:55 AM
Hi,
I would guess, You had empty memory, when You tried first. So Bootloader was activated because of empty memory and not BOOT pin state. Try to connect with ST-Link via STM32CubeProgrammer and check option bytes. ST default production value for nBOOT_SEL is 1, which means it is by default ignoring BOOT0 pin and takes signal from nBOOT0 bit in Option bytes. For more information about Option bytes please check reference manual, section 3.4. FLASH option bytes.
If You will change nBOOT_SEL value to 0, You can then use BOOT0 pin again.
I hope it is clear now. Have a nice day.
2020-04-24 03:59 AM
Hi @Tomas SIRUCEK .
Thanks for the info.
Does this apply also to the TSSOP-20 package?
And what about the larger packages, where both the "native" and "remapped" PA9/PA10 are present? What's the exact behaviour there?
IMO this ought to be described in the respective chapter of AN2606.
JW
2020-04-24 06:50 AM
I can confirm this.
Using the ST-LINK utility, I connected the target with the previously described "connect under reset" method. Then I opened the dialog Target -> Option bytes and found that nBOOT_SEL was checked, meaning that the state of the BOOT0 pin is ignored and the activation of the bootloader is determined by the state of the nBOOT0 bit (3 positions above nBOOT_SEL in the picture), which is checked, meaning the bootloader will not be activated.
Thank you all for the help.