Hi. I have been trying to flash an STM32L152RD (STM32L1xxxD) using the CUBE programmer through the USART2 and it never connects (Timeout error occured while waiting for acknowledgement). I have used the software method of branching into the bootloade

[JBaue.1]

Because I do not have access to the BOOT0 pin (custom board, not eval board) I have used the software method of branching into the bootloader : https://stm32f4-discovery.net/2017/04/tutorial-jump-system-memory-software-stm32/

I have adpted this code for the device (notably bootloader address 0x1FF0 0000)

USART2 physical pins are PA2 and 3

My questions are:

1. Is the bootloader code listening to USART2, is it listening to everything? Or does this require a specific configuration?
2. Do I need to configure the USART2 with baudrate etc. before jumping to the bootlaoder so that it corresponds to the CUBE->UART settings or is this an automatic process?

____

logs from Cube

15:59:33:510 : Serial Port COM34 is successfully opened.

15:59:33:511 : Port configuration: parity = even, baudrate = 115200, data-bit = 8, stop-bit = 1.0, flow-control = off

15:59:33:511 : No Init bits value is : 0 

15:59:33:511 : Sending init command: 

15:59:33:511 : byte 0x7F sent successfully to target

15:59:34:511 : Wait ends after 1 loop, dataready = 0, delay = 1001

15:59:34:511 : Timeout error occured while waiting for acknowledgement.

15:59:34:512 : No response from target received

15:59:34:519 : byte 0x7F sent successfully to target

15:59:34:621 : Wait ends after 1 loop, dataready = 0, delay = 100

15:59:34:621 : Timeout error occured while waiting for acknowledgement.

15:59:34:621 : No response from target received

15:59:34:621 : Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again...

Any help is appreciated, thank-you!

[TDK]

If you jump into the bootloader directly after reset, or in a state where clocks/peripherals are at their reset values, the bootloader will listen on all support interfaces and will respond to the first one that sends a message. No additional configuration needed.

If you have a scope, I would look at the signals on the line. Possibly try using a lower baud rate as well.

Next time just add a debug port to your board. It's a headache without one and a productivity drain.

[Tesla DeLorean]

Got anything chattering on USART1? Or other used pins?

Doesn't it expect USART2 signals to be on PD5/PD6?

AN2606 https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf

[Tesla DeLorean]

I think you're going to need to write your own loader in the front few KB of the L151

Using a protocol like X-Modem allows more commonly available terminal applications to push new binaries into the device.

[JBaue.1]

Thanks so much for the rapid replies.

I am not sure where the issue is. I am using the L152RD eval project IAP (which was TrueStudio) then I imported it into CubeIDE. Therefore I have 2 projects, my app code and the IAP. The final objective is to be able to flash the app code when it is broken. Originally my design was a 2 app combo with a jump from IAP to the app if upgrade not needed. That was before I realized that the IAP/ymodem upgrade is not what I need. Now I am using the IAP app just to test the upgrade mechanism via USART2. It took quite a while to modify the original project to get USART2 up and running (basically a call to clock it was missing because the original code uses USART1). Therefore I have a skeleton IAP app that can do I/O through USART2. Now I need the bootloader part so that it can dialog with any standard flash tool (CubeProgrammer, st-link, whatever).

There is no possibility to "add a debug port" because this is a qualified finished production board.

Yes Tesla, but my debug/interface port is on PA2 and 3. (USART2 has several mappings).

It is possible but unlikely that the issue could be that the eval true studio code conversion to cube caused a problem (my app uses the HAL interface and the eval project uses the StdPeriph_Driver.

Other musings:

• having st-link interface connected interferes with bootloader "finding" USART2 (yet I power it off during testing)
• I have, using the debugger, verified that I am in the bootloader code (PC>0x1FF00000). But I think the debugger loads RAM and not the flash so that is not conclusive?
• Problem with clock set-up before jumping to bootloader (HSI clock is required) is:

#if defined(USE_HAL_DRIVER)
 HAL_RCC_DeInit();
#endif /* defined(USE_HAL_DRIVER) */
#if defined(USE_STDPERIPH_DRIVER)
 RCC_DeInit();
#endif /* defined(USE_STDPERIPH_DRIVER) */

sufficient to remove previous clock settings and therefore default to HSI?

My next steps;

• O-scope on the USART2/PA2/PA3 pins to observe trafic
• Changing my app to do the branch to the bootloader (not using the IAP app at all)

I'll let you know ...

Thanks for your help

[TDK]

I think you're missing what @Community member​  is saying.

> Yes Tesla, but my debug/interface port is on PA2 and 3. (USART2 has several mappings).

This was doomed at the start. The USART2 bootloader isn't on PA2/PA3, it doesn't matter if those pins can be used by USART2 if the bootloader isn't listening on them.

 

> this is a qualified finished production board.

Didn't anyone qualify the bootloader interface?

[JBaue.1]

Tesla DeLorean I think you are right about the PD5/6 pins and this is why the "standard" bootloader is not talking to CubeProgrammer. I have provoked bootloader execution by clearing the flash and pulling the BOOT0 pin high (in this case it is available but in final package it is not). And still no COM on USART2 PA2/3. I think the pre-installed bootloader only listens to PA10/11 USART1 and PD5/6 USART2.

For making my own bootloader I see 2 options, IAP/y-modem protocol and stm32 bootloader x-modem. Do you have a recommendation? And is the host side software available also or is this limited to teraterm settings?

Thanks again for your help!

[JBaue.1]

TDK Yes you are right, therefore I will have to code a bootloader myself that talks to those pins until we do a re-design of our board. Thanks again for your help!

[JBaue.1]

"Didn't anyone qualify the bootloader interface?" lol, I am a software guy, you know what hardware designers say "Fix it in software!"

[JBaue.1]

I have now flashed using IAP with the USART2 mapped to PA2/3, no issues. My app at 0x80004000 (2 changes, FLASH_BASE and ld file).

Thanks for your help Tesla and TDK, greatly appreciated,

jcb

[Tesla DeLorean]

I use Clear Terminal (was Connex, but now under Telit), I like the X-Modem-1K implementation. I have target and host side implementations of the algo.

On the L151 boards I have, I'm staging the new firmware in the upper portion of the internal Flash and I can trigger the app to copy a small loader to RAM and overwrite itself. Living on the edge, but it only initiates if the image is valid, and I have other ways to debrick. I don't recall the exact size of the loader, but could likely do it in 512-1024 bytes if pushed.