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

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • 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.
      Files

      • jlinklog2.txt

        (91.41 kB, downloaded 19 times, last: )

      The post was edited 2 times, last by fjouen ().

    • 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,

      We can confirm that the problem is reproducible on our side.
      We already have an internal solution for it but need to perform another round of iterations to check against unwanted side effects.


      BR
      Alex
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.

    • Hello,

      The fix for this issue will be included in the next version, scheduled for later today.

      Stay up-to-date regarding J-Link:
      segger.com/notification/subscribe.php?prodid=7,94

      Best regards,
      Simon
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.

    • New

      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

      The post was edited 1 time, last by fjouen: More information ().

    • New

      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:

      Brainfuck Source Code

      1. T266C 016:295.339 HandleBeforeFlashProg() start
      2. T266C 016:295.355 J-Link Script File: Executing HandleBeforeFlashProg()
      3. T266C 016:295.408 QS7001 Flash Loader init
      4. T266C 016:295.419 CPU_ReadMem(4 bytes @ 0x40000000)
      5. T266C 016:296.539 CPU_WriteMem(4 bytes @ 0x40000000)
      6. T266C 016:296.558 CPU_ReadMem(4 bytes @ 0x40000414)
      7. T266C 016:298.272 CPU_ReadMem(4 bytes @ 0x40000418)
      8. T266C 016:299.432 CPU_WriteMem(4 bytes @ 0x40000414)
      9. T266C 016:299.453 CPU_WriteMem(4 bytes @ 0x40000418)
      10. T266C 016:299.584 HandleBeforeFlashProg() end - Took 4.10ms
      11. T266C 016:299.600 -- --------------------------------------
      12. T266C 016:299.613 -- Start of determining flash info (Bank @ 0x00000000)
      13. T266C 016:299.622 -- End of determining flash info
      14. T266C 016:299.634 -- Start of determining dirty areas in flash cache
      15. T266C 016:299.648 -- Filling invalid ranges in sector buffer (flash cache) for sector @ 0x00005000 if necessary
      16. T266C 016:299.659 -- Start of preparing flash programming
      17. T266C 016:299.675 -- Recalculating RAMUsage for optimal performance during programming
      18. T266C 016:299.686 -- End of preparing flash programming
      19. T266C 016:299.699 CPU_ReadMem(384 bytes @ 0x00005000)
      20. T266C 016:315.656 -- Updating C cache (384 bytes @ 0x00005000)
      21. T266C 016:315.763 CPU_ReadMem(64 bytes @ 0x000051C0)
      22. T266C 016:319.338 -- Updating C cache (64 bytes @ 0x000051C0)
      23. T266C 016:319.419 -- Read from C cache (512 bytes @ 0x00005000)
      24. T266C 016:319.462 -- Updating flash cache (512 bytes @ 0x00005000)
      25. T266C 016:319.498 -- Updating flash cache invalid range 0x00005000 - 0x000051F7 (504 bytes)
      26. T266C 016:319.541 -- Updating flash cache invalid range 0x000051FA - 0x000051FF (6 bytes)
      27. T266C 016:319.914 -- End of determining dirty areas
      28. T266C 016:319.963 -- CPU speed could not be measured.
      29. T266C 016:320.003 -- Start of comparing flash
      30. T266C 016:320.043 -- CRC check was estimated as fastest method
      31. T266C 016:320.083 -- CRC check is not supported by this flash bank. Switched to read back method.
      32. T266C 016:320.126 -- Comparing range 0x5000 - 0x51FF (1 Sector, 512 Bytes), using single-block CRC calculation
      33. T266C 016:320.166 -- CRC check is not supported by this flash bank. Switched to read back method.
      34. T266C 016:320.211 -- Recalculating RAMUsage for optimal performance during programming
      35. T266C 016:339.930 -- CRC does not match for sector 40
      36. T266C 016:340.069 -- End of comparing flash
      37. T266C 016:340.118 -- Start of erasing sectors
      38. T266C 016:340.166 -- Erasing range 0x00005000 - 0x000051FF ( 1 Sector, 512 Bytes)
      39. T266C 016:340.213 -- Recalculating RAMUsage for optimal performance during programming
      40. T266C 016:364.531
      41. ***** Error:
      42. T266C 016:364.613 PC of target system has unexpected value after erasing sectors. (PC = 0x000001C4)!
      43. T266C 016:364.651
      44. ***** Error:
      45. T266C 016:364.682 Failed to erase sectors.
      46. T266C 016:364.704 -- End of erasing sectors
      47. T266C 016:364.739 -- Start of restoring
      48. T266C 016:364.771 -- End of restoring
      49. T266C 016:365.176 HandleAfterFlashProg() start
      50. T266C 016:365.213 J-Link Script File: Executing HandleAfterFlashProg()
      51. T266C 016:365.438 QS7001 Flash Loader uninit
      52. T266C 016:365.485 CPU_WriteMem(4 bytes @ 0x40000418)
      53. T266C 016:365.523 CPU_WriteMem(4 bytes @ 0x40000414)
      54. T266C 016:365.560 CPU_WriteMem(4 bytes @ 0x40000000)
      55. T266C 016:365.883 HandleAfterFlashProg() end - Took 384us
      Display All
      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

      The post was edited 1 time, last by fjouen ().