Watchdog reset in W32K mode while open TCP connection


#1

Hi

I get unregular watchdog resets while I am in W32K mode (sometimes after 10s, sometimes after 20 minutes). Yes, I know what you think, seems logical in W32K mode, everything is slow… But:

The problem is, the only thing I do during this mode is to keep a tcp connection open. I do not send, nor do I receive. I have no timers active.
No ports subscribed, no keyboard pressed. No interrupt. Did I forget any source of events?

the aim is to do some at commands and a short tcp submission every 1 minute. But I stopped that to find the cause of the whatch dog reset. And it still resets. If I do those things (at commands, tcp submission) there is no difference in behaviour.

Has anybody an idea how to find the cause of a watch dog reset?

cheers
Philipp


#2

Well,

  1. What module, OS version and OpenAT version are you using?
  2. How do you know the reset is caused by a watchdog?
  3. What TCP library are you using?

I have to say I’m not using TCP yet but I’ve never seen a module reset on it’s own without a good reason. Please try to simplify your application down to a few lines of code and check the problem is still there, then post it here.
I guess you have a problem somewhere in your code. :wink:

Well I’d write something on UART1 (with adl_atSendResponse(ADL_AT_PORT_TYPE(ADL_AT_UART1, ADL_AT_RSP), “Hello!”); )whenever any OpenAT handler (timers, TCP callbacks, AT command handlers) is entered or leaving. Probably you will see, e.g., “Entering myTimer1-handler…” then a “+WIND: 3” indicating the module reset. Then it’s the handler causing the problem.

Milan


#3

Thanks for your answer.

I have news indeed. It has nothing to do with TCP because I stripped down the code to a main which basically plays a melody on the buzzer (for debug reasons) and switches to W32K mode and it still happened. I’m just running another test.

In the testverion which still caused resets, I’m not using Timers, I have no connections on Ports and I have no TCP traffic as stated before.

I’m using Q2686 and tried OpenAT Version 4.00 (OS 660) and 4.12 (OS 661).

I know the watchdog is causing the reset, because I get this message from retrieving the Backtrace informations (adl_errStartBacktraceAnalysis,adl_errRetrieveNextBacktrace). Even I dont know exactly how to interpret this data, as long as I find an Ascii string saying “watchdog” I’m taking this as a wachdog reset. Also adl_main doesnt start with Exception or Error.

However, the more interesting news is that I have a working version again. The only change I did to my larger application is NOT to close Uart1 (at+wmfm=0,0,1) when switching to W32K and that works! (To close Uart1 is the only way to switch to W32K when UART1 is connected to the terminal, because an active RTS is keeping it from going to W32K mode)
I keep a TCP connection open all the time, I do have a timer running (restarting it every timer event, so it can’t cause any event jam), within this timer, I send tcp messages every minute, I check battery voltage and connection quality every 10s (AT+ADC?,AT+CSQ).
So far it continues to run in W32K mode for 2.8 days, which would solve my problem without a real explanation and a somehow unease feeling…

Your doubts are reasonable, I would doubt as well. However, because I tried allready so many versions without comming closer to a solution, I ask for help in this forum.

I will post my code as soon as I have a second proof for my alligations…
thanks for watching my post.


#4

I think I’ve had problems during a data call, since it sort of closes the UART1 as well: the module cannot write to it (it’s used for the data), so the module buffers the responses, hoping to flush them later. But when the buffer gets full, the module crashes. I think the buffer was about 2KB.
In other words, try to stop sending any messages to UART1 in the W32K mode and see if the module can run for a longer time. Or add some useless messages and see if it crashes sooner. Keep in mind that there are also unsolicited responses, such as +CREG: or +WIND:.

I’m sorry I can’t think of another explanation why your “fix” works.

Milan


#5

Hi Milan

Thanks for your interesst. The reason why I still haven’t posted any code, is because I couldn’t get the effect again. However I didn’t test enought as well. This time, I will post some code just to give some more comments about it (I find it tyring to watch at pages of code posted in this forum, however there it is).

#include "adl_global.h"
const u16 wm_apmCustomStackSize = 1024;

#define TRACE_TERMINAL(STRING) adl_atSendResponse( ADL_AT_PORT_TYPE(ADL_PORT_UART1,ADL_AT_RSP), (char*)STRING)
#define false 0

void playSound();
void switchToW32K();
bool onSwitchToW32KDone(adl_atResponse_t* i_pArgs);
void closeUart1();
bool onCloseUart1Done(adl_atResponse_t* i_pArgs);




void adl_main ( adl_InitType_e i_eInitType )
{   
	switch(i_eInitType)
	{
	case ADL_INIT_POWER_ON:
	    TRACE_TERMINAL("ADL_INIT_POWER_ON");
		break;
	case ADL_INIT_DOWNLOAD_SUCCESS:
	    TRACE_TERMINAL("ADL_INIT_DOWNLOAD_SUCCESS");
		break;
	case ADL_INIT_DOWNLOAD_ERROR:
	    TRACE_TERMINAL("ADL_INIT_DOWNLOAD_ERROR");
		break;
	case ADL_INIT_REBOOT_FROM_EXCEPTION:
	    TRACE_TERMINAL("ADL_INIT_REBOOT_FROM_EXCEPTION");
		break;
	default:
		TRACE_TERMINAL("default");
	}

	playSound();
	switchToW32K();
}

void playSound()
{
	u16 pMelody[] = {
		WM_SND_C0		| WM_SND_QUAVER,
		0
	};
	wm_sndMelodyPlay(WM_SND_DEST_BUZZER, pMelody, 2, 1, 13);
}

void switchToW32K()
{
	u8 nRspflag = ADL_AT_PORT_TYPE(ADL_PORT_NONE, FALSE);
	u8 nReturnValue = adl_atCmdCreate("at+w32k=1", nRspflag, onSwitchToW32KDone, "*", NULL);
	if(nReturnValue != OK)
	{
		TRACE_TERMINAL("at+w32k=1: CmdCreate failed");
	}
}

bool onSwitchToW32KDone(adl_atResponse_t* i_pArgs)
{
	TRACE_TERMINAL(i_pArgs->StrData);
	//closeUart1();
	return false;
}

void closeUart1()
{
	u8 nRspflag = ADL_AT_PORT_TYPE(ADL_PORT_NONE, FALSE);
	u8 nReturnValue = adl_atCmdCreate("at+wmfm=0,0,1", nRspflag, onCloseUart1Done, "*", NULL);
	if(nReturnValue != OK)
	{
	    TRACE_TERMINAL("at+wmfm=0,0,1: CmdCreate failed");
	}
}

bool onCloseUart1Done(adl_atResponse_t* i_pArgs)
{
	TRACE_TERMINAL(i_pArgs->StrData);
	return false;
}

As you can see, the parts of the code to close Uart1 is not used (I commented closeUart1).

That’s what I have in mind as well for being responsible for the reboots. However, I already tried your suggestion to post a lot to Uart1 and not to use it at all. There was no difference.

Now some Explanations:
To make sure, I have a fresh platform, I also reinstall the OS before running the tests, later more about that (I’m still working with OS 660 because OS 661 has a bug with buzzer output, I allready posted it in the forum)

After a reinstallation of OS 660 and the at+wopen=1, if I install the above software as it is, the current consumption is not getting low.

Then I put in the closeUart1 line and install just the application. The current gets low immediately, and I can expect a reboot somewhen (20sec - 20minutes or longer until reboot).

The next step is to reinstall the first software again. Now, after 10-15sec, the current dropps. Communication is off with terminal. No reboot.

When I tested my real larger application (I do not close the Uart1 anymore to avoid reboots) the current didnt dropp, as described above.

So I installed the above software above whith closing Uart1, run it and overwrote it again with my large application.

That’s how I get my large application work with dropping the current and stable. The supprise however is, that I have a working Uart1 communication with the terminal software as well!

Well, obviously I do much more in my application than just the posted software, however I haven’t found out the reason for this behaviour.
Nor do I understand why I can’t open and close Uart1 in the running application without the risk of a reboot.

My next step will be to create a Flag in the FlashROM and close Uart1 if no marker is set (at the first run of the software) then set the flag, cause a reboot and never use at+wmfm again. However, this has yet to be tested…


#6

Hi phhuber,

I’m also using Q2686 with OS 6.60 and I had some problems with shutting down UART1 (without W32K, with the wmfm-cmd or dtr)) too. I recognize if the processor has a lot of workload (reading GPS data and so on) after several minutes I get a network lost for a few seconds. If I leave the UART1 running everything works fine. I contacted my distributor and they said its not good shutting down the UART.

I also made some experiments with w32k and I caused some crashs. The crashs had definitley somethings to do with the workload, for instance 1 cyclic command (creg, adc…) works, but more timer or commands leads to watchdog reset. The w32k-Mode under OpenAt seems to me very unstable.

Marcus.


#7

marcus

Good to hear that I’m not the only who has trouble with w32k mode. I’m getting crazy with it.
I couldn’t reproduce every time, what I wrote above. So suddenly my large application also wouldnt go to lo power anymore.

My current hunch is, that I shouldn’t open and close uart1 all the time. However, whitout closing recently I can’t get to low power at all. so I closed it once after a new OS installation and the installation of my application. so far it works (20 hours)…

What are you doing to use w32k mode? did you give up on it? I wonder, currently I also cant get any effect with the RTS signal…

I might have to go back to my very start of the w32k evaluation.

Since it is difficult to reproduce I havent told my distributor any specific report yet.

cheers
Philipp


#8

Hi phhuber,

I only use the w32k-Mode with 1 1-s-Timer (monitoring a pin). That seems to work. To achieve this mode I shut down the UART1 with at-wmfm (DTR also works…) and then I send at+w32k. When the modul has more to do I do not enter any power save mode. Although you can save a lot of power by only shutting down UART1 without AT+W32K (36mA --> 18mA) I do not use this mode in certain cases:

  1. When I make a call (shutting down UART1 leads to a crash) <–> When I answer a call it works!
  2. When I have a lot of workload -> lost of network happens.

When I run my application in normal power mode everything works quite stable.

Marcus.