Can't examine high-cycle data flash on STM32H573

[dliebler]

I finally got to testing this.
Regarding the memory calculations:
The sector allocation for less than 8 high cycle seems to be fine.
But it is still a bit more complicated. 2M/1M Devices behave a little bit different to the 512k/256k Devices.
I have made a list of all the h5 devices here:
                        Start Flash1  Start Flash2  Sector F1   Sector F2   HC Sector1  HC Sector2
H503 : 128kB Flash      0x0800 0000   0x0801 0000   <------- NO HIGH CYCLE FLASH SUPPORT ------->
H523 : 256kB Flash      0x0800 0000   0x0802 0000   0-15        2000-2015   24-31       2024-2031
H523 : 512kB Flash      0x0800 0000   0x0804 0000   0-31        2000-2031   24-31       2024-2031
H533 : 512kB Flash      0x0800 0000   0x0804 0000   0-31        2000-2031   24-31       2024-2031
H562 : 1024kB Flash     0x0800 0000   0x0808 0000   0-63        2000-2063   120-127     2120-2127
H562 : 2048kB Flash     0x0800 0000   0x0810 0000   0-127       2000-2127   120-127     2120-2127
H563 : 1024kB Flash     0x0800 0000   0x0808 0000   0-63        2000-2063   120-127     2120-2127
H563 : 2048kB Flash     0x0800 0000   0x0810 0000   0-127       2000-2127   120-127     2120-2127
H573 : 2048kB Flash     0x0800 0000   0x0810 0000   0-127       2000-2127   120-127     2120-2127

You can also find this information in RM0481 7.3.10 on page 262-263.

I have attached a modified script which takes this into account as well.
With this, I tested it with the H563(2M) and the test project from earlier. It worked for both tests. Thats great!

I also tried to test it with a H533(512k), but the script crashes in line 83: 

Code:

_n_throw(intrfApi.readMem32(0x08fff80c))

I don't understand why this happens. With STM32cube programmer, I can read this address(flash size) and it is correctly reported as 0x00000200.
The H533 has a STLink V3J13M4 (should be latest)
But at the same time, I also didn't find any information about _n_throw() and intrfApi.readMem32(), so maybe one of them has other side-effects. Do you have an idea what could cause this?

And another thing, the H503 doesn't support HC at all, i think this also has to be addressed. do you want to split the script file into different scripts for H50x and H5xx or handle it all in one script?

[embitz]

I will look into it. I have only one H5 board so I can not test the smaller devices.

_n_throw is a build-in script function:

Code:

_n_throw(v) {
  if( v < 0)  throw(v)
}

EBlink uses negative numbers for errors and -1 (ERROR_NOTIFIED) is reserved for errors that have already been reported to the user.

Is it sure that all those devices are using the same address to report flash size?

Yes, I would like to keep everything in one file. We now also check if HC is enabled and otherwise we skip it in the memory map because the length of those sections are zero.

BTW
I released EBlink 5.30 with a lot of fixes (increased bandwidth/speed)

[dliebler]

Ok, I managed to extract the error-code. But I was still testing with 5.20. I will install 5.30 and also try it. Maybe it fixes the problem as well.
But with 5.20, most of the times, eblink reports an error -102 which is probably INTERFACE_ERROR?
Do we have more methods available to check where this INTERFACE_ERROR stems from?(Verbose Levels/Logs?)
Is it maybe correlated to the occurences of STLINK_SWD_AP_WDATA_ERROR?
EBLink-Log with verbose 8:

Code:

"C:/Program Files (x86)/EBlink/win32/eblink.exe" -I stlink -S stm32 -P "C:/Program Files (x86)/EBlink/scripts" -G s,nc -v 8


EBlink version 5.20-[197] by Gerard Zagema

Using EB_SCRIPT_PATH = C:\Program Files (x86)\EBlink\scripts

Interface      : STlink
Device found at bus 2:16
Interface USB# : 005100333133511635333335
Interface at  2:16 - <BUS>:<ADDR>
Interface type : STlink/V3
STlink Frmware : V3.J13.M4
Target voltage : 3.29V
Interface speed: 24000KHz
Try DAP_AP 0.
STlink open DAP_AP 0
Read CPU id on DAP_AP 0
STLINK_SWD_AP_WDATA_ERROR
STlink close DAP_AP 0
Try DAP_AP 1.
STlink open DAP_AP 1
Read CPU id on DAP_AP 1
CPU id found (0x410FD214)
Target selected: Cortex-M
Target detected: Cortex-M33 (r0p4) with FPv5_SP
HW breakpoints : 8
HW watchpoints : 4
Fault unwind   : Active break (level 2)
Search script stm32.script in path: C:/Program Files (x86)/EBlink/scripts
Script found: stm32.script
STLINK_SWD_AP_WDATA_ERROR
STLINK_SWD_AP_WDATA_ERROR
STmicro device : 0x478
STmicro cpu : M33
STmicro device : 0x478
STmicro script : h5
Required script load: stmicro/stm32h5.script
Search script stmicro/stm32h5.script in path: C:/Program Files (x86)/EBlink/scripts
Script found: stmicro/stm32h5.script
STLINK_SWD_AP_WDATA_ERROR
unknown error -102         //I added this line in stm32.script main() to read the value of e.
Error:  Can't access target device!
        If reset is disabled ("dr" option), try with reset.STlink close DAP_AP 1

I got it to run one time past that error, but then it hung somewhere later in the process.
But I could not reproduce that one time.

The 533 and the 56x/57x share the same manual, so yes, they both store the flash size in that register.
I confirmed it with the stm32Cubeprogrammer, the flash size is stored in that register.

[dliebler]

I tested it now with eblink 5.30.
First, it still didn't work.

But I tried now to connect via jtag. This works with the new scripts.
I don't know, maybe there is a problem with the combination between swd, eblink and my board?

SWD with the STM32CubeProgrammer works, but with eblink, I can only get a working connection via jtag.
I think without the source code I am not able to dig deeper into this issue. But do you have any idea where this issue could stem from?
I don't expect my board to be faulty, but I cant exclude it.

[embitz]

That error is coming from STlink. We don't know why it fails.
It is just a normal memory read like all other devices. Is there an errata about this issue?  Is Cube working around a problem?
Perhaps that register needs to be accessed by a different AP?

What you could do ( what I would do) is looking with wireshark and sniff the USB to see what the differences are between both devices. I have a Luna to make the parsing a bit understandable.

I will see if I can get my hands on a board with this device.

Added:

That -102 is an interface error. Perhaps you could place some printf's in the script to see which where it goes wrong.

[dliebler]

Yes, I already used printf's to track it down to the read on 0x08fff80c. I also didn't identify any relevant errata.

But today, I cant reproduce it to fail anymore like it did yesterday...
To me, it seems like an error depending on some weird interaction.

I don't think you need to put extra effort into getting your hands on such a device, it will probably be very difficult to reproduce this on your end.

CubeProgrammer was always getting somehow through. I have not tried CubeIDE.
I will try to reproduce the error and try to get my hands on a wireshark protocol of the error.
But until I think we can regard this issue as solved until I am able to reproduce it.
The new scripts look good and the remaining issue is probably not an issue with the scripts.

[embitz]

Ok

[Aroyer]

Hi,

I'm working with the STM32H5 with ST-Link.
At home I use Embitz but at the job it's VSCode


Just to let you know, we had a lot of problem connecting to the STM32H5.
now it is fixed..

Did you connect the pin JTDO-SWO to the CPU
and
# Access port number required to debug on STM32H5 devices (port 0 will not work)
set AP_NUM 1

I hope this might help

[dliebler]

Yes, I encountered this, too. But eblink is aware of this. Eblink first checks AP0. This fails, so it retries with AP1.
With -G ap=1 you can configure eblink to directly check AP1. I tried it, but since eblink already works without setting the AP, it didn't change much.

But if you want to use stlink-gdbserver, you have to set the AP to get it to work.

And regarding the JTDO-SWO: I am using a Nucleo board, so this is already wired.
Also, I was trying to connect via SWD, so shouldn't JTDO and SWO be irrelevant for the basic debugging without SWO?

Btw: I am running VSCode with Cortex-Debug and Eblink, so let me know if you encounter any issues with the h5 in the future.

[embitz]

But it is strange that only one member of that H5 family is acting differently.
I'm testing it here with the H563 and  that is working. There is a difference between those two devices.

For the discovery of the H5 I'm using the same approach as The Cube Programmer.