# Open AT Framework 2.51 serial port problems

**URL:** <https://forum.sierrawireless.com/t/open-at-framework-2-51-serial-port-problems/5674>\
**Category:** Development tools\
**Created:** [June 21, 2012, 7:14pm UTC](https://forum.sierrawireless.com/t/open-at-framework-2-51-serial-port-problems/5674 "2012-06-21T19:14:22Z")\
**Posts on this page:** 7\
**Page:** 2

<div class="post-metadata">

**Author:** ![pierreandre](https://avatars.discourse-cdn.com/v4/letter/p/58f4c7/32.png) [@pierreandre](https://forum.sierrawireless.com/u/pierreandre)\
**Post date:** [July 21, 2012, 4:51am UTC](https://forum.sierrawireless.com/t/open-at-framework-2-51-serial-port-problems/5674/21 "2012-07-21T04:51:46Z")

</div>

I’ve done is several times. No problems.

---

<div class="post-metadata">

**Author:** ![pvouzis](https://avatars.discourse-cdn.com/v4/letter/p/50afbb/32.png) [@pvouzis](https://forum.sierrawireless.com/u/pvouzis)\
**Post date:** [July 23, 2012, 11:00am UTC](https://forum.sierrawireless.com/t/open-at-framework-2-51-serial-port-problems/5674/22 "2012-07-23T11:00:06Z")

</div>

By using FW 7.47 and the corresponding bootloader things work much better. What still doesn’t work 9/10 times is the Start button on Target Management. It times out, although the application starts properly on the device.

The problem I have now is that the device keeps reseting every few seconds. Does it have to do with the watchdog timer? Is the watchdog activated by default when an application starts, and is the application responsible to reset it or put it to sleep? Actually, after a few times it resets by itself then it becomes unresponsive. I recall reading somewhere (but I cannot remember where; maybe in a Sierra manual, maybe a forum post) that after the device resets by itself a few times then it goes into another state. Does this ring a bell to anyone? Does it make sense?

Thanks.

---

<div class="post-metadata">

**Author:** ![pierreandre](https://avatars.discourse-cdn.com/v4/letter/p/58f4c7/32.png) [@pierreandre](https://forum.sierrawireless.com/u/pierreandre)\
**Post date:** [July 23, 2012, 11:16am UTC](https://forum.sierrawireless.com/t/open-at-framework-2-51-serial-port-problems/5674/23 "2012-07-23T11:16:20Z")

</div>

I normally use AT=WOPEN to stop and start the app, as I’ve also experienced problems with the start/stop buttons.

The watchdog is started automatically AFAIK. You can inform the watchdog if it needs to wait a bit longer. I try to avoid this at all costs, as I don’t want to have long running operations that influence the working of the GSM stack and cause it to miss a voice call or loose GPRS etc.

You can get the reason for the reset by calling adl\_InitGetType in you Task startup method. If it was a watchdog reset, you should also get a backtrace, although it won’t tell you which method took too long to execute. This is something we are seeing at the moment. Its quite difficult to determine what caused the watchdog to reset.

Finally, I suggest you start a new topic on the forum for this question, otherwise the more knowledgeable people might miss it. Good luck.

---

<div class="post-metadata">

**Author:** ![graham.pronk-jones](https://avatars.discourse-cdn.com/v4/letter/g/dec6dc/32.png) [@graham.pronk-jones](https://forum.sierrawireless.com/u/graham.pronk-jones)\
**Post date:** [November 11, 2012, 10:50pm UTC](https://forum.sierrawireless.com/t/open-at-framework-2-51-serial-port-problems/5674/24 "2012-11-11T22:50:26Z")

</div>

I’m having difficulty with serial port problems too. I’ve contacted my local distributor who is going to contact SW, but suggested I add a post here to keep the discussion alive on the forums too…

When I build and use the debug system the serial comms are not reliable. The application and debug traces work ok, but when I switch back to the target status page it all locks up and I can’t get the target info. The application in the modem usually stops too, and best way to get running again is cycling the power. But this too can be problematic. The most reliable way to get new firmware downloaded is to switch to a terminal program and start bashing out AT Commands manually: AT+WDM=0 to stop the debug, AT+WDWL to accept new firmware with X-Modem, and then AT+CFUN=1 to start the new application running. This could/should all be so smooth with the IDE!?

I’ve tried the Dev Studio on XP and Vista on 2 different machines. Build Version 2.2.1.201206182209-R9667 (but I’ve had similar problems with older versions).

I’ve tried the patch on the Vista machine - no improvement.

I’ve tried native serial and 3 different types of USB-Serial adaptors (FTDI, Prolific and Belkin) running at 11520 (with flow control).

The problem exists with a Fastrack Supreme (FSU004) and the Q2687RD modules.

And appears on all the Open AT firmware versions I’ve tried up to 2.37. (I’ve rolled the firmware and bootloader version back and forward with no real improvements).

Hope someone can help, or join in the feedback to SW so that this can be improved!

---

<div class="post-metadata">

**Author:** ![daav](https://sea1.discourse-cdn.com/flex025/user_avatar/forum.sierrawireless.com/daav/32/2767_2.png) [@daav](https://forum.sierrawireless.com/u/daav)\
**Post date:** [November 12, 2012, 8:21am UTC](https://forum.sierrawireless.com/t/open-at-framework-2-51-serial-port-problems/5674/25 "2012-11-12T08:21:17Z")

</div>

If this is possible with your HW design, you should give a try with pure USB connection (not USB-serial converter).  
Anyway, we have some clues for improvement in order to reduce the load of data exchanged between DS and the target at connection/refresh time. As this is probably the main reason for current instabilities, this will help to improve the user experience, even on classic serial connections.  
These improvements will be integrated in next DS release, which is planned within the end of the year.

---

<div class="post-metadata">

**Author:** ![graham.pronk-jones](https://avatars.discourse-cdn.com/v4/letter/g/dec6dc/32.png) [@graham.pronk-jones](https://forum.sierrawireless.com/u/graham.pronk-jones)\
**Post date:** [November 19, 2012, 8:30pm UTC](https://forum.sierrawireless.com/t/open-at-framework-2-51-serial-port-problems/5674/26 "2012-11-19T20:30:57Z")

</div>

Thanks daav – looking forward to trying the new DS!

The Q2687RD used UART1 (not the USB port) for downloading and debug, so I’ll have to live with it for now.

---

<div class="post-metadata">

**Author:** ![graham.pronk-jones](https://avatars.discourse-cdn.com/v4/letter/g/dec6dc/32.png) [@graham.pronk-jones](https://forum.sierrawireless.com/u/graham.pronk-jones)\
**Post date:** [January 16, 2013, 1:05am UTC](https://forum.sierrawireless.com/t/open-at-framework-2-51-serial-port-problems/5674/27 "2013-01-16T01:05:24Z")

</div>

Got a new board running (Q2687RD) with USB and the new DS and it’s running great. 😃

[Previous page](https://forum.sierrawireless.com/t/open-at-framework-2-51-serial-port-problems/5674.md?page=1)
