Can't configure UARTs in 7.4.0.a and above

I have been trying to port my app from Fastrack Supreme (with to the new Fastrack Xtend (7.4.0.a) and have experienced serious difficulties with configuring UART settings on both UARTs.

Basically I am trying to set UART2 to 9600, 8E1 and am getting 9600, 8N1 instead (the required Even parity parameter is not getting set). The same happens when I try to set UART1. Manually setting either UART from the command line seems to work OK.

I can reproduce the problem on my original Fastrack Supreme if I ‘upgrade’ it to 7.4.0.a. I’ve also tried upgrading to 7.43.0 but the problem persists. Restoring to fixes everything.

So its not the new modem, its something to do with 7.4.0.a (and above) or with the way I am using it.

I am using M2M 1.1.1 and have been especially careful to create a new project using apropriate settings each time, but to no avail.

I’ve tried delaying serial config a few seconds until after the modem has initialised, but this does not make any difference.

If it helps, I have managed to condense the problem down to its smallest form using the hello_world sample. But I don’t know how to include code samples on the forum - If I use the Code button and put a code snippet between the two markers and hit the preview button the page seems to seize up and after several seconds it just times out.

Are you using FCM, or “Direct” access?

Isn’t that the well-known, long-standing forum bug:

Note the “https”…

I’m using FCM

So you must be issuing AT commands to make the settings?

So you need to be sure that those AT commands are being correctly directed to the required port (UART2).

Has something changed about the way Open-AT directs commands to specific physical ports?
I seem to hear a faint bell ringing somewhere…

Apologies for presentation, but here are the three key lines, lifted directly from my modified hello world prog.

Interestingly if I change the order around (eg set the parity first) then its the baud rate that seems to get missed (stays at default). Its almost like the first AT command works OK, but the two subsequent ones aren’t handled correctly. Even though all three result codes are OK.


Code Snippet (u16 port = ADL_PORT_UARTx )

res1 = adl_atCmdCreate ( “AT+IPR=9600”, ADL_AT_PORT_TYPE ( port, FALSE ), ( adl_atRspHandler_t ) NULL, NULL );

res2 = adl_atCmdCreate ( “AT+ICF=2,1”, ADL_AT_PORT_TYPE ( port, FALSE ), ( adl_atRspHandler_t ) NULL, NULL );

res3 = adl_atCmdCreate ( “AT+IFC=0,0”, ADL_AT_PORT_TYPE ( port, FALSE ), ( adl_atRspHandler_t ) NULL, NULL );
wm_sprintf ( Str, “Res1,2,3 = %d,%d,%d\r\n”, res1, res2, res3 );
adl_atSendResponse ( ADL_AT_UNS, Str );

Note that the result code from adl_atCmdCreate merely indicate that the API call was OK - they do not indicate the outcome of the command!

To see the result of the command itself, you need to use the response handler…

Interesting. Now I did try adding response handlers but had trouble interpreting their results - am I looking for the OK/ERROR result ?

I know from documentation and examples how to get the result from a query command - add a null-terminated list of strings for the response to subscribe to (eg “+IPR” then NULL) and then to use wm_strGetParameterString to extract any returned values (eg parameter 1, the baud rate). But I’m not sure how to capture/interpret the OK/ERROR result from a configuration command.

Thanks I will have a look at that. I have seen the “*” thing before but haven’t used it, I’m always a bit uncomfy with undocumented stuff.

Meantime I have done some digging and discovered what I think might be some useful details. I’ve got rid of my FCM subscription and am now just using the IPR, ICF and IFC commands as above. This means that I can now go in with my Hyperterminal session and (with a bit of trial and error) easily deduce which of the three settings have taken and which have been ignored. The original hello world message is still in the sample and is broadcast on all open ports, and this provides a useful debug facility. With very interesting results.

It appears at first that only the first of the three commands is accepted. So if that first command is IPR=9600 then the baud rate will be set but the framing/flow control retain their default settings. If you swap things around and send ICF=2,1 as the first command, then the parity is set to even but the baud rate etc stays at 115200.

However, as soon as you enter any command on that port with hyperterminal, even just AT, all three settings take immediate effect. How amazing is that! Almost like the last two commands have been accepted but are stuck in a buffer/queue somewhere waiting for something to flush them out. Only the first one gets actioned properly.

I tried adding \r\n characters but that doesn’t work at all.

Adding a two second delay between the three commands makes no difference.

Ignoring the prog altogether and just typing in the config commands on either port works fine.

So Wavecom must make you really uncomforatble, then…?


Hmm… you code is sending all three commands effectively “simultaneously” - without waiting for the response to one command before sending the next.

I think that’s a really bad idea - you really need to wait for one command to complete (ie, give its terminal response) before sending the next.

I wouldn’t be surprised to find that’s something to do with not leting one command finish before starting the next… :question: