Modem waits in protection mode

Hello,
I have been trying to solve my problems on my FXT002, FTX009, FW R7.43 modems for a while. I have created several topics about these problems. Now i have investigated a new problem.
There was a problemmatic modem on the field and i asked my customer to send it back to me. I received it yesterday. i read my custom logs which my open at software saves in flash.
According to the logs, it seems that modem software has stopped working somehow. My Open AT software checks the time in each 5 minutes and it saves a log record on midnight. So there must be at least one log record in each day.
However, there are no log records during 6 days.

  • 2nd Jan through 11th Jan 07:56 -> there is no log.
  • 11th Jan 07:56 through 11th Jan 23:17 -> working.
  • 11th Jan through 18th Jan -> there is no log.
  • 18th Jan 09:00 through 18th Jan 09:19 -> there are 47 resets! and after that there is no log until 24th Jan.

So, i suspected that something puts the modem a protection mode. As i mentioned above, there is a reset loop 47 times within 19 minutes!

The question is if there is a protection mechanism in Fastract Xtend modems and if so how can we indicate the reason why the protection mechanism occurs.

Thanks.

There is a recovery mechanism built into OpenAT. (see attachement)
Perhaps your application tries to do something on startup that causes reset? May be it is tining-dependent. Something sometimes is not initialised before you use it?

We have a situation the field on older firmware running on WMP100. Sometimes modem locks up completely and the only way to recover is to connect DWLWIN and “erase flash objects”. I have a feeling that OpenAT has issue accessing flash and this problem may be carried to later versions, but I am unable to reliably reproduce or investigate the issue.

Rudolf
P_Recovery_Mechanism_Application_Note-Rev002.pdf.zip (179 KB)

hi rudolfl,

On startup, my application starts a timer with 4 seconds. When the timer expires, all my logic starts. And i save a log record when the timer expires. So i dont see anything that causes a reset loop on startup.

Although i am not sure of it, i think that built-in recovery mechanism stops my open at application on the modem. And i have to solve this problem because there are several problemmatic modems on the area and i do not know why they do not work. Maybe all of them have the same problem.

If there is a flash problem, i think modem will not get working again even if a power off/on is performed. In my stuation, most of the time, powering off/on will get the modem works again.

Is there anything that i can do to prevent modem reseting in a loop or going into recovery mechanism which stops open at application?

Hi.
rudolfl not mention his post: [url]https://forum.sierrawireless.com/t/fxt-009-power-supply-issue/5068/1]
Also your problems may be result of A&D memory corruption, if used. Without complete knowledge its difficult to decide.

My Open AT application does not use A&D space. It uses flash memory. Ok then, let me ask you, can flash memory curroption be fixed by power cycling?
Because the point is that, when we power off/on the modem, it starts working again(mostly). But it falls into the same stuation after a time. I know this is strange and hard to solve. But i am still searching for any reason.

Always used flash memory (you mean “flash objects” i suppose) for config variables, a&d for logging and so on. So i dont know if adl_flash suffers from the same problems as A&D, it looks solid.
But its looks like your modems suffer from the same “reset syndrome”. Link provided in previous message. Upgrade to 7.45 FW saved me from this problem without hardware redesign. The situation can be easily reproduced in the laboratory, so I think you should check this possibility.

Also you can look at [url]https://forum.sierrawireless.com/t/q2687-cfun-1-vs-reset-pin-vs-power-cycle/5357/1]

Hi victorjd,
Thanks for your explanation. Probably, i will upgrade firmware version from R7.43 to R7.46 and will watch the modems on the same location.
The problem is that i can not reproduce the issue in laboratory. The problem happens on the area in different places. Also, we may try to investigate the problem right in the area. But this will make us spend alot of time.
Anyway, for now only thing i can do seems a firmware upgrade.