Hello All! I have an issue that has come up twice over the last 7 months and wanted to pick your brain as to the best solution to solve it. I have several modems in the field and they all have the same firmware and Open AT application on them, but only one of them is giving me a problem. The problem is the the modem will get into, what seems to me, a power cycle based on a software issue in my application. I reset the modems everyday using cfun, but I can also send it a command that will trigger a micro-controller to toggle the reset pin. The micro-controller is kind of a third level watchdog for the modem, but also provides some other functionality to the unit. Anyway, the modem will “reboot” every few hours or so and neither cfun or the reset pin seems to solve this. Only a power cycle seems to reset it, which, of course, requires us to physically visit the unit. We have tried to manually reset the unit with the reset pin (button) with the same results, so I can rule out the micro-controller not working properly. Any ideas why only a power cycle will work. I figured the reset pin would do it (which is why it was designed into our units), but it reacts the same as cfun (in this scenario). I haven’t gone out there to monitor the modem, so I can’t say whats causing it. It will lasts months before it does it again though. Strange. Anyway, just wanted to get your thoughts on this…
Well, that’s not entirely a foregone conclusion - as you’ve got an external microcontroller, you could give it the facility to interrupt the power.
I presume your current hardware doesn’t have such a capability?
It’s not uncommon to have certain parts of a circuit that are not “hit” by a reset signal - so, if anything goes awry, a power-cycle is required.
eg, memory doesn’t usually have a “hard” reset - it relies on software to initialise.
Sorry this doesn’t solve your problem, but it may be of some consolation to know that it’s not entirely unheard-of.
Thanks for the reply awneil. We have actually been looking into how we can do just that with out having to re-engineer anything. Is a power cycle the only way to clear memory? The micro-controller is connected to the modem by the UART, so I am wondering if there is a command I can send it that may solve the issue. I’ll look into that now. I’d hate to use wopen=0 then wopen=1 as there is too much risk for something going wrong. Maybe interrupting the power IS the best and only solution. And no, I haven’t contacted SiWi about this yet.
Well, bummer for that! Two things I know for sure: Cycling the power solves the problem (that is, until the problem show up again) and using the reset pin doesn’t seem to help in this case. We are definitely holding the reset pin low for the required amount of time and held it low manually for even a greater length of time with no difference. Our engineer is looking into interrupting the power supply with the micro-controller and if that is even possible with the current revision of our project. One thought I had along those same lines is that currently we are just tying the ON/~OFF pin to 3.6V. If we can use the micro-controller to drive that pin low and then drive the ~reset pin low (or even better sending an AT+CPOF command), that would turn the modem off (if I am reading the integration guide correctly) until the ON/~OFF pin is driven high again. That would essentially be a hard power reset and could be implemented as a fail safe for instances such as this. Of course, we would have to undergo another engineering change. The only other idea I have that wouldn’t require an engineer to touch the board would be DOTA. It would save on engineering cost but we would have to eat the extra data cost. What are your thoughts on these potential solutions and their chances of working with this type of scenario?
@victorjd,
I believe the current firmware we are using is 7.44. I don’t have a unit in front of me, so I will have to double check, but I am almost certain it’s 7.44. Do you know what bug/improvement was fixed/implemented between 7.44 and 7.45 FW that helped clear up that particular issue for you? As we are only seeing this on one unit, this seems to be somewhat of an isolated case.
Sadly, i dont. Studying FW release notes i cant find appropriate description. But for me its working.
Some extra info. Periodically some units in the field (up to 3-4 from 2000+) began endlessly drop and reestablish GPRS-connections. Internal logs provide no useful information - just power_on restart without any reason every 2 - 3 minutes working. Restarting by AT+CUN=1 useless in this state, only power off/on.
After some more studying we a discover that any unit can be easily moved into that error state by repeated power interruptions on a very short time (up to second). It is always working from n-th attempt. After an unsuccessful search for software solution we just updated FW. And voila. No one field unit shows such symptoms anymore.