Question regarding use of AXIM vs ITCM.

[SBurc]

I just solved a bug in my software, and can't quite understand how it happened. My code is a built in hardware test for our board, and a bootloader, which communicates with a serial bus and downloads different compoents to different memories. One of those components is on the internal flash, and is the main software.

Loading the main software worked fine. However, the software also supported queries about the tests, and after the software was loaded, the CRC check would fail on the newly loaded software until the power was cycled. After cycling power, the CRC check would pass.

I looked at this under a debugger, and found that the CRC check was in fact giving a different result after rewriting the flash contents (an incorrect value) and a correct value after cycling power. My first guess was cache problems, but since the loader component of the software does things to the flash, and has no need for caching, it doesn't turn the caches on.

I had been running the CRC over the region where the main software was stored, (0x280000-0x2FFFFF). I noticed that under the debugger, when I looked at the newly-burned region, including the CRC itself, the values shown and the values actually there disagreed until reset. That gave me the idea for the fix, and I just changed the boundaries of the CRC to 0x8080000-808FFFF. Now the software worked perfectly.

I did notice while debugging that during a load from the flash, the values getting loaded into the registers of the CRC component seemed to be correct, even if I didn't see them correctly under the debugger. What I don't understand is what the processor was "seeing" on the ITCM bus after the flash was rewritten? How was it coming up with an incorrect value?

[waclawek.jan]

> it doesn't turn the caches on

Does turn them off?

JW

[SBurc]

AFAIK it doesn't touch them from powerup. If I recall correctly, you need to set the enable bits in the CCR of the SCB, and I don't.

[Tesla DeLorean]

Not exactly sure whats going on in this case, but it sounds like it is holding some stale content, or there is a mapping issue.

​

Thing to watch with flash is what the ART is doing and how it manages and fetches​. When writing any cached content (CPU side, FLASH side) needs to be flushed/invalidated.

​

The H7 is an odd beast, the reset is not the same as a power cycle. The ROM loader may change the mapping of things based on the presence of code on flash at initial startup.​

[waclawek.jan]

> AFAIK it doesn't touch them from powerup. If I recall correctly, you need to set the enable bits in the CCR of the SCB, and I don't.

My copy of PM0253 says the instruction cache is turned on by reset.

Try to disable it.

I know you what you read are data, but...

AFAIK, the 'H7 does not have the FLASH jumpcache/datacache ST calls ART.

JW

PS: Isn't there any example by ST, even if Cube?

 PS2. If the discrepancy is only a few words, it may be consequence of AXIM's wicked buffering

[Pavel A.]

> PS2. If the discrepancy is only a few words, it may be consequence of AXIM's wicked buffering

Jan, could you tell a bit more what is wicked in H7 AXIM buffering and how it may look?

(asking because I have a H7 and see some weird things...)

Apologies for jumping in...

> PS: Isn't there any example by ST, even if Cube?

Example of disabling I-cache? Of course, the cube HAL is a function for this.

-- pa