CPU running from RAM halted during page erase

RE: CPU running from RAM halted during page erase

pavel.kucera — Wed, 28 Oct 2020 08:28:06 GMT

Thank you for the tip! Checking, that nvmc_page_erase is called from RAM was not enough, wait_for_flash_ready() was not inlined despite "inline" suggestion to compiler, after adding "__attribute__((always_inline))" it is really inlined and the IRQ is triggered, now I just have to check all dependencies of TWIS IRQ handler are really in RAM.

RE: CPU running from RAM halted during page erase

Kenneth — Tue, 27 Oct 2020 14:04:36 GMT

With the help of a colleague we can see the same here, so it looks like there is still some hardware dependency that prevent this to work with interrupts even when running from RAM.

Update: My colleague may have made it work now, I am attaching an example that use timer to trigger a timer interrupt during the flash operation, it show in principle it should work. Hope the example can be of use.

devzone.nordicsemi.com/.../3364.sdk_5F00_17.0.2_5F00_peripheral_5F00_nvmc_5F00_cpu_5F00_halt3.zip

Maybe your problem can be related to the flash wait is not inlined (ref wait_for_flash_ready()).

Alternative solution: The page erase can be done partially by using ERASEPAGEPARTIALCFG, e.g. run flash partial erase 9 times with a duration of 10ms = 90ms (which is more than the required 85ms). Then you can have application interrupts only delayed by 10ms during erase.

Best regards,
Kenneth

RE: CPU running from RAM halted during page erase

pavel.kucera — Tue, 27 Oct 2020 13:35:41 GMT

NVMC->ICACHECNF is 0 in this configuration. Targeted master is capable of clock stretching, but not for tens of ms, it will timeout way earlier. The setup from scope picture is not with targeted master. Will try to investigate if there is other interrupt left enabled from MBR that could touch flash and cause the stall here.

RE: CPU running from RAM halted during page erase

Kenneth — Tue, 27 Oct 2020 12:24:32 GMT

Interesting, I assume you have verified by debugger and possibly breakpoints that the code don't "touch" the flash here when jumping to the vector table in ram. Could be interesting to see if the cache have any influence on this:
https://infocenter.nordicsemi.com/topic/ps_nrf52840/nvmc.html#register.ICACHECNF

This is a slight corner case, so not sure if this actually have been tested, so it may be that you need to avoid interrupts while running the code from RAM while nvmc is executing, for instance you may need to handle the twis directly. Though typically it is allowed in twi to delay and stall bytes by clock stretching, this is something that the hardware will automatically do if the CPU don't process or handle the data fast enough. Does the peer twi master device support clock stretching?