Watchdog


#1

Hi,

because Wavecom is using the ARM7 internal watchdog in order to protect the firmware against the OpenAT application, we must install an external watchdog in order to protect our customers against a not attainable modem. Looking into the basic development guide I found an example from wavecom which is using GPO to trigger an external watchdog. Does this mean that the firmware can generate the trigger itself or must I implement an OpenAT application to do this? Further if I implement an OpenAT application, can I use GPO to trigger the watchdog or is this output used for other purposes too by wavecom?

Best regards
Ralf


#2

Not sure I understand what you mean by that - could you explain a bit more?

Yes, Open-AT Applications can control GPIOs - see the GPIO Service in the ADL Manual


#3

Hi awneil,

our devices, which are installed at the end of the world, using the modems integra and q2406b/c from wavecom to send data to several servers or get changes of their settings from a remote maintenance system. Sometimes the modems are not reachable — neither over the air nor local over the serial interface. The only way to reactivate the modems now is to drive to the device and make a power on reset.
Because this is expensive we looking for a way to detect and solve the problem automatically using a watchdog. Unfortunately the internal watchdog of the ARM cpu is used from wavecom to detect never ending loops in the OpenAT application so we must install an external watchdog. The basic development guide from wavecom has an example how to implement and trigger such an external watchdog. Because the most of our modems does work with at# commands I hope it’s possible to trigger the watchdog from the modem itself.
I know this is not a real OpenAT problem yet but maybe some of the members of this forum has experience using an external watchdog. If we design a watch doc using the example from wavecom and must trigger the watchdog by an own application it will be an OpenAT problem …

Best regards
Ralf


#4

Hi Ralf,

I have seen that too, that devices were not reachable. In our case, I think, it was the network operator. On the device everything looked OK, it even said on debug outputs, that is is registered on the network. The application did run OK, but the device could not be reached over GSM… If you have a similar problem, I don’t think a watchdog could offer you any help…

We have also tried this without application, just with AT commands, and the same thing happened. Although it looked like everything is OK the modem was unable to communicate over GSM until it was reset and the PIN re-entered…

Best Regards,
Jan


#5

Hi Jan,

we had the problem which you mentioned too, but we solve it by sending an at+cfun=1 to the modem one time per day. But sometimes the modem isn’t reachable over the serial interface (or better we get no response for any command send over the serial line to the modem) so we can’t restart the modem on this way. Because we can only restart the modem with power up I assume that a watchdog will help to solve this problem.

Best regards
Ralf


#6

Hi Ralf,

OK, I see… I am not sure if the core firmware has support for external watchdog that way that it could recognize that communication over the serial line is not possible. So you basically would need to send some command in a certain interval and if this is not received it will trigger a reset…

It would be quite simple to write an application to perform an at+cfun=1 if it didn’t receive a certain stimulus in time but that does not fit well for the at# commands since this already needs an application installed in the modem…

Best Regards,
Jan


#7

Hi again,

one more thing… If it’s not reachable by serial port, will it still give you output over that port? You could for example activate battery indications (at+wbcm) and see if those stop, too.

If the communication stops working both ways, I guess you could design a hardware circuit, that monitors if some data is received and if not the power to the module is shut down and restored after a wihle so giving the modem a quite hard reset :wink:

Best Regards,
Jan


#8

Hi Jan,

yes, the circuit to monitor the communication will be a good idea, thanks.

Best regards,
Ralf


#9

Could your servers (the ones connected to the modems) do this?

If there is no activity on the COM: port, they activate the modem’s RESET line, or cycle the power…

Simple devices are available that connect to a USB port and could provide a RESET signal…


#10

I think that Ralf’s modems are not connected to computers…


#11

Aonther option might be the +CCED: indications, with periodic updates…

Do you have +WIND: indications enabled?

Could be worth logging these things to see if there’s anything that could identify what’s happening…


#12

Hi Jan, Hi Awneil,

our devices are connected to the modem with an RS-485 connection because the devices partly are in an ex-zone and the modems in the non-ex-zone, so we have no control line to them. Because our devices are battery based we minimized the unsolicited messages to minimize the battery consumption. And this makes CCED impossible too :frowning:

Best regards,
Ralf


#13

Ralf,

some Application note shall be available from your distributor or from your contact in Wavecom directly to create a watchdog monitring the full system (Wavecom FW and OPEn AT Application…)…
Hope this would help…


#14

Hi,

I’ve also asked wavecom via our distributor but this way of communication is very slowly :frowning:

Regards,
Ralf


#15

:imp: anyway the principle is quite simple: you put a watchdog chipset that you reset with a pulse generated by the Open AT Application OR by the DTR signal ( this signal is active during the OPen AT Apps download as you might not want the product to reset when you try to download your apps…) and you plug the output of the watchdog on the reset PIN of the module. you might want to use a chip from TI TPS3813L30 with a 20s timer.

Now you have a watchdog dedicted to monitor your Open AT Application while the internal watchdog will monitor the good behaviour of the firmware!!!

You know that you may even use the back traces to check after reset if the reset was unexpected (internal watchdog==FW issue) or through the “normal” reset external watchdog==OPEN AT issue… now you can monitor the status your device on field…

hope this helps


#16

Don’t excite please kaliwing.

In some of our devices I can’t use an OpenAT application to trigger an watchdog because they need the EdSoft application to create GPRS connections using AT# commands. Further this devices are connected with an RS485-interface to the modem, so we don’t have a DTR signal (or which DTR signal do you mean?).

Normally a watchdog is used to prevent a problem in the firmware, not in an extended application. Because wavecom don’t use the watchdog in this way and describes how to implement an external watchdog to do this I assume that wavecom have a solution for this. That’s why I’m waiting for an answer from wavecom.

An other possible way to reset the modem is sending a special character which can be recognised by the a watchdog, e.g. a break. But in this case we must change our firmware in hundreds of devices and recertificate this new firmware. So this way is very stony …

Best regards,
ralf


#17

no problem I’m just experiencing the same with my distributor big buffer time betwen question and answer!!

sorry my solution couldn’t work for you