What is the differences between software reset and hardware reset? What are those things which hardware reset does while software reset can not?
I want to know about it because i have a problem which i can solve by only hardware reset. Software reset can not help.
Any idea?
Here is some info that I know…
soft reset: See AT+CFUN in AT manual. It does GSM/GPRS detach. So, the network gets notified that module is no longer on network.
hard reset: abrupt power off. no time for firmware to do GSM/GRPS detach. So, network assumes that you are still present on network but in idle state. I am told that when you power up after a hard reset, it may take a bit longer for GSM/GPRS attach since the IMEI/IMSI is already present on the network. I haven’t really tested this.
Either way, network registration will be successful. So, no big issue.
What the issue that you facing with soft reset?
Actually i face a problem occasionally which is happening just after wip_init function. After executing this function the module resets itself, starts from the beginning. And it again resets itself in a loop when it executes the function next time.
I am not sure it is related wip_init or somethingelse. Because it happens rarely, i havent investigated in details. What i know is that only hardware reset can solve the problem when it happens. AT+CFUN=1 can not help. And the adl_initType value is ADL_INIT_POWER_ON on each reset.
If it seems to happen after wip_init, then stack size would be the first thing to look at…
We have nearly same problem with some Fastrack Xtend modems when Tcp connection is established!
see log:
[GPRS]: open: -> DISCONNECTED
[GPRS]: start: -> CONNECTING
[GPRS]: GPRS CTX (cid=1) found
[GPRS]: GPRS EVENT SETUP OK (cid=1): GPRS activate
[GPRS]: GPRS CTX (cid=1) found
[GPRS]: GPRS EVENT: 27 (cid=1)
[GPRS]: GPRS CTX (cid=1) found
[GPRS]: GPRS EVENT ACTIVATE OK (cid=1)
[GPRS]: GPRS: -> CONNECTED
[WIP] new TCPCLIENT 0x180c8cfc
+WIND: 13
+WIND: 1
+WIND: 16And it can only be solved by a real hard reset, powering the modem off several seconds.
The failure is also visible in current consumption which is 4mA @ 24V higher than normal.
The error situation can be reproduced by power off the modem shortly for 1s and power on immediately.
Bug report is already at Sierra, but still no reply.
best regards,
Gregor
What about using the RESET pin?
Should i check stacksize by adl_memGet wheather it is full or not in this state? Do you have any opinion about determining the suitable value for wm_apmCustomStackSize constant? Can you explain in details?
adl_memGet uses Heap - not Stack.
No: I’m afraid this is one of those things that has never been documented - so it’s always been a matter of trial-and-error guesswork. 
See also: