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:
Nick
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:
- 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.
- The Jlink output script seems to have some errors in it and then an eventual timeout when erasing sectors
- The Jlink output script seems to have some errors in it and then an eventual timeout when erasing sectors
- On launching the debugger for the second time, it does correctly program but does have an error in it too?
- 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.
- 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.
- 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'.
Nick