[SOLVED] J-Link Timeout while erasing sectors / Problem debugging RT1064

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

  • J-Link Timeout while erasing sectors / Problem debugging RT1064

    Hi,

    I've been having problems with the RT1064 and a JLink Base.
    I've described the problem on the NXP forum here:
    community.nxp.com/t5/i-MX-RT/D…-JLink/m-p/1261542#M13781

    The problem I am having seems to be exactly the problem that was described here: forum.segger.com/index.php/Thr…ut-while-erasing-sectors/ but the issue never says if it was resolved or not.

    My current question is, Does the J-Link base support programming the SIP memory inside the RT1064 via FlexSPI?
    If it does, can someone help for finding out what the potential other problems might be? I'm getting to be at my wits end here... I can program and run from RAM fine, but our main application needs to run from flash...

    The issue is as follows (condensed from NXP forum thread):
    I cannot get reliable debugging via JLink from MCUXpresso. The behaviour is as follows:
    1. On launching the debugger for the first time, it will open up the Jlink programming dialog for a few seconds, then it will close and the program will not run.
      1. The Jlink output script seems to have some errors in it and then an eventual timeout when erasing sectors

    Source Code

    1. ERROR: Timeout while erasing sectors, RAMCode did not respond in time. (PC = 0x00000000, CPSR = 0x00200300, LR = 0x81000000)!
    2. Failed to erase sectors

    • On launching the debugger for the second time, it does correctly program but does have an error in it too?

    Source Code

    1. Core did not halt on reset vector. Assuming faulty image.
    2. Resetting and halting core on image verification value read.
    3. Core did not halt after reset step 1

    • When this happens, the debugger does not stop at main and seems to randomly pick a breakpoint it wants to stop at (it does successfully stop at breakpoint 3 that was set. restarting the core via MCUXpresso does stop at the first breakpoint.
    When debugging, I consistently bounce between these 2 states. For example, after a failed load, the next load will always succeed (insofar as you can call that success). However, the next load will fail in one of two ways:
    1. If I do not change anything in the source files, the debugger gets into a weird state where it stops responding altogether and I have to disconnect / reconnect it from USB and close / reopen MCUXpresso.
    2. If I do change the source files, I get back into state 1 above, where the load fails due to RAMCode timeout, then the next load 'succeeds'.
    Thanks,
    Nick
    Files
  • Hi,

    We are already aware of a regression in the current V7.00 of the J-Link software, which affects exactly this device (actually it was me internally running into this).
    We are already working on a fix and plan to have it available by Friday.
    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.
  • [SOLVED] J-Link Timeout while erasing sectors / Problem debugging RT1064

    I spent most of today debugging this issue.

    I tried installing IAR and it has similar issues, where it can run from RAM but not from flash.

    I did more digging into MCUXpresso and got the following J-LINK logs:

    The 'good' log shows the following:

    C Source Code

    1. T3BD8 003:402.002 Looking for J-Link GUI Server exe at: C:\Program Files (x86)\SEGGER\JLink\JLinkGUIServer.exe
    2. T3BD8 003:402.036 Forking J-Link GUI Server: C:\Program Files (x86)\SEGGER\JLink\JLinkGUIServer.exe
    3. T3BD8 003:422.113 J-Link GUI Server info: "J-Link GUI server V7.00 "
    4. T3BD8 003:435.197 -- CPU speed could not be measured.
    5. T3BD8 003:435.217 -- Start of comparing flash
    6. T3BD8 003:435.226 -- CRC check was estimated as fastest method
    7. T3BD8 003:455.170 -- Comparing range 0x70000000 - 0x7001FFFF (2 Sectors, 128 KB), using multi-block CRC calculation
    8. T3BD8 003:587.171 -- CRC does not match for sector 1
    9. T3BD8 003:587.440 -- Comparing range 0x70000000 - 0x7000FFFF (1 Sector, 64 KB), using alternative multi-block CRC calculation
    10. T3BD8 003:680.361 -- All CRCs match
    11. T3BD8 003:680.385 -- End of comparing flash
    12. T3BD8 003:680.394 -- Start of erasing sectors
    13. T3BD8 003:680.404 -- Erasing range 0x70010000 - 0x7001FFFF ( 1 Sector, 64 KB)
    14. T3BD8 003:952.430 -- End of erasing sectors
    15. T3BD8 003:952.455 -- Start of flash programming
    16. T3BD8 003:952.466 -- Programming range 0x70010000 - 0x7001FFFF ( 1 Sector, 64 KB)
    17. T3BD8 005:529.840 -- End of flash programming
    18. T3BD8 005:529.866 -- 0x70010000 - 0x7001FFFF ( 1 Sector, 64 KB)
    19. T3BD8 005:529.875 -- Start of restoring
    20. T3BD8 005:529.884 -- Restoring RAMCode
    21. T3BD8 005:566.648 -- Restore target
    22. T3BD8 005:566.672 -- Restore memory
    23. T3BD8 005:566.680 -- Restoring CPU registers
    Display All
    Whereas the bad log shows:


    Source Code

    1. T4A98 003:485.174 Looking for J-Link GUI Server exe at: C:\Program Files (x86)\SEGGER\JLink\JLinkGUIServer.exe
    2. T4A98 003:485.209 Forking J-Link GUI Server: C:\Program Files (x86)\SEGGER\JLink\JLinkGUIServer.exe
    3. T4A98 003:504.220 J-Link GUI Server info: "J-Link GUI server V7.00 "
    4. T4A98 003:517.338 -- CPU speed could not be measured.
    5. T4A98 003:517.360 -- Start of comparing flash
    6. T4A98 003:517.369 -- CRC check was estimated as fastest method
    7. T4A98 003:553.931 -- Comparing range 0x70000000 - 0x7001FFFF (2 Sectors, 128 KB), using multi-block CRC calculation
    8. T4A98 003:617.822 -- CRC does not match for sector 1
    9. T4A98 003:618.040 -- Comparing range 0x70000000 - 0x7000FFFF (1 Sector, 64 KB), using alternative multi-block CRC calculation
    10. T4A98 003:649.296 -- All CRCs match
    11. T4A98 003:649.312 -- End of comparing flash
    12. T4A98 003:649.321 -- Start of erasing sectors
    13. T4A98 003:649.330 -- Erasing range 0x70010000 - 0x7001FFFF ( 1 Sector, 64 KB)
    14. T4A98 013:674.439
    15. ***** Error:
    16. T4A98 013:674.463 Timeout while erasing sectors, RAMCode did not respond in time. (PC = 0x00000000, CPSR = 0x00200300, LR = 0xA1000000)!
    17. T4A98 013:674.473
    18. ***** Error:
    19. T4A98 013:674.480 Failed to erase sectors.
    20. T4A98 013:674.486 -- End of erasing sectors
    21. T4A98 013:674.495 -- Start of restoring
    22. T4A98 013:674.503 -- Restoring RAMCode
    23. T4A98 013:737.318 -- Restore target
    24. T4A98 013:737.358 -- Restore memory
    25. T4A98 013:737.368 -- Restoring CPU registers
    26. T4A98 013:737.386 -- End of restoring
    27. T4A98 013:739.509
    28. ***** Error:
    29. T4A98 013:739.525 Timeout while erasing sectors, RAMCode did not respond in time. (PC = 0x00000000, CPSR = 0x00200300, LR = 0xA1000000)!
    30. Failed to erase sectors.
    Display All


    So it looks to me like the jlink is timing out when trying to erase the flash sectors. Why might this be?
    Why is it so consistent that every second program succeeds?
    Files
  • Hi,
    Good to hear that it now works as expected.
    We will close this thread now.

    We are sorry for any inconvenience caused.

    Best regards,
    Fabian
    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.