My DOTA works well if I am connected via RS232 serial cable to UART1. But when the RS232 serial cable is not present, and I have a USB cable connected, then the DOTA only proceeds up to the point where the Wavecom modem is supposed to reboot. But it does not start up again, no AT commands possible etc until I physically reset its power supply. After this it shows that the new firmware was installed correctly. But why does it not reboot as it should by itself?
“DOTA” = Downloadi Over The Air - so if you’ve got a cable, it’s not really DOTA, is it?! 8)
This actually sounds like everything is working as normal!
The problem, I suspect, is because you are using USB:
When the modem restarts, it also restarts its USB stack - this seems to confuse something between Windows and the modem, because it won’t work properly until you unplug & then reconnect the USB cable.
I think you will see the same effect if you send AT+CFUN=1 via the USB…
I don’t know if this is a specific Wavecom “feature”, or if any USB-connected modem would have the same issue…
Thanks for your reply. Actually when I only use the USB (or serial cable) to watch debug printf statements and to initiate the dota process. But I guess you realised that and were just joking. 
It actually looks like the Wavecom device is just completely dead until you reset its power. No matter how much you unplug the USB cable, close hyperterminal etc, there is just no activity at all. I will raise this issue directly Wavecom to see if they know about this behaviour. 
Upon further investigation I am now sure it is definetely related to debug info that the Wavecom info sends on UART1. If I turn off all debug info in my app and then do the DOTA with a serial cable disconnected, then the DOTA works as expected. If debug info turned on and serial cable connected, it also works. But if debug info turned on, and the serial cable not connected, then the Wavecom device hangs when it has to reboot.
Hope this info would be usefull to others as well.
Presumably, you have hardware flow control enabled?
With no cable connected, the hardware flow control prevents the UART from transmitting.
What “debug information” are you speaking of?
Presumably, you have hardware flow control enabled?
Yes
With no cable connected, the hardware flow control prevents the UART from transmitting.
I also presume it is something like that. It looks like the device buffers the data because if you connect it at some later stage it still spews out all the debug strings.
What “debug information” are you speaking of?
Well, we designed some debug routines that allows us to use printf statements all throughout our code with date/time that just keeps a running log of what it happening. We do have a single flag that can turn debug info on/off, but usually we just keep the debug info swithced on as it is very usefull to just plug in a laptop and monitor what is happening. But now this DOTA thing is stuffing me around a bit.
I already tried to close UART1 with a “at+wmfm=0,0,1” command just before activating the DOTA, but this does not help. Any ideas what else to try?
If you’re using FCM to send the stuff, are you checking for when the Flow gets out of “credit”… 
WTF 
Pardon? 
Sorry… did not mean to be rude. Just meant I did not quite understand your suggestion. 
no problem.
Do you use the Flow Control Manager (FCM) to send your diagnostics?
If you do, the adl_fcmSendData return code indicates if the output could not be sent; eg, becuase of hardware flow control:
ADL_FCM_RET_OK_WAIT_RESUME - the data was accepted (queued) for transmission, but the Flow is now out of “Credit”; ie, it will not be able queue any more until some “Credit” has been released;
After receiving this result, you should not attempt another adl_fcmSendData call until after your Control Event handler has received an ADL_FCM_EVENT_MEM_RELEASE event.
If you do call adl_fcmSendData again before receiving ADL_FCM_EVENT_MEM_RELEASE, the result will be ADL_FCM_RET_ERR_WAIT_RESUME - the data was not accepted (queued) for transmission; eg, due to all “Credit” having been used-up because hardware flow control prevents transmission.
So you should be able to use these to detect the situation, and prevent the lockup…
BTW: “Credit” is a mysterious Wavecom term that is not well explained in the documents… 
Ok, I received official confirmation now that this happens if there are some data buffered inthe V24 buffers. In this case, the adl_adInstall () will not perform the reset of the Wireless CPU and the control of execution is not returned to the application.
This can happen also as a result of unsolicited responses, so even if you do not have debug printf statement in your code as I do, it can still happen. I tried several things so far and none resolved the issue.
I’m a little bit puzzled why the adl_install () command have to behave this way when there is data buffered in the UART1 buffer.
That’s more than a little puzzling - that’s absolutely shocking!! 
Where is this documented?
This casts a huge doubt on whether the whole DOTA thing is at all suitable for remotely-located units!
Surely it cannot be acceptable to have this possibility that the install may lock-out the application with no way for the application to detect, prevent, or recover from this situation!!
This could explain a problem reported on one of my units recently which failed to restart after a download…
Just in case anyone is interested. It turns out there are several work-arounds to overcome this problem if the DOTA freezes because of data on the buffer of UART1. I implemented Option 3, which works fine for me:
Option 1. Design your hardware to pull the CTS line so the Wavecom processor things there is a serial cable connected.
Option 2: When the code is ready to apply the DOTA file, issue a “at+wrst” to be executed two minutes later. Issue the adl_install() command. The idea is that ff the adl_install does not reset the Wavecom modem, the the at+wrst will do so anyway two minutes later
Option 3: When the DOTA file is finished downloading, just set a non-volatile flag and reboot the WMP with a normal at+cfun=1 command. When it starts up it first checks the flag. If set, it disables all debug info and unsollicted responses to UART1. It then clears the flag and executes the adl_install() which works now because there is nothing on serial port.
Is there a 4th option:
4. Make a call to adl_fcmReleaseCredits to release all “credits”
Cross reference: viewtopic.php?f=4&t=994&p=10263#p10263
I wonder how many other DOTA problems posted on this forum can also be traced to this adl_adInstall stupidity…?
I’ve successfully used DOTA for many applications. However, once I had a specific application that could not DOTA when another version of the same app was loaded. For example, I had three versions of an application (only small differences between the three) 1.0, 2.0 and 3.0.
1.0 is loaded and successfully updates via DOTA to 2.0
1.0 is loaded and successfully updates via DOTA to 3.0
Likewise 2.0 can successfully update via DOTA to both 1.0 and 3.0
3.0 is loaded and can successfully update via DOTA to 1.0 but NOT 2.0.
(DWLWin could do it successfully, as could AT+WDWL)
A small insignificant change in the app (creating a different dwl file) solved this problem.
The moral of this story is before performing a DOTA, always test the DOTAbility between the existing app and the new app.
Note that this AT+WRST command would cause the unit to reboot every 2 minutes - so you would need to take steps to cancel that after the app had successfully started!