Jlink flash programming interface does not take memory changes from CPU/code into account

When Jlink performs flash updates, it looks that its cache is not up-to-date if the memory content has been modified by code execution. It results in having wrong memory content at the end.

My use is case is the following : My application is initializing 16 bytes at defined address of the Flash memory at startup, assuming the first byte is FFh.

- 1. Flash code -> memory is virgin -> All bytes are FFh
- 2. Using memory viewer, I modified some bytes (lets say 8th and 12th to CCh) into the buffer. The flasher runs and modifies the memory. Memory viewer shows the right data.
- 3. I run code and stop it just after my code performs memory initialization. Memory viewer shows the expected data : All the bytes are written with new value including 8th and 12th bytes
- 4. I use the memory viewer to modify first byte to 33h. The flasher runs but the result is not the good one. First byte is ok but 8th and 12th get the value written in dot 2 !!!!

@0x5000 (Flash Memory)
1. -> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
2. -> FF FF FF FF FF FF FF CC FF FF FF CC FF FF FF FF FF FF
3. -> 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4. -> 33 FF FF FF FF FF FF CC FF FF FF CC FF FF FF FF FF FF (expected value with Read-Modify-Feature: 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 )

If I perform exactly the same but replacing the code operation with direct modification in Memory viewer , everything is ok

Looking at jlinklog, the CPU mem read and cache update are ok. See log attached (line 1383). But it looks the Flasher has its own cache that it is not up-to-date as it restores the former data.

Context :
- Embedded Studio 8.16
- Jlink software 7.98d
- Jlink base compact with last firmware.

Note: All the Flash memory has been excluded from Flash caching in jlink script file using JLINK_ExecCommand("ExcludeFlashCacheRange 0x00000000-0x0007FFFF"); as required.

More information about the issue:
When using the memory viewer of embedded studio to modify some bytes of the memory, only modified characters are updated into the cache used for flashing. That is visible in the jlink control panel and llink log file.

However the first modification MUST trig a refresh of the cache by reading the full content of the concerned memory sector.
This seems not to be done.
As a result, the jlink flash driver does not know the current memory content of the sector and so performs inconsistent write operations.

Regards
Fred

Hi Alex,
Any news about the solution ?
Regards,
Fred

Hello Simon,
I've just tried the new version.
It does not work on my side. When using the memory viewer to modify the memory, it looks the flash loader is not loaded into RAM memory before calling it, resulting in having an illegal instruction error with address in loader.

[Update]
The exception does not occurs when doing a "step into" after the modification. Doing a "step over" or a run after cause the illegal exception occurs. And for step over I get the error message "Failed to set stepover breakpoint".

For both I can also see in console: PC of target system has unexpected value after erasing sectors. (PC = 0x000001C4)! for all cases (including step into)

Any idea ?

Regards
Frederic

Additionnal information :

The exception occurs for all exit conditions so for "step into" too.

Exceptions occurs when attempting to execute flash loader code that should be loaded into RAM memory.
mcause register indicates an illegal instruction at start address of SEGGER_FL_Erase.

The exception results in having PC into the security exception handler. That's why I get the following message after modifying the memory:

PC of target system has unexpected value after erasing sectors. (PC = 0x000001C4)!
Failed to erase sectors.

So now, I have 2 issues:
1 - Memory update from memory viewer cause a security exception due to an illegal instruction (loader not loaded ?). Please note that everything is working well when loading the code.
2 - When using "step into" mode the debbuger seems ignoring PC modification from flash loader and restore the PC value to the nex expected one.

Here are the log trace:

T266C 016:295.339   HandleBeforeFlashProg() start
T266C 016:295.355    J-Link Script File: Executing HandleBeforeFlashProg()
T266C 016:295.408   QS7001 Flash Loader init 
T266C 016:295.419   CPU_ReadMem(4 bytes @ 0x40000000)
T266C 016:296.539   CPU_WriteMem(4 bytes @ 0x40000000)
T266C 016:296.558   CPU_ReadMem(4 bytes @ 0x40000414)
T266C 016:298.272   CPU_ReadMem(4 bytes @ 0x40000418)
T266C 016:299.432   CPU_WriteMem(4 bytes @ 0x40000414)
T266C 016:299.453   CPU_WriteMem(4 bytes @ 0x40000418)
T266C 016:299.584   HandleBeforeFlashProg() end - Took 4.10ms
T266C 016:299.600    -- --------------------------------------
T266C 016:299.613    -- Start of determining flash info (Bank @ 0x00000000)
T266C 016:299.622    -- End of determining flash info
T266C 016:299.634    -- Start of determining dirty areas in flash cache
T266C 016:299.648    -- Filling invalid ranges in sector buffer (flash cache) for sector @ 0x00005000 if necessary
T266C 016:299.659    -- Start of preparing flash programming
T266C 016:299.675    -- Recalculating RAMUsage for optimal performance during programming
T266C 016:299.686    -- End of preparing flash programming
T266C 016:299.699   CPU_ReadMem(384 bytes @ 0x00005000)
T266C 016:315.656    -- Updating C cache (384 bytes @ 0x00005000)
T266C 016:315.763   CPU_ReadMem(64 bytes @ 0x000051C0)
T266C 016:319.338    -- Updating C cache (64 bytes @ 0x000051C0)
T266C 016:319.419    -- Read from C cache (512 bytes @ 0x00005000)
T266C 016:319.462    -- Updating flash cache (512 bytes @ 0x00005000)
T266C 016:319.498    -- Updating flash cache invalid range 0x00005000 - 0x000051F7 (504 bytes)
T266C 016:319.541    -- Updating flash cache invalid range 0x000051FA - 0x000051FF (6 bytes)
T266C 016:319.914    -- End of determining dirty areas
T266C 016:319.963    -- CPU speed could not be measured.
T266C 016:320.003    -- Start of comparing flash
T266C 016:320.043    -- CRC check was estimated as fastest method
T266C 016:320.083    -- CRC check is not supported by this flash bank. Switched to read back method.
T266C 016:320.126    -- Comparing range 0x5000 - 0x51FF (1 Sector, 512 Bytes), using single-block CRC calculation
T266C 016:320.166    -- CRC check is not supported by this flash bank. Switched to read back method.
T266C 016:320.211    -- Recalculating RAMUsage for optimal performance during programming
T266C 016:339.930    -- CRC does not match for sector 40
T266C 016:340.069    -- End of comparing flash
T266C 016:340.118    -- Start of erasing sectors
T266C 016:340.166    -- Erasing range 0x00005000 - 0x000051FF (  1 Sector, 512 Bytes)
T266C 016:340.213    -- Recalculating RAMUsage for optimal performance during programming
T266C 016:364.531   
  ***** Error: 
T266C 016:364.613   PC of target system has unexpected value after erasing sectors. (PC = 0x000001C4)!
T266C 016:364.651   
  ***** Error: 
T266C 016:364.682   Failed to erase sectors.
T266C 016:364.704    -- End of erasing sectors
T266C 016:364.739    -- Start of restoring
T266C 016:364.771    -- End of restoring
T266C 016:365.176   HandleAfterFlashProg() start
T266C 016:365.213    J-Link Script File: Executing HandleAfterFlashProg()
T266C 016:365.438   QS7001 Flash Loader uninit
T266C 016:365.485   CPU_WriteMem(4 bytes @ 0x40000418)
T266C 016:365.523   CPU_WriteMem(4 bytes @ 0x40000414)
T266C 016:365.560   CPU_WriteMem(4 bytes @ 0x40000000)
T266C 016:365.883   HandleAfterFlashProg() end - Took 384us

Regarding the trace, I note something strange in the log (lines 19 and 21). 7.98f release is intended to update cache reading the full memory sector. We can see 2 CPU_ReadMem in the trace :
- Read 384 bytes from 0x5000
- Read 64 bytes from 0x51C0
So 64 bytes are still missing from 0x5180 to 0x51C0.

Regards
Fred