Softreset not working if executing from OctalSPI flash

[wernerkullmann]

Hello, I am using the embeddedartists imxrt1062 board which has the adesto ATXP032 as serial octal NOR flash. My application is burned into the NOR flash and is starting well at Powerup. Now I encounter the following problem: As soon as I try to make a soft reset by setting bit 2 in AIRCR or forcing a watchdog reset to occur the processor reboots, but then stays in the ROM bootloader of NXP. I have the impression that the serial flash cannot be read anymore and so the bootloader decides to go into Bootmode 01 = serial boot. SRC_SBMR2 show after a POR and after the softreset the value 02 which is right. As long as I am in my application I can read the flash, after the softreset I only read 0xffffffff. For sure my application changes the clocks, but if this is the problem then it could only be the moment when th ROM bootloader reinitializes the CCM(_ANALOG) registers.

I am already busy with this issue the whole week, so a quick help would be appreciated.

[wernerkullmann]

@Juri: Thank you for your answer. It is more or less what I suspected. Luckly I am in a prototype situation and can change the hardware.

@Mark: Also thank's a lot. This seems to be another appearance of the same problem.

Now I await the delivery of a watchdog chip (ADM6320) which will be triggered by an IO pin. So, I will have a POR signal which should solve the problem.

Marc, you are right: It was better to analyze the situation and try to find a solution by correcting the real reason, but a.) the time is running away for me and b) this would mean to do something when the application is running and there is no guarantee that the watchdog tried to reset already before and then I have the lock situation again.

Again thank you for your help!!! I let you know if I was successful!

Regards

Werner

[mjbcswitzerland]

Werner

I did some investigations:

1. When I run the code from QSPI flash commanded resets and WDOG-3 timeouts cause the processor to restart and the rest cause is correctly identified. Therefore I don't believe that the power supply to the processor generally needs to be removed during a reset. This seems to be inverse to what you find on your HW (?)
2. I added an output that is toggled a number of times as soon as the processor starts running code so I can reliably see whether it starts or not. Also I have a logic analyser monitoring the QSPI lines to see activity there.
3. When I move the program to internal RAM instead of leaving it in QSPI flash there are no QSPI accesses when it is operating. The flexSPI LUT is changed and the RAM is re-organised, but otherwise the program runs as before, apart from the fact that it doesn't restart when a reset is commanded or when the watchdog fires - a reset takes place since outputs that were active (eg. driving the LED) become inputs.

In this state I see neither any QSPI Flash accesses nor that the program starts (it doesn't toggle the output as it does as soon as it starts). I cannot connect to the chip with the debugger in this state.

This suggests the following to me:
- a reset certainly took place
- the ROM loader didn't try to access the QSPI
- the ROM loader is not in ISP mode since the USB doesn't enumerate and also, if it were to be in this mode, I would be able to connect the debugger to the chip and see it running.
- the ROM loader must be either in a different mode (that I don't know since I can normally connect the debugger in all modes) or has crashed, leaving the processor in a state that can't be connected to.

What I don't know is whether the fact that the application changes the FlexSPI LUT setup or changes the FlexRAM (the two main differences) causes the problem - I will need to try to find a way of running from RAM without changing one of the two each time (or maybe reinstalling the states before a commanded reset is issued)

Although I don't have a final conclusion yet the intermediate results are pointing to quite a serious restriction since I have never experienced such processor behavior before. If the application's own configuration when running can effectively put the ROM loader "out of action" so the processor cannot run again without a power cycle and can't even recover from a watchdog reset one is forced to add external HW to save the situation and simple warm resets are impossible to do (adding implications for boot loader strategies and such).

I have quite a bad feeling at the moment that there is a serious bug in the chip itself and think that NXP needs to do similar tests - in fact the firmware here [https://community.nxp.com/thread/524690#comment-1270214 ] can be loaded to a standard board and shows how the reset/watchdog of the chip can be effectively completely taken out of action!!

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[mjbcswitzerland]

Werner

I have a work-around for the commanded reset case.

If I set the FlexRAM back to use its setting from eFUSE defaults it restarts:

    IOMUXC_GPR_GPR16 = (IOMUXC_GPR_GPR16_RESERVED | IOMUXC_GPR_GPR16_INIT_ITCM_EN | IOMUXC_GPR_GPR16_INIT_DTCM_EN); // set the FlexRAM layout back to that taken from the eFuse setting (default configuration)
    APPLICATION_INT_RESET_CTR_REG = (VECTKEY | SYSRESETREQ);             // request Cortex core reset, which will cause the software reset bit to be set in the mode controller for recognition after restart

This tells me (and I believe I managed to see it once with the debugger connected before it lost connection) that these types of reset don't reset the IOMUXC. This is also confirmed in the user's manual:

My explanation is that, since I disable OCRAM and the ROM loader uses it for its stack the ROM loader can no longer operate (without RAM) if I don't set it back.

This is OK for the reset case since one can control the FlexRAM layout (as above) to ensure that it always works reliably. But the watchdog case is not guaranteed - one needs to install a watchdog interrupt handler to prepare for the subsequent reset (which takes place 255 clocks later). This is however not fool-proof due to the fact that in the case of a serious firmware runaway error also this interrupt may fail (or its vector in RAM be lost).
Also in a system where the FlexRAM is left in its default state there is no guarantee that runaway code can't write to IOMUXC_GPR_GPR16 and change the configuration (this can't be locked/protected against), meaning that in high reliability systems I think that one is forced to use an external HW watchdog to recover via a power on reset (which can't subsequently be detected in the reset controller....).

It would be better if this register were really set to its default value on a COLD reset so that the ROM loader is not killed. or if the ROM loader itself would write IOMUXC_GPR_GPR16 = (IOMUXC_GPR_GPR16_RESERVED | IOMUXC_GPR_GPR16_INIT_ITCM_EN | IOMUXC_GPR_GPR16_INIT_DTCM_EN);

as its first line of code to ensure that it can actually operate in every situation.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[wernerkullmann]

Hi Marc!

Unfortunately for me this doesn’t work (I don’t modify IOMUXC_GPR_GPR16 in my application). Maybe there is another register in the IOMUXC block which creates a problem. I will check this soon and let you know, but as you wrote: The real watchdog case after a crash then would be still pending. This means: the final solution must be a hardware watchdog creating a POR.

Regards

Werner

Von: mjbcswitzerland <admin@community.nxp.com>

Gesendet: Mittwoch, 19. Februar 2020 16:23

An: Werner Kullmann <kullmann@ingkullmann.de>

Betreff: Re: - Re: Softreset not working if executing from OctalSPI flash

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg> NXP Community

Re: Softreset not working if executing from OctalSPI flash

reply from Mark Butcher <https://community.nxp.com/people/mjbcswitzerland?et=watches.email.thread> in i.MX RT - View the full discussion <https://community.nxp.com/message/1271411?commentID=1271411&et=watches.email.thread#comment-1271411>

[mjbcswitzerland]

Werner

At the moment I tend to agree that in mission critical systems one can't afford to rely on the internal watchdog. I presently use just WDOG3 but I will look into adding the use of WDOG_B output (with a slightly longer delay than WDOG3) in order to be able to trigger an external power cycle in case the first watchdog reset fails. Maybe it will be possible to devise a simple and cheaper circuit to ensure recovery than the one in the reference HW designs or needing to use a dedicated external watchdog?

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

[wernerkullmann]

Hi Marc!

Only to complete it: I now tested with an external watchdog-chip and -as expected- it works. I used an ST STWD100. There I have the advantage that a 2nd signal can deactivate the watchdog and yes I know before a crash this signal could also have been deactivated and I would have no reset, but with this risk I will live…

Once I also tried with the watchdog output from WDOG1 and connected it to the POR, but I had no success. Finally this lead me to the decision to use an external chip.

Thanks a lot for your help!!!

Best regards

Werner

Von: mjbcswitzerland <admin@community.nxp.com>

Gesendet: Donnerstag, 20. Februar 2020 17:38

An: Werner Kullmann <kullmann@ingkullmann.de>

Betreff: Re: - Re: Softreset not working if executing from OctalSPI flash

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg> NXP Community

Re: Softreset not working if executing from OctalSPI flash

reply from Mark Butcher <https://community.nxp.com/people/mjbcswitzerland?et=watches.email.thread> in i.MX RT - View the full discussion <https://community.nxp.com/message/1272338?commentID=1272338&et=watches.email.thread#comment-1272338>

[mjbcswitzerland]

Hello Werner

I have a similar but not the same issue:
With the NXP EVKs I can run code in QSPI Flash and command SW resets or allow watchdog resets to occur and the processor starts:
If I however run code in RAM and use the QSPI for other purposes (in addition to booting), meaning I change the FlexSPI configuration in the application, it never restarts after either a watchdog reset or a software commanded reset. I need to push the reset button for it to restart.

Since I only just noticed this I haven't studied it in any detail yet but did see (with debugger attached) that the ROM loader is operating, meaning that I have a similar case.

I don't expect that it has anything to do with board power but that after the reset the ROM loader can't correctly read from the QSPI - maybe there are some settings that are retained through a reset.
I'll be looking in to it shortly but I have a feeling that the there is a problem with the reset mechanism in the chips since it should not be possible to effectively latch-up the processor/board with a software/watchdog reset - a watchdog reset should guarantee recovery but it doesn't, due to what every different reasons we are experiencing.

In any case this needs to be understood so that reliable designs can be achieved - hopefully you can identify the issue you have and maybe I can report later on what I find.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[Yuri]

Hello,

  It is highly recommended to remove power (voltage source) to all components on
the board in the event of a processor reset. This avoids problems with proper state of
components, critical for rebooting the processor - if  they are in the necessary state to

support  a reboot. So, the total POR may be recommended for reboot (via WDOG).

Look at UM805RE (U5) circuit on the reference design. 

Have a great day,

Yuri.

-------------------------------------------------------------------------------

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.