Periodic write operations on UART2 problem


#1

Hi,

I’m using the adl API (adl_OpenDevice/read/write direct access) to communicate with an external device through the device UART2.

The external device periodically sends data (read operation) and the wavecom modem sends an acknowledge (write operation).
If the external device doesn’t get the acknowledge from the wavecom, it will retry 5 times and stop if no more acknowledge are received.

I notice that sometimes (2 or 3 times per day) the external device stops to send data because the wavecom doesn’t sends answer.
When the problem occurs, It seems that the write operation doesn’t really sends data…

I’ve read the firmware R73a correction:
“CUS52838
When write operations are triggered periodically the OnTxComplete event handler is sometimes not recalled. Consequently the pending write operation never ends.”

Where can I find more information about that ?
Does somebody have the same problem ?

Thanks


#2

If it’s a bug in the open device direct access, can you use FCM instead?


#3

In the 73a realease note, we can read that the bug was corrected… but seems not… Do you no if such a bug is known ?

Unfortunately I can not use FCM because the connected device has a “special” behavior.

By default, it works with full uart signal so I can not use uart2 (and uart1 is already used).
But as long as the device received a 1 level trough the CTS signal, it works with the TX/RX simple uart (in this case we can use uart2).

As we can not control signal level with the FCM, I need to use the device direct access (to send 1 to CTS and then be able to configure the device in TX/RX uart). And it works fine until some write operations seem to not been sent…

Do you think it is “dangerous” to use device direct access instead of FCM ?

Sorry for my english. Hope you understand what I mean.

Thanks


#4

Is the FCM based on the open device direct access API ?


#5

I doubt it.

The FCM has been around for a very long time - long before the Open Device stuff was even mentioned.

So it’s just a kind of hunch that FCM is liable to be more “stable” than any new-fangled API - as this bug would seem to suggest…

There is an old saying in software circles that you should never use v1.0 of anything… :wink:


#6

:slight_smile: you’re completly right…

Well, I will send this problem to my distributor and will try to use FCM instead…

Thank you Awneil !