I’ve done is several times. No problems.
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?
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.
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 18.104.22.168206182209-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!
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.
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.
Got a new board running (Q2687RD) with USB and the new DS and it’s running great.