Changing a value in HyperRAM via debugger locks processor up

[p_shep]

This is one I'm not expecting an answer to, really...

I have HyperRAM running on an IMXRT1064 happily enough. Have the FreeRTOS heap located there.

All fine while running, but If I suspend the processor and try and change a value (either a viable, or memory view) the processor immediately restarts, with no indication of why.

Reads are ok, but doesn't like writes one bit.

Any ideas?

[kerryzhou]

Hi @p_shep ,

  Do you enable the watchdog?

  After your device is reset, do you check the reset type, which detail reset it is triggered? Please check SRC_SRSR register, which reset it happens?

    Then give me the updated information, thanks.

Best Regards,

Kerry

[p_shep]

Funnily enough, I've just implemented that feature.

Watchdogs are not enabled, at least by me - some WD registers are fiddled with in the NXP startup code. Never bothered to work out what that does! 

So first off, if I change any memory in the 0x60000000 region, I see the 'multiple errors' appear in the variables window in the value column, then it locks-up/resets and gets stuck at initialise_monitor_handles() - that leads to a hard fault. SRSR at this point is reporting 0x2, so the usual lock-up/sysreq. This is cleared on start-up, so the unit must have restarted.

[kerryzhou]

Hi @p_shep 

Why you change 0x6000000 memory? where you code is running now? In the flexRAM or internal RAM?

You need to make sure, your code execution area, you can't modify the data, otherwise, it may broken your app code.

Best Regards,

kerry

[p_shep]

Sorry, the device is the RT1064.

0x60000000 is the base addresss of FlexSPI1, where the HyperRAM is located.

All code runs from the internal QSPI flash on FlexSPI2, at 0x70000000.

[kerryzhou]

Do you define the variable, stack, heap, or anyother APP used memory in the flexRAM?

Seems your modified 0x6000000 area data influence your app working.

Best Regards,

KERRY

[p_shep]

System stack and heap are placed in DTCM. That's all fine.

FreeRTOS heap is placed on the HyperRAM (at 0x60000000) taking up the whole 8Mb.

OCRAM is actually currently unused.

All runs fine and smooth when its running. 

Only issue comes in when I suspend execution with the debuggger and change anything, anything at all on HyperRAM via the debugger. Changing data in DTCM (or OCRAM) is absolutely fine, no issues. Just HyperRAM that has this problem.

Could it be that with the processor suspended, FlexSPI isn't running so can't issue the SPI commands, so there's a bus fault? Don't hit that exception though. Also no issue reading values from HyperRAM (or Flash, for that matter).

Attached is an example of what i see in the memory window when I try changing a value

[kerryzhou · Accepted solution]

Hi @p_shep ,

  Code running in the internal QSPI flash, then when you suspend execution with the debugger, it will means your related flexSPI is also suspend, when you modify the memory, it will meet the issues.

   Do you try to modify the memory when the code is running? I mean use the code to modify the memory, then printf it, whether that method works or not? If it works, then the issues is the debugger and IDE suspend, it stop the flexSPI communication for the flexRAM.

Any updated information, please kindly let me know.

Wish it helps you!

Best Regards,

Kerry

[p_shep]

Code running in the internal QSPI flash, then when you suspend execution with the debugger, it will means your related flexSPI is also suspend, when you modify the memory, it will meet the issues.

That's what I suspecting. Have a feeling it'll never work - just have to work around it somehow.

Thanks for the help.