Erase sectors problem - frame data send (UART connection mode)

[Aelavin]

Platform: Windows 11 22H2 (x64)

CubeProgrammer version: 2.12

After updating CubeProgrammer from 2.6 to 2.12 we end up with issues where selecting sectors to erase does not work with UART connection mode. What we observed is that program sends wrong data.

We're using custom bootloader but its functioning was made in line with ST documentation (AN3155) and was verified to work with STM32CubeProgrammer in version 2.6.

Example:

What I want to do: Erase single sector '17' (0x11)

Version 2.6:

Frame: 0x001111

Version 2.12:

Frame: 0x01118696

According to documentation first byte should be "number of sectors to erase - 1", so for 1 sector it should be '0'. Looking at logs from CubeProgrammer (2.12) it sends 1 extra sector and what's more it's a sector that does not exist.

Below small snippet from logs from CubeProgrammer (2.12):

11:46:46:713 : Flash sector erase ... 
 11:46:46:713 : Sending Erase command and its XOR:
 11:46:46:714 : byte 0x43 sent successfully to target
 11:46:46:714 : bytesToWrite before send = 1 
 11:46:46:714 : bFlushRet = 1, bytesToWrite after flush() = 1 
 11:46:47:712 : waitForBytesWritten Error : Upłynął limit czasu operacji oczekiwania.
 11:46:47:842 : byte 0xBC sent successfully to target
 11:46:47:848 : Wait ends after 1 loop, dataready = 1, delay = 10
 11:46:47:848 : Received response from target: 0x79
 11:46:47:848 : Sending sectors codes to be erased and their checksum:
 11:46:47:849 : data sent successfully to target: 0x01118696

Looks like something has been messed up between versions.

We've updated CubeProgrammer to latest version (2.13) and the problem still exists.

Below logs after connecting (I don't think it is a problem with data sent from our devices):

11:57:41 : UR connection mode is defined with the HWrst reset mode
 11:57:42 : RTS low
 11:57:42 : DTR low
 11:57:42 : Serial Port COM23 is successfully opened.
 11:57:42 : Port configuration: parity = even, baudrate = 115200, data-bit = 8, stop-bit = 1.0, flow-control = off
 11:57:42 : Activating device: OK
 11:57:42 : Board : --
 11:57:42 : Chip ID: 0x419 
 11:57:42 : BootLoader protocol version: 1.1
 11:57:44 : UPLOADING OPTION BYTES DATA ...
 11:57:44 : Bank : 0x00
 11:57:44 : Address : 0x1fffc000
 11:57:44 : Size : 16 Bytes
 11:57:44 : Bank : 0x01
 11:57:44 : Address : 0x1ffec008
 11:57:44 : Size : 8 Bytes
 11:57:44 : UPLOADING ...
 11:57:44 : Size : 1024 Bytes
 11:57:44 : Address : 0x8000000
 11:57:44 : Read progress:
 11:57:46 : Data read successfully

[Bogdan Golab]

Hi,

I see the same with the 2.13.0 version of the software.

Have you managed to fix it?

[Aelavin]

No, still using older version that actually works (2.6).

Our updater software uses same protocol (and CubeProgrammer was used to verify if it is compatible) so seeing that newer Programmer is broken is a little bit sad. Even in ST's protocol documentation such behaviour/change is not described so I think we should count it as a bug. But like You can see nobody from ST is interested with this bug :\

[Bogdan Golab]

Just removed as not relevant.

[Aelavin]

Well, my problem does not refers to problem ST-LINK (those works fine for most of the time). I have problem with UART connection (which does not require using ST-LINK).

[Bogdan Golab]

OK. I misunderstood it.

[AVish.2]

Another message about this error:

https://community.st.com/s/question/0D53W00002FbLNvSAN/stm32cubeprogrammer-page-erase-error

PS. Yes, this is a real bug: Bootloader (STM32F103) really erases wrong sectors.