Need help with CubeProgrammer CLI syntax

[NArnd]

Hello,

STM32L4+, CubeProgrammer 2.21, ST-Link V2, Windows 10

I need to do:

* Full flash erase

* Write Application image (.hex or .bin)

* Write Bootloader image (.hex or .bin)

* Set RDP level 1

* Start the application at the Bootloader start address.

-

I am successfully doing this with the CubeProgrammer GUI, but I fail to get it to work with CLI.

The "-e all" command works and says "Mass erase successfully achieved":

C:\"Program Files"\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe -c port=SWD ap=0 -e all

-

However, I have tried numerous variants of the following command (and its separate parts alone) without success:

C:\"Program Files"\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe -c port=SWD freq=3900 ap=0 -e all -w C:\SVN\Path\More_path\hex\Application.elf -w C:\SVN\Path\More_path\hex\Bootloader.hex -ob rdp=0xBB -s 0x08000000

I have also tried with .bin files and their respective start addresses.

The only response I get is the header:

-------------------------------------------------------------------
STM32CubeProgrammer v2.21.0
-------------------------------------------------------------------

-

The command "-c port=SWD freq=3900 ap=0 -s 0x08000000" gives a complete (failure) response:

-------------------------------------------------------------------
STM32CubeProgrammer v2.21.0
-------------------------------------------------------------------

ST-LINK SN : 36FF6C064D59303612251543
ST-LINK FW : V2J46S7
Board : --
Voltage : 3.17V
SWD freq : 1800 KHz
Connect mode: Normal
Reset mode : Software reset
Device ID : 0x470
Revision ID : Rev V
Device name : STM32L4Rxxx/STM32L4Sxxx
Flash size : 2 MBytes
Device type : MCU
Device CPU : Cortex-M4
BL Version : 0x95
Debug in Low Power mode enabled

RUNNING Program ...
Address: : 0x8000000
Warning: failed to run application!
Warning: The core is kept under Reset!
Error: Start operation failed

-

I have tried to find a tutorial or a list of CLI command examples but um2237 is a wee bit brief and I haven't found much on the internet.

Grateful for your input.

BR

Niclas

 

 

[TDK]

> I need to do:

> * Full flash erase

> * Write Application image (.hex or .bin)

> * Write Bootloader image (.hex or bin)

> * Set RDP level 1

> * Start the application at the Bootloader start address.

It's not possible to do the last step. You can't run flash in RDP 1 in debug mode. The chip needs to boot up normally.

[NArnd]

Thank you TDK,

So, I need to do:

> * Full flash erase

> * Write Application image (.hex or .bin)

> * Write Bootloader image (.hex or bin)

> * Start the application at the Bootloader start address.

This works in the STM32CubeProgrammer 2.21.0 GUI. (And setting RDP to level 1 as an individual step.)

The log from the GUI using JLINK (omitting the RDP change) is:

11:24:13 : UR connection mode is defined with the SWrst reset mode
11:24:13 : 506000727
11:24:13 : Device=Cortex-M4
11:24:13 : Device ID : 0x470
11:24:13 : Voltage : 3.26V
11:24:13 : UPLOADING OPTION BYTES DATA ...
11:24:13 : Bank : 0x00
11:24:13 : Address : 0x40022020
11:24:13 : Size : 20 Bytes
11:24:13 : Bank : 0x01
11:24:13 : Address : 0x40022044
11:24:13 : Size : 16 Bytes
11:24:13 : UPLOADING ...
11:24:13 : Size : 1024 Bytes
11:24:13 : Address : 0x8000000
11:24:13 : Read progress:
11:24:13 : Data read successfully
11:24:13 : Time elapsed during the read operation is: 00:00:00.012
11:24:17 : Opening and parsing file: Application.elf
11:24:17 : Memory Programming ...
11:24:17 : File : Application.elf
11:24:17 : Size : 513.84 KB
11:24:17 : Address : 0x08009000
11:24:17 : Erasing memory corresponding to segment 0:
11:24:17 : Erasing internal memory sectors [9 137]
11:24:20 : Download in Progress:
11:24:31 : File download complete
11:24:31 : Time elapsed during download operation: 00:00:13.552
11:24:37 : Opening and parsing file: Bootloader.elf
11:24:37 : Memory Programming ...
11:24:37 : File : Bootloader.elf
11:24:37 : Size : 93.74 KB
11:24:37 : Address : 0x08000000
11:24:37 : Erasing memory corresponding to segment 0:
11:24:37 : Erasing internal memory sectors [0 2]
11:24:37 : Erasing memory corresponding to segment 1:
11:24:37 : Erasing internal memory sector 3
11:24:37 : Erasing memory corresponding to segment 2:
11:24:37 : Erasing internal memory sectors [256 277]
11:24:38 : Download in Progress:
11:24:40 : File download complete
11:24:40 : Time elapsed during download operation: 00:00:02.785
11:24:40 : RUNNING Program ...
11:24:40 : Address: : 0x08000000
11:24:40 : Application is running, Please Hold on...
11:24:40 : Start operation achieved successfully
11:24:53 : Disconnected from device.

It should be mentioned that both when using ST-Link V2 and JLINK Ultra+, I now sometimes need to do the above procedure twice to get it to actually succeed with "Run after programming".

-

I've continued testing various approaches with CLI without success:

* CubeProgrammer 2.17.0, 2.20.0, and 2.21.0 with ST-Link v2 (latest FW)

* .elf (with and without address) and .bin, .hex, and .srec with address

* Segger JLINK ULTRA+ (latest FW)

* Files generated by CubeIDE 2.0.0 in both debug config (debug level 3, no optimization) and release (no debug info, optimization for size)

The common behaviour is that the commands that don't involve -w seem to be accepted and processed.

-

Just issuing

C:\"Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe"

doesn't respond at all (although some internet sources claim that this should respond with a list of possible actions).

 

 

[NArnd]

The MCU is STM32L4S7ZIT6.

[NArnd]

A minor correction:

In one of my previous posts I wrote:

"It should be mentioned that both when using ST-Link V2 and JLINK Ultra+, I now sometimes need to do the above procedure twice to get it to actually succeed with "Run after programming"."

This appears not to be an issue when programming a completely new MCU.

---

Additional information:

(Please excuse the bad readability. It is for some weird reason not possible to post text with consecutive white space characters and it automatically changes font back from Courier New...)

The FLASH memory layout is:

* Flash 0x0800 0000 - 0x081F FFFF
* Start addr End addr Length #Pages Phys page range Use
* 0x0800 0000 - 0x0800 2FFF 12 K 3 0 - 2 bank 1 Bootloader execution area
*
* 0x0800 3000 - 0x0800 3FFF 4 K 1 3 bank 1 Flash layout table page
* 0x0800 4000 - 0x0800 7FFF 16 K 4 4 - 7 bank 1 Bootloader storage area
* 0x0800 8000 - 0x0800 8FFF 4 K 1 8 bank 1 FW upgrade status page
*
* 0x0800 9000 - 0x080C 0FFF 800 K 200 9 - 208 bank 1 Application execution area
*
* 0x080D 1000 - 0x080F FFFF 188 K 47 209 - 255 bank 1 Unused
* 0x0810 0000 - 0x0813 7FFF 224 K 56 0 - 55 bank 2 Device table area
*
* 0x0813 8000 - 0x081F FFFF 800 K 200 56 - 255 bank 2 Application storage area

 

[NArnd]

The Application project (and hex file) contains the code for the Application execution area.

The Bootloader project (and hex file) contains the code for the Bootloader execution area, the Flash layout table page, and the Device table area.

The Bootloader storage area, FW upgrade status page, Unused, and Application storage area are not included in either of the hex files. 

[Aziz BRIGUI]

Hi @NArnd,

What I recommend is to split the CLI instructions by functionality. Thanks to Hotplug mode, you'll be able to connect without a reset interfering in MCU operation. Here's a snippet below:

#Erase all
STM32_Programmer_CLI -c port=SWD -e all
#Program bootloader binary
STM32_Programmer_CLI -c port=SWD mode=hotplug -w bootloader.elf
#Program application binary
STM32_Programmer_CLI -c port=SWD mode=hotplug -w application.elf
#Set RDP to 1
STM32_Programmer_CLI -c port=SWD mode=hotplug -ob RDP=0xBB

One clarification to keep in mind regarding RDP 1, if boot is from flash and your bootloader is @0x08000000, it should run normally (in user mode) => It's valid to set RDP to 1 at the end of the sequence, just make sure you're booting from flash and not system memory or SRAM.

Hope you find this helpful.

Aziz

[NArnd]

Hi Aziz,

I'm afraid your CLI commands don't work for me. The problem is the same as described above.

---

#Erase all works (like before):
C:\"Program Files"\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe -c port=SWD -e all

-------------------------------------------------------------------
STM32CubeProgrammer v2.21.0
-------------------------------------------------------------------

ST-LINK SN : 36FF6C064D59303612251543
ST-LINK FW : V2J46S7
Board : --
Voltage : 2.93V
SWD freq : 4000 KHz
Connect mode: Normal
Reset mode : Software reset
Device ID : 0x470
Revision ID : Rev V
Device name : STM32L4Rxxx/STM32L4Sxxx
Flash size : 2 MBytes
Device type : MCU
Device CPU : Cortex-M4
BL Version : 0x95
Debug in Low Power mode enabled

Mass erase ...

Mass erase successfully achieved

----

#Program application binary doesn't work (and neither does its bootloader counterpart:
C:\"Program Files"\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe -c port=SWD mode=hotplug -w C:\SVN\XXXXX\Xxxxx_3\SW\Xxxxx3_ws\Application\Debug\Application.elf

-------------------------------------------------------------------
STM32CubeProgrammer v2.21.0
-------------------------------------------------------------------

That's all it outputs. I have also tried this with J-Link (-c port=JLINK) with the same output (which for erase is less verbose with J-Link).

===

It appears this is a bug or lack of support in STM32CubeProgrammer.

Based on previous experience:

Up until a few versions ago of CubeIDE, Debug probe ST-LINK GDB server didn't work with my flash layout. At that time I didn't have a J-Link so I don't know if that was supported and worked, but ST-LINK OpenOCD worked. At some point ST-LINK GDB server was fixed/improved, so now all three Debug probe options work.

My guess is that CubeProgrammer needs the same fix/improvement as ST-LINK GDB server.

I cannot send you our .elf files, but your colleague M B has my contact details for collaboration on further investigation and testing.

Best regards

Niclas

[NArnd]

Thank you Aziz,

This looks like the information i need. I will test it and report back

Best regards

Niclas

 

 

[Ozone]

> * Write Application image (.hex or .bin)
> * Write Bootloader image (.hex or .bin)

I would recommend to merge these two into one file, preferably HEX or SREC format.
These files contain target addresses for each line, and can even be merged by hand.
And your bootloader and application code do surely not overlap.

[NArnd]

Thank you Ozone,

I suppose your suggestion makes sense if you have a high volume and rarely change the hex file content.

CubeIDE outputs the two .elf files we need, so with a .bat file it should be very simple to write one after the other.

Best regards

Niclas

 

[Ozone]

Well, ELF files are a bit different, and more complex.
I don't think they can be merged so easily, and by hand.

If ou look at a SREC (a.k.a. S19) file OTOH, they are quite simple and line-based.
For me (us), both use cases are relevent. We publish the application alone for device updates, and a bootloader / application merge file for the PCB manufacturer.
BTW, there is even a nice tool available to do a merge from commandline, e.g. from a batch / script file :   https://srecord.sourceforge.net/

 

[TDK]

One wonders what sort of tomfoolery is going on inside STM32CubeProgrammer that it fails to parse this correctly. Is it reconstructing the path and then trying to re-parse it to get the parameters?

It is a parsing issue, but not a Windows command line parsing issue. That part works.

[NArnd]

Thank you TDK,

Windows Command Prompt syntax has never been one of my areas of interest, so I was thinking maybe I had made a mistake. What an unnecessary waste of customer time...

So, now we know that it can be done and that ST is aware of their parser error. Hopefully this means that they will also fix it. (?)

-

Regarding the suspected issue with resetting the MCU after RDP is set to 1:

I'll try the following:

With my ST-Link V2 I use an Olimex adapter board to connect to the 10-pin Cortex M debug pin header on the device:

https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-20-10/

Rev C of this board has a footprint for a tactile reset switch. The Olimex product page has a photo of Rev A, but I attach a photo of Rev C.

Here is a link to a document from ARM (?) that present the various ARM-standard headers:

https://documentation-service.arm.com/static/5fce6c49e167456a35b36af1

The tactile switch is an 1185AU2 J-bent:

http://www.ilswitch.com/pdf/Tact/1185.pdf

The closest I have found that I can buy are these two (CIT CS1213BJF160 / CS1213BJF260):

https://www.digikey.se/sv/products/detail/cit-relay-and-switch/CS1213BJF160/16607697

https://www.digikey.se/sv/products/detail/cit-relay-and-switch/CS1213BJF260/16607813

I hope this will help others in a similar situation.

 

[NArnd]

Unfortunately, the RESET switch approach doesn't work when an RDP level change is done.

The Option bytes must be re-read and re-loaded, which happens at a Power On Reset (POR) or when bit FLASH->CR OBL_LAUNCH is set. The latter is not accessible via SWD/JTAG after RDP has been changed to 0xBB or 0xCC.

There is hope that a usable sequence can be achieved by changing RDP to 0xBB and setting bit FLASH->CR OBL_LAUNCH from program code.