Examine high-cycle flash STM32H573 [solved]

[dliebler]

I am working with a STM32H563ZI currently.
This device also has a high-cycle flash.

The memory region for the high-cycle flash is located from 0x09000000 and can only be accessed by 16-bit or by 32-bit.
8-bit reads to this addresses are not allowed.

Now the problem is, I cant examine this memory via eblink. I tested the exact same configuration with eblink and with stlink-gdbserver.

eblink:

Code:

x/1xb 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000
x/1xh 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000
x/1xw 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000
x/1xg 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000

stlink-gdbserver:

Code:

x/1xb 0x09000000
0x9000000:    
Cannot access memory at address 0x9000000
x/1xh 0x09000000
0x9000000:    0x1e0f
x/1xw 0x09000000
0x9000000:    0x3c2d1e0f
x/1xg 0x09000000
0x9000000:    0x78695a4b3c2d1e0f

As you can see, stlink-gdbserver is able to examine the memory as long as I dont make it read only one byte.
But eblink is not able to examine it at all. I suspect eblink treats every memory access as byte reads?
Is this the intended behavior?

This is not an important bug to me, I can fall back on stlink-gdbserver, I just stumbled over it.

[embitz]

This is OCTOSPI1 memory.
We currently don't support that in our H5 script but nothing is stopping you from adding this.
I don't have a board here to test this so I can't help you with this.

[dliebler]

What makes you think this is OCTOSPI1 memory?
Afaik, this is not using any part of the OCTOSPI1 peripheral.
I am refering to the high cyclic memory at address 0x0900.0000, not 0x9000.0000.

Its part of the original flash remapped to use more bits per byte for ECC and therefore is also part of the main flash peripheral. Reading should be as simple as just reading from these addresses. Just not bytewise.

But if I am wrong, do you have any script where something like this is implemented?

[embitz]

I just looked into the reference manual after I received a stm32H563 board. I think we need to rewrite that whole script for the H5 in case we use ECC and also implement high-cycle memory. But I need some help with that. I'm too busy to dive into this on my one.

I will introduce special xml memory attributes so that we can force EBlink the read access width for certain segments.

Could you make some test projects with different scenarios like ECC 6-bit with high-cycle and 9-bit etc with some comments in the code. I will try to make the script high-cycle aware. Maybe we also need to support system memory etc.

[dliebler]

Yes, sure, I am happy to help where I can.
You are referring to rewriting the stmicro/flash/h5.script, correct? I can try to rewrite the flash functions to give you a starting point, but I am a little bit confused about the interface between eblink and the scripts. Does eblink call the functions by using dedicated function-names for reading/writing/erasing etc or from where are they called?

What are you planning with ECC?
high cycle memory is always 6b ECC, non-high cycle memory 9b ECC.
ECC errors are raised on reads. As far as I understand, you cannot turn ECC on/off. Its only dependent if a flash page is configured as high-cyclic or not.
Do you want to add checks for ECC when reading data? I think this would make special functions for reading from flash required in the flash script.

About the test-projects: high cycle configuration is set in the option bytes.(EDATA1/2)
I could create projects which set this at runtime, but they are always persistent and have to be reset/overwritten. Also this can be easily set in CUBE programmer instead of switching between projects. Running Code is not really required, is it?
I would directly connect to eblink without a Project/IDE via GDB and try to manually read/write high cyclic adresses. This uses the same functionality with a lot less overhead.
Or did you imagine a project to directly flash data sections into high cycle memory through the linker&eblink?

[embitz]

Yes, if you would create a small project how you would like to use these memory regions and what you would expect to get from GDB back. A project which works with stlink-gdb.
That would be very helpful.

[dliebler]

I finally got around creating a test configuration.
I uploaded it to Github Test Project.

In main.c are two defines for enabling the two tests. I would recommend starting off with only TEST2 enabled. I would suggest to only try TEST1 once TEST2 is working.

TEST1 is for checking if data can be directly linked into high-cycle memory. This was not my original issue, but I think writing to high cycle flash is just as important as reading. But I found out that this doesnt work with STLink debugger, either. But it probably is a bug there, too.

TEST2 is testing for my original issue, this works with STLink debugger.

I have described more in the projects README.md about how to perform the tests.

I also use my flash functions for interaction with high-cycle flash inside flash.c. We can probably copy from them when upgrading the eblink flash functionality for high-cycle memory.

One important note for debugging is, that reading from virgin flash causes a double ECC error and thus a currently unhandled NMI. So debugger watches on addresses in high cycle flash are probably a bad idea.

[embitz]

I'm busy with the implementation of this and it starts working however, if the memory viewer is showing the high cycle memory I get an ECC interrupt error because it also shows unwritten data. I'm not sure how to handle this. I don't think that high cycle memory is suitable to be shown by debugging IDE's

But I've got the GDB memory queries working.

   

[dliebler]

Thats perfect news.

Yes, I think it is inevitable to generate these double ECC errors when reading virgin flash.
But I think it is still neccessary to examine these addresses, sometimes. For me personally, this problem is solved if I can use the GDB commands.

For watches, my idea would be to allow the user to set up these addresses and have the user deal with the double ECC errors.
The user would have to make sure the addresses are never virgin flash when the debugger is halted(and the watches are updated).
I think in the scenario where you would want to look into the contents of the high cycle flash, you are able to ensure this, i guess.

But memory view and live watches are indeed probably not a good idea for high cycle flash.

[embitz]

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.