cancel
Showing results for 
Search instead for 
Did you mean: 

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

Aelavin
Associate II

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

6 REPLIES 6

Hi,

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

Have you managed to fix it?

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 :\

Just removed as not relevant.

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).

OK. I misunderstood it.

AVish.2
Associate II

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.