SFSA "read", is there a length limitation I'm missing? | Thales IoT Developer Community
June 8, 2016 - 12:46pm, 3228 views
I wonder what I'm doing wrong here. I have a file on EHS6 FFS (~20k of CSV of increasing values, never mind the name ".jpg") , which I try to read. Reading up to 512 bytes at a time seems to work, but for example 768 seems to be too much; the output gets garbled after that, and stays like that (for all command replies, not only read related) until I reset the modem.
Below is a capture showing this. After module startup, the open and read(512) commands work fine, as does an ATI. After that I tried reading 768 bytes (but only received 512 + garbage) and issued a new ATI command. After that, read 256 bytes and 512 bytes, only received a few bytes (but reading of the file is clearly progressing). My commands are bolded in the capture.
After reset, I can read the whole file just fine if doing it in pieces of 512, but if trying bigger ones, only way to get EHS6 back to normal is resetting the device.
I'm using 9600bps, no hardware flow control.
^SYSLOADING
^SYSSTART
+PBREADY
AT^SFSA="open",a:/data/flower.jpg,0
^SFSA: 0,0
OK
AT^SFSA="read",0,512
^SFSA: 512,0
0;1;2;3;4;5;6;7;8;9
10;11;12;13;14;15;16;17;18;19
20;21;22;23;24;25;26;27;28;29
30;31;32;33;34;35;36;37;38;39
40;41;42;43;44;45;46;47;48;49
50;51;52;53;54;55;56;57;58;59
60;61;62;63;64;65;66;67;68;69
70;71;72;73;74;75;76;77;78;79
80;81;82;83;84;85;86;87;88;89
90;91;92;93;94;95;96;97;98;99
100;101;102;103;104;105;106;107;108;109
110;111;112;113;114;115;116;117;118;119
120;121;122;123;124;125;126;127;128;129
130;131;132;133;134;135;136;137;138;139
140;141;142;143;144;145;146;147;148;149
150;151
OK
ati
Cinterion
EHS6
REVISION 02.000
OK
AT^SFSA="read",0,768
^SFSA: 768,0
;152;153;154;155;156;157;158;159
160;161;162;163;164;165;166;167;168;169
170;171;172;173;174;175;176;177;178;179
180;181;182;183;184;185;186;187;188;189
190;191;192;193;194;195;196;197;198;199
200;201;202;203;204;205;206;207;208;209
210;211;212;213;214;215;216;217;218;219
220;221;222;223;224;225;226;227;228;229
230;231;232;233;234;235;236;237;238;239
240;241;242;243;244;245;246;247;248;249
250;251;252;253;254;255;256;257;258;259
260;261;262;263;264;265;266;267;268;269
270;271;272;273;274;275;276
OK
rionead",0,768
EHS6
REVISION 02.000
OK
ati
Ci
OK
A="read",0Cinterion
EHS6
RAT^SFS
^SFSA: 256,0
;152;39
340;341;342;
OK
rionead",0,256
EHS6
REVISION 02.000
OK
AT^SFS
^SFSA: 512,0
39
31;402;403;404;40
OK
rionead",0,512
EHS6
REVISION 02.000
OK
Hello,
This looks very strange. Maybe it's connected with no flow control. Or the terminal.
Please paste the ATI1 and AT^SCFG? replies.
Are you using serial interface or usb?
I tried with my EHS6 revision 3 module and was unable to reproduce it.
I don't know at the moment about any problem connected with SFSA in revision 2 but if nothing will help you could try to update to some newer FW version.
Regards,
Bartłomiej
Below are the replies.
I'm using a simple serial interface (just TX/RX) between the module and a host processor (embedded application). I'm taking the capture by just simply probing the RX line (from host processor's point of view, i.e. what module transmits) and directing that to PC.
---
Cinterion
EHS6
REVISION 02.000
A-REVISION 00.000.03
OK
^SCFG: "Call/ECC","0"
^SCFG: "GPRS/AutoAttach","enabled"
^SCFG: "Gpio/****/ASC1","rsv"
^SCFG: "Gpio/****/DAI","gpio"
^SCFG: "Gpio/****/DCD0","std"
^SCFG: "Gpio/****/DSR0","std"
^SCFG: "Gpio/****/DTR0","std"
^SCFG: "Gpio/****/FSR","gpio"
^SCFG: "Gpio/****/HSIC","std"
^SCFG: "Gpio/****/PULSE","gpio"
^SCFG: "Gpio/****/PWM","gpio"
^SCFG: "Gpio/****/RING0","std"
^SCFG: "Gpio/****/SPI","rsv"
^SCFG: "Gpio/****/SYNC","gpio"
^SCFG: "Ident/Manufacturer","Cinterion"
^SCFG: "Ident/Product","EHS6"
^SCFG: "MEShutdown/Fso","0"
^SCFG: "MEopMode/SoR","off"
^SCFG: "Radio/Band","511"
^SCFG: "Radio/OutputPowerReduction","4"
^SCFG: "Serial/Interface/Allocation","0","0"
^SCFG: "Serial/USB/DDD","0","0","0409","1E2D","0058","Cinterion Wireless Modules","EHx",""
^SCFG: "Tcp/IRT","3"
^SCFG: "Tcp/MR","10"
^SCFG: "Tcp/OT","6000"
^SCFG: "Tcp/WithURCs","on"
^SCFG: "Trace/Syslog/Otap","0"
^SCFG: "URC/Ringline","local"
^SCFG: "URC/Ringline/ActiveTime","2"
^SCFG: "Userware/Autostart","1"
^SCFG: "Userware/Autostart/Delay","0"
^SCFG: "Userware/DebugInterface","0.0.0.0","0.0.0.0","0"
^SCFG: "Userware/DebugMode","off"
^SCFG: "Userware/Passwd",
^SCFG: "Userware/Stdout","null",,,,"off"
^SCFG: "Userware/Watchdog","0"
OK
Hello,
So there are 3 devices that could be responsible for the problem. I think that the most probable cause of this is the lack of flow control. Maybe some buffer is overwritten.
From the module's perspective - according to the documentation for revision 2 the using of flow control on ASC0 and ASC1 is recommended (please see more in the AT commands specification - AT\Q command), it is possible not to use flow control but there is a risk of data loss and no power saving should be used (AT^SPOW). In the revision 3 it has been changed and there is additional setting for AT\Q (disable flow control). But still using the HW flow control is recommended.
Maybe it would be a good idea to test the module with the PC directly to verify if the additional controller is not the cause of the problem.
As I understand you are not using the terminal (EHS6T) - if you would there could be more issues because of additional hardware.
According to the firmware version that you are using it is also not the latest.
Regards,
Bartłomiej
I could understand some missing or ******* data caused by lack of flow control, but that still doesn't explain why all AT correspondence with the module gets messed up after issuing one too long read.
I get the exact same results (garbled output after reading too big a chunk) using the Concept Board (putty terminal connected to ASC0), except that the scfg answers differ a bit.
From Concept board:
ati1
Cinterion
EHS6
REVISION 02.000
A-REVISION 00.000.03
OK
at^scfg?
^SCFG: "Call/ECC","0"
^SCFG: "GPRS/AutoAttach","enabled"
^SCFG: "Gpio/****/ASC1","std"
^SCFG: "Gpio/****/DAI","gpio"
^SCFG: "Gpio/****/DCD0","std"
^SCFG: "Gpio/****/DSR0","std"
^SCFG: "Gpio/****/DTR0","std"
^SCFG: "Gpio/****/FSR","gpio"
^SCFG: "Gpio/****/HSIC","rsv"
^SCFG: "Gpio/****/PULSE","gpio"
^SCFG: "Gpio/****/PWM","gpio"
^SCFG: "Gpio/****/RING0","std"
^SCFG: "Gpio/****/SPI","rsv"
^SCFG: "Gpio/****/SYNC","gpio"
^SCFG: "Ident/Manufacturer","Cinterion"
^SCFG: "Ident/Product","EHS6"
^SCFG: "MEShutdown/Fso","0"
^SCFG: "MEopMode/SoR","off"
^SCFG: "Radio/Band","511"
^SCFG: "Radio/OutputPowerReduction","4"
^SCFG: "Serial/Interface/Allocation","1","1"
^SCFG: "Serial/USB/DDD","0","0","0409","1E2D","0058","Cinterion Wireless Modules","EHx",""
^SCFG: "Tcp/IRT","3"
^SCFG: "Tcp/MR","10"
^SCFG: "Tcp/OT","6000"
^SCFG: "Tcp/WithURCs","on"
^SCFG: "Trace/Syslog/Otap","0"
^SCFG: "URC/Ringline","local"
^SCFG: "URC/Ringline/ActiveTime","2"
^SCFG: "Userware/Autostart","1"
^SCFG: "Userware/Autostart/Delay","0"
^SCFG: "Userware/DebugInterface","0.0.0.0","0.0.0.0","0"
^SCFG: "Userware/DebugMode","on"
^SCFG: "Userware/Passwd",
^SCFG: "Userware/Stdout","null",,,,"off"
^SCFG: "Userware/Watchdog","0"
OK
Hello,
As you are using a really old firmware revision and I have not found this behaviour on my module even without flow control I suggest updating to at least latest version of revision 2 or even revision 3. I'll send you the firmware.
Regards,
Bartłomiej
I guess the key is the bps rate I was using. Still on the old firmware, if I switch to 115200, I'm able to read to up to 1500 bytes (as reported by AT^SFSA=?) at once. If I go back to 9600, I get back the erractic behaviour. Can you try with 9600 and see if you can reproduce with newer FW?
Since I can't read more than 1500 bytes at a time in any case, it really doesn't matter much what the chunk size actually is, I need to read my file in parts no matter what... so I'll leave these trials for now, I can live with these results in my application.
Cheers,
Pasi
Hello,
I'm still not able to reproduce this with any baudrate.
Regards,
Bartłomiej
OK, that's weird, as the speed definitely makes an impact for me. Thanks for trying.