Issue running code in OCR on i.MX RT 1060 - loaded by debugger

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Issue running code in OCR on i.MX RT 1060 - loaded by debugger

647 Views
mjbcswitzerland
Specialist V

Hi All

The following issue was found when building a project to be located in the 512k OCR in an i.MX RT 1060 (600MHz B).
The OCR was chosen initially for simplicity as it has a fixed size of 512k and is adequate to load the code to for RAM based debugging purposes.
What is found is that
1: When the code starts it hits random HW faults.
2: The fault handler doesn't stay in a loop (wanted by design) but instead simply returns so that the instruction causing the fault can be seen and it was originally expected that there were some bad access but the instructions failing are totally normal instructions accessing registers, and, when stepping is continued the instruction is successful at the second attempt to execute it and so the program execution continues.
3: During startup there are typically 5 to 10 such faults that 'repair themselves" when repeated and then the application runs normally and without any problems until things are executed which haven't been executed before since starting. Typically scrolling through a CLI provokes a fault in a new menu on first use but afterwards it can be repeated as much as desired without failing.
4. When replacing the code a power cycle is required for the next attempt to have any success at all (otherwise just hard faults all the time)

My feeling is that this has something to do with caching of the fixed 512k OCR. For example the access retrieves initially something from cache rather than the newly loaded code in OCR. Once the instruction is repeated it is always OK - potentially because the cache was then correctly updated with the instruction(s).

5 .When the same program is linked to load and run in ITC this problem doesn't exist.

There are two questions:
A) How can the cache be cleared when/before new code is loaded to ensure that nothing stale is in it (in case this may be the source of difficulties)?
B) How can FlexRAM be configured ? (since ITC works reliably configuring banks to give more ITC would allow bigger programs to be loaded and debugged)

Supposedly a debugger script needs to be executed in order to perform the cache delete commands or to configure FlexRAM 'before' the code download is started. Are there such existing ones that can be used as references that will allow this to be customised (eg. for MCUXpresso and its supported debuggers)?

Or is there a different overall issue explaining this behavior?

Thanks
Regards

Mark

Labels (1)
1 Reply

606 Views
jeremyzhou
NXP Employee
NXP Employee

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) How can the cache be cleared when/before new code is loaded to ensure that nothing stale is in it (in case this may be the source of difficulties)?
-- I think it'd be better to use a debugger script to disable the cache feature during the debugging.
2) How can FlexRAM be configured? (since ITC works reliably configuring banks to give more ITC would allow bigger programs to be loaded and debugged)
-- Please refer to the application note.

More further, I'd like to know whether you ever tested the code be copied to the OCR from the external flash via the ROM code, then jump to execute it, if yes, did you encounter the boot failure?

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos