FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

STM32G070RB: Flash booting over USART1 (PA9, PA10) , Boot0 (PA14), NRST

ARost.1
Associate

‎2019-09-16 06:35 AM

We developed a product which uses STM32F series and everything works fine. For some reason, we need to swap the F serie to G serie for future products.

Unfortunately, we do not manage to flash the virgin device (STM32G070CBT6) through USART1 (PA9/PA10) using stm32flash. The error message says "failed to init device". We also tried to write to the option bytes (address 0 x 1FFF 7800) so that the boot is targeting the System Memory, but doing this results in the same error message. So here are the questions:

  1. What is the proper timing and correct "enter bootloader mode" sequence for NRST, PA14-BOOT0-pin before sending the first byte over USART1 (PA9 and PA10)? Currently we use NRST-low, BOOTpin-high, NRST-high, run stm32flash, NRST-low, BOOTpin-low, NRST-high with 1s delay between each action.
  2. At this point, we are not sure if the pins we are toggling are configured to listen to that function. In stm32 G series, the boot pin is now merged with SWDCLK pin and the function is selectable through the nBOOT_sel register. How can the register be set if we are not able to program the device yet?
  3. We detected an issue with the shared pin BOOT0 / SWDCLK. BOOT0 is either driven by our HOST-CPU or the JTAG-debugger. We need to cut the connection in order to run either. Can you please provide us a schematic in order to be able to use it at the same time?

Any other suggestions that might alleviate the problem?

Thanks a lot in advance

Astrid

1 REPLY 1
ARost.1
Associate

‎2019-10-08 04:21 AM

Hello,

Not that many answers on this board.

  1. I think our timing was OK - if we pick a new board we are able to enter the boot-loader mode and get an answer. Still it seems to answer only with baudrate=57600. Any idea why?
  2. It is possible to make with srecord a small build (1 word) and write 0x1FFF7800 with 0xdeffe1aa. We read the value back - the data was the same as before, except for the one bit. After an additional reset, we are able to flash. In case we flash without setting the bit before- the board is dead and can only be accessed by a debugger. If the second flash fails, we require a power reset (reset pin is not enough.
  3. I am not sure why, but some boards seem to be read protected after this sequence. Reading out FLASH_OPTR.RDP, the flags show AA (Level 0). It seems to be possible to put it through the JTAG into Level 1 mode and then back to Level 0 mode. in order to clear the read/ write protection. Do you have any idea why this happened? By writing the flag twice? We have only written 0xdeffe1aa to 0x1FFF7800. Is there any way to put the device back to factory default in case we have run the sequence incorrectly?

Thanks

Astrid

0 Kudos
Related Content
Top