Issues with writing bytes/erasing memory on NXP mk64 board using JLink

[CarloATX]

Hi everyone,
I've been running into a problem with saving 'changes' I make to a mk64 board that I am using.

Essentially, I am flashing two program files using the loadfile command and then running a series of write commands to an address where I have a flash partition designated in my .dts file. I am able to issue these write commands to the board but when I summon a command like say erase, quit, or reboot, I get a RAMCode Timeout error that then erases all write changes I had attempted to make. The program files are unaffected but it really is just the write commands afterwards. It could be a simple problem but I am unsure what is causing it. Maybe some security configurations in zephyr that are default and I am unaware of or maybe an upstream issue with the processor and compatibility with JLink 'saving' these memory changes.

The problem I run into seems to only occur with zephyr and when I run another rtos I am not prohibited from making these changes. Hopefully someone who knows more can enlighten me more and help.

I attached a log file from jlink showing the issue. I did not run the loadfile commands in this example because the program is already flashed to the board.

Thank you!

edit: Some stuff that might help clarify. I am flashing the files at addresses 0x0 and 0x00010000 for the mcuboot and program files.

mk64_log.txt

[DerekSnell]

Hi @CarloATX ,
It seems you feel the Zephyr app image in flash is causing this issue with the write commands. I would confirm that is true. If you erase the flash, power cycle the board, and then use JLink to perform the same write commands, do those writes succeed? If so, it would seem the execution of the Zephyr app is interfering with the RAMCode execution.

One thought I have is the MPU. If the Zephyr app configures the MPU to prevent execution from the RAM used by RAMCode, and the MPU is not reinitialized by the JLink, then perhaps that leads to an access violation fault, and the RAMCode cannot execute. You could test this in your Zephyr app by deselecting CONFIG_MPU=n.

Otherwise, an option is to not allow the Zephyr app to execute before the JLink write commands. Since the loadfile commands work fine, can you write to your flash partition first before programming the app? I mean: erase the flash, use the write commands for your flash storage data, and then use loadfile to write the app. Or another potential option is to use the JLink to connect to the K64 under reset, so the app cannot execute. Have the JLink tool halt execution and then release from reset. If the JLink can prevent the app from executing, then it would not interfere with the RAMCode.

Let us know what you find. Best regards

[CarloATX]

Hi Derek,

Sorry for the late response. I believe I was able to resolve with it with your help.
First, I tried using the write commands before running loadfile for the program files and it still seems to perform an erase at that memory area I have designated for my write commands so instead I opted for connecting under reset. Connecting under reset did the trick for saving the changes to flash.

Concerning MPU changes, I have not tested modifying those settings, but it is possible that deselecting the hardware would allow JLink access to the ram for flashing. I can give an update after some quick testing if that is the case.

Thank you so much for your help and attentiveness with this.