I’m using the G120 and it seems like we have to choose between having the capability to use IFU or implement the hardware watchdog.
The MAX_TIMEOUT property of the watchdog on the G120 is around 16 seconds and since the flash and reboot of SystemUpdate takes longer when doing IFU, the watchdog resets the device before the flash and reset is done with the effect that the device gets corrupted.
Is there a way to disable the watchdog by writing directly to the registry?
@ olif - Maybe you can follow this approach… As soon you want to do a IFU first write a ‘flag’ to persistence storage. reboot the device, at startup check if the flag is set, and if… don’t enable the watchdog… after UFI reset the ‘flag’
I was thinking about that and it should work. I’m just a bit frustrated. We are using the G120 in production and I think that almost more than half of our code base consists of workarounds for different kind of bugs or unwanted behaviour (mostly network related bugs) which comes with the current version of .net mf and the premium library. I have no experience of writing c on emx:s but I’m beginning to wonder if that would be a faster approach.
@ olif - i am exactly at the same page… :’( and know how you feel. This week i went back to EMX (72Mhz) with netmf 4.1 to do some test… I have one project that probably could run on EMX. I was surprised EMX(72Mhz) write speed to SD card 200KB / sec. vs G120(120Mhz) 115KB/sec. As far as i know network is more stable in 4.1 as in 4.2
The timeout should not be changed, but IFU was changed a bit since g400 4.2.11.2 is added watchdog, and there no problem between watchdog and IFU on G400.
So G120 should work same with G400 at 4.2.11.2, I think
Is there a reason why the maximum watchdog timeout for the MCU isn’t used?
According to the datasheet the maximum allowed timeout is Twdclk2^244 (with the 500kHz watchdog clock that should be ~134 seconds)
For example:
static public void Enable()
{
Register WDMOD = new Register(0x40000000);
Register WDTC = new Register(0x40000004);
WDTC.Write(0xFFFFFF);
WDMOD.SetBits((1 << 0) | (1 << 1));
Reset();
}
static public void Reset()
{
Register WDFEED = new Register(0x40000008);
WDFEED.Write(0xAA);
WDFEED.Write(0x55);
}
Can you share with us the document you have?
Our document just say there is 12 bit counter, but yours looks like 24 bit.
Did you run that code?
And I don’t think 0x40000000, 0x40000004, 0x40000008 are related to Wathdog registers
Even the way to reset watchdog also different with yours way (it only accepts 0xA5 while you can write 0xAA then 0x55). If you have another document, it is very useful for us.
What about programming directly from within VS. Setting it to the Max timeout (16 secs) is not working! It reboots in the middle of flashing!
I haven’t had the chance to try Olif’s suggested code yet, which sets the timeout to near 2 mins, as supported by the G120 - LPC178x/7x.
Busy chasing other Bugs! As you well know, it’s unwise to turn on the watchdog timer before finding and killing most of them suckers!
The reason I was playing with the built-in watchdog time is to make sure it works before I complete my PCB design, in case I need to provide an external WDT. I am thinking of adding the external WDT anyways with an electronic power switch (MOSFET) to recycle power on the whole system just in case some peripheral add-on module gets stuck and refuses to be reset, or lacks a reset input, such as the DHT22 sensor I am testing now. It definitely requires power recycle, at least on its own, since it’s freezing occasionally.
