about After WDOG RESET

[soichiyamamoto]

Hi,

I examine software of WDOG RESET.

After WDOG RESET, does IOMUX,DDRMC do Lost?

Best Regards,

soichi

[johnfielden]

Opps.  Spoke too soon.  We blew the BT_FUSE_SEL fuse with other fuses at zero to indicate QSPI booting.  Issue is still present.  What is the "correct" shape of reset?

[jiri-b36968]

Hi John,

"correct" reset is 0V (logic 0) for about 150us - functional reset  (about 500us when POR)

Please note that POR reset (descructive reset) is different than WDOG reset (functional reset) - other part of your board/module could be in different state compare to POR. Please check if your code does not rely on some state of used peripherals/memory.

Just for sure - note that BT_FUSE_SEL = 0 is GPIO boot, if BT_FUSE_SEL = 1  (blown)  is boot from fuses (if BOOT_CFGx are 0, than boot device is QSPI0).

Need better description what exactly failed:

• What board/module you use ?
• What is booting device ? QSPI single -parallel QSPI0 or QSPI1 ?
• Which WDOG you use A5 internal or WDOG-A5 or WDOG-M4?
• Is WDOG set to generate RESET or just interrupt?
• Is RESET signal present after WDOG activation
• Does XTAL started ? (bias)
• Does Vybrid started to read from your booting device (QSPI)? - see it on oscilloscope.

/Jiri

[johnfielden]

We have the boot selection set to QSPI, which we belive is the fuses are zero, so not blown.  We blew the BT_FUSE_SEL to ensure that the device would boot from QSPI on a reset edge.

We see similar timings on RESET to what you described, 150us, and the 500us for POR.

The board is our own design, simular to the Phytec design.

Using a single QSPI tied to QSPI0.

The XTAL bias does start, up to 500mV.

Checking with SW, but we have only used the A5 so far.  The M4 is held in reset as far as I know.

No accesses to the QSPI are seen on an oscope.

The rest I'll have to go ask about.

[jiri-b36968]

Hi John,

will try to reproduce it here. Please send me the project. There are three WDT in the Vybrid. Which WDOG you use A5 internal or WDOG-A5 or WDOG-M4?

/Jiri

[johnfielden]

I cannot send you the project.  It is part of our Nucleus build.  Our SW person was working on a bare metal version to send to you, but we've fixed it in the meain time.

We are using the WDOG to generate the reset.  The reset is a 100usec long pulse generated by the Vybrid itself.

After your last post, we went back and looked at the QSPI.  I was wrong, we are seeing some accesses, but a failure to boot.

Tried the same code on the tower board.  It also failed to boot.

We dropped down from 100MHz QSPI to low speed single data channel, and the problem went away.  Appeared to be speed dependent.

Next we, increased the QSPI speed to 74MHz without a failure.  Still failed at 100MHz.

Next, we replaced the crystal with an external oscillator.  That cured the problem.  We can now WDOG reset and reboot at 100MHz QSPI.  But, only with an external oscillator that is enabled by a second microcontroller.  Good for us, but not for others maybe.

[jiri-b36968]

Hi John,

New datasheet limits QSPI frequency to 80MHz especially due to limits of memory producers. That would be the reason.

Frequency strongly depends on the memory. SPI signal waveforms from oscilloscope could help. Also reset signal lenght could be very important factor for the memory. You can try to prolong it by external reset circuit if the memory require longer reset.

/Jiri

[jiri-b36968]

Hi Soichi,

yes IOMUX and DDRMC will be reset after WDOG reset. From  Table 17-1. Reset Functionality in RM:

/Jiri

[johnfielden]

Any reported issues using the WDOG to reset the part?  We are seeing a failure to reboot after the WDOG asserts reset.  The power supplies are all stable, and we see the external reset pin toggle, but the processor doesn't reboot.  Is this an RCON issue?  Trying to boot from the wrong source perhaps?

We're still looking at it, but I thought I'd ask if there were any known issues.

Thanks,

John

[jiri-b36968]

Hi John,

no know issue. WDOG reset requests can be masked in SRC_SCR(CM4_WDGRST_MASK and CA5_WDGRST_MASK). But you said that you see /RESET line toggle.

Please check RESET signal for level and shape. If boot fail after correct RESET then I start to think that you boot from different source than you expect. Please ensure that BOOTMODE and RCON pins are on correct level during RESET. They are sampled during RESET. BMOD setting can be checked also in SRC_SBMR2 register (also fuse sel bit ) and RCON in SRC_SBMR1. Please note that it is what should boot not what actually booted - it is setting captured during reset.

Please start with check if XTAL is biased (unconnect external oscillator) - it will signalize that BootROM code started. Then proceed to check booting device setting.

/Jiri

[johnfielden]

Thanks, I think we found the issue.  RCON pins occured to me after I wrote the post above.  We found one pulled the wrong way.  Planning on blowing fuses later, so we didn't think of it till now.

[soichiyamamoto]

Please give me an all of support teams answer.

Best Regards,

soichi