[SOLVED] r (reset) triggers flash write trace ...

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

  • [SOLVED] r (reset) triggers flash write trace ...

    I see that doing a 'r' / reset command in J-Link, causes a flash write traces, and , I do not understand why. Most importantly I guess to know if it's actually erasing/writing anything just because I wanted reset .. and why. I load/flash image just before reset, and don't want it to be erased.

    Source Code

    1. J-Link>r
    2. Reset delay: 0 ms
    3. Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
    4. Comparing flash [100%] Done.
    5. Erasing flash [100%] Done.
    6. Programming flash [100%] Done.
    7. Verifying flash [100%] Done.
    8. J-Link: Flash download: Bank 0 @ 0x01000000: 1 range affected (2048 bytes)
    9. J-Link: Flash download: Total time needed: 0.125s (Prepare: 0.037s, Compare: 0.006s, Erase: 0.011s, Program: 0.038s, Verify: 0.006s, Restore: 0.024s)
    10. ResetTarget() start
    11. ResetTarget() end
    12. J-Link>
    Display All
    Sort of, did not expect reset to trigger re-flashing.
    Files
  • Hi,
    Thank you for your inquiry.

    One reason could be, if you have any flash break points enabled.

    I just did a reset on an empty target (CC3220SF) and it does not do any reads/downloads from/to flash (find screenshot attached).

    Best regards,
    Fabian
    Images
    • Capture.PNG

      33.79 kB, 677×678, viewed 15 times
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    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.
  • Hi,
    after reviewing this, I realized that you are doing some writes after the loadfile-command:
    w4 0x01000000, xxx
    w4 0x01000004, xxx
    w4 0x01000008, xxx

    These writes are cashed by the DLL and are written Go / Step / Reset, leading to a flash download.
    We do this to make Downloads from IDEs more efficient.
    Since loadfile is always flushed directly, this leads to the described behavior.

    Best regards,
    Fabian
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    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.
  • Hi Fabian,

    Thanks for your time to describe how the internals of the JLink soft/dll work. Just want to clarify your last post.


    SEGGER - Fabian wrote:



    Since loadfile is always flushed directly, this leads to the described behavior.
    Way I read it (or understand), loadfile triggers "direct" flush, with no-cashing or buffering before write to target. Is this how you meant it?


    SEGGER - Fabian wrote:

    ...
    w4 0x01000000, xxx
    w4 0x01000004, xxx
    w4 0x01000008, xxx

    These writes are cashed by the DLL and are written Go / Step / Reset, leading to a flash download.
    .....

    Could you explain the sequence "Go/Step/Reset" in the above? The writes are few bytes/words to flash (not breakpoints related) before letting the target/core run. Are you saying these trigger re-flash?

    I sort of thought, based on my OP / question, thought (again, assuming I understood it) your first explanation made more sense - because JLink needs to modify XIP flash to insert breakpoints code after reset.

    If you could explain it would be much appreciated.
  • Hi,

    Please cross out "flash breakpoints" here. This is totally unrelated.
    Hopefully this makes it clear:

    1. J-Link is designed to work with multiple IDEs, including GDB. For most IDEs, there is no defined "Flash download start" and "flash download end" indicator.
    2. In addition to 1., some IDEs download the application image section-wise / chunk wise, so immediately triggering flash download can would eventually result in the same sector being erased + programmed multiple times, which costs time and flash erase cycles
    3. Therefore, the J-Link DLL caches(!) writes to flash until a flush is required (reset/go/memory access to a non-flash area, ...)
    4. The "loadfile" is a special case for J-Link Commander because in this situation we know the start and end of the flash operation, so we can trigger it immediately and flush the buffer
    5. If you issue additional writes to flash afterwards (e.g. via w1/w2/w4 commands) they will also cause flash programming but with the default caching mechanism, explained in 3.
      It is the same as if you edit the flash contents in the memory window of your IDE (which some customers do to change constants during debug without a whole debug session restart). J-Link simply does not know when you are done with editing, so the writes are cached until programming is necessary
    As you perform additional writes in your setup as explained in 5), you are affected by this caching mechanism.
    Hope this makes it clear.
    Again: It has *nothing*(!!!!) to do with flash breakpoints.


    BR
    Alex
  • Hi,
    Sorry for the confusion caused.

    We will consider this thread as closed now.

    Best regards,
    Fabian
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    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.