Hi,
Attached a new EBlink 5.20. It is unsigned and just for testing. This version has some bug fixes and also a new reset strategy. I noticed that when the H5 was in sticky error state, EBlink couldn't release it. I copied the release strategy of the CubeProgrammer. I first had to write a wireshark luna script to get some understanding what Cube is doing.
Also a preliminary version for the new stm32h5 script file. I hope you can check it because i'm not that familiar with these devices.
I think the memory calculations are perhaps not correct. I don't exactly what happens with the main memory flash sizes when other sector allocation numbers are used instead of 8 for high cycle.
Note:
This EBlink is always trying to get memory requests with the most possible access width possible. Older STlink firmware didn't supported 16bit access so two 8 bit accesses are used. Be sure that your firmware is not too old
The release version will also print the info as sections so that multi-core is a bit easier to read.
Attached a new EBlink 5.20. It is unsigned and just for testing. This version has some bug fixes and also a new reset strategy. I noticed that when the H5 was in sticky error state, EBlink couldn't release it. I copied the release strategy of the CubeProgrammer. I first had to write a wireshark luna script to get some understanding what Cube is doing.
Also a preliminary version for the new stm32h5 script file. I hope you can check it because i'm not that familiar with these devices.
I think the memory calculations are perhaps not correct. I don't exactly what happens with the main memory flash sizes when other sector allocation numbers are used instead of 8 for high cycle.
Note:
This EBlink is always trying to get memory requests with the most possible access width possible. Older STlink firmware didn't supported 16bit access so two 8 bit accesses are used. Be sure that your firmware is not too old
The release version will also print the info as sections so that multi-core is a bit easier to read.