2023-03-02 03:02 AM
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
2023-03-27 09:00 AM
Hi,
I see the same with the 2.13.0 version of the software.
Have you managed to fix it?
2023-03-27 02:28 PM
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 :\
2023-03-28 04:35 AM
Just removed as not relevant.
2023-03-28 04:39 AM
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).
2023-03-28 04:44 AM
OK. I misunderstood it.
2023-05-10 11:06 AM
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.