Unexpected reset after FLASH erase

[yixinwu]

Dear community,

I have a problem after erasing of FLASH low block on MPC5744P. The block has 16k. After erasing I do a FLASH status check. But there is always an unexpected reset, for which I can't find the reason. If I erase the mid block of 32k, there is no reset. If I set a breakpoint by the line of status check function, and run the software further, there is no reset either.

Watchdog is bypassed by a debug bridge. After the unexpected reset, the mentioned FLASH block has random values in it and sometimes the software stops in an access control interrupt. In the software there is FLASH protection through MPU and SMPU. I have tried to deactivate this protection but it didn't help. What could be the reason for this reset?

l_ulreturncode = HW_FLASH_ERASE(1, 0);  //FLASH erase low block 1 (16k)
fn_Appl_flasherase_status_check();  //FLASH status check

Thank you in advance!

[petervlna]

Hi,

You can see the reset reasons in RGM (reset generation module)  FES and DES registers.

After every reset the reset source is latched in FES or DES.

Share the DES/FES registers value after the unexpected reset occur.

Also it is good for test case to place while(1) loop at very first executed instruction in startup, to prevent code execution after reset occurs.

Peter

[yixinwu]

Hello,

I did what you told me and find some values in FES are set. They are bit F_EXR and F_ST_DONE.

Does it mean, that the reset is an external reset? It is a little bit strange, because obviously there was no manually reset with button. And a debug bridge is connected, so that the watchdog for MC33907 should be not the cause for this reset problem.

[petervlna]

Hi,

So lets get back to reset source.

You see F_EXT and F_ST_DONE.

F_ST_DONE is reset executed during reset phase after self-test (BIST) is completed. This is set by HW, we can exclude it.

and then you see only F_EXT. Which tells me that your reset source is external reset.

Are you handling RGM module after reset? Analyze reset sources, and then clear RGM FES/DES to be sure that on next reset you see always latest reset source?

F_EXT is most probably cause by debugger after you left debug, use attach and break. Not system up/reset.

I need to see the real reset root cause in order to help you.

You should not read flash block which is being erased. Otherwise you will get exception.

Peter

[yixinwu]

Hello Peter,

Thank you for the reply.

I have made a while loop at the very beginning of the code, so nothing is to be handeled after the unexpected reset.

Anyway I found another problem, which could be the reason for the reset. There is a UTEST area, on which I read in the software periodically. This is the NVM block 16k and has no partition assignment according to the manual. I tried not to read this area periodically, then no reset will be done while the low block 16k (block 0 or 1, partition 0) is being erased. Does it mean, if I am erasing a block FLASH, I should not read any part of FLASH, even it is not on the same block or partition? It is strange that, if I erase the mid block 32k (block 0 or 1, partition 2 or 3), there will be no reset, even when I read the UTEST.

[petervlna]

Hi,

This is described in reference manual.

So you cannot read Partition 0 while erasing it.

Peter

[yixinwu]

Hello,

This must be the explanation for the problem. Thank you very much!

[yixinwu]

Hello again,

My problem should be read-while-write error of FLASH and this causes the reset. By erasing, the whole FLASH should not be read. By us it is interesting that if I erase the two low blocks and read the value in UTEST FLASH area, there will be this error; if I erase the two mid blocks and read the value in UTEST FLASH area, there will be no error and no reset. Is this reasonable?

[petervlna]

Can you tell me which exact low flash blocks you are using?

Peter

[yixinwu]

I have problem with erasing the 2 low blocks: