SPWF04 File print Not Responding

brianshankland9 · ‎2018-03-28

Posted on March 28, 2018 at 17:00

I have been able to use the File Print (AT+S.FSP) in some test situations, but now that I'm using it for real I'm not getting any results.

When I was performing my feasibility tests I was printing sections from within a small text file located in the Application volume.

When i try to do a similar task with a large text or binary file that is on the User Volume the command just hangs with no reply.

I can see from the FSL command that the file is present with the 'E' prefix indicating user volume.

Interestingly the AT+S.FSP command when echoed back is not terminated with 0x0D 0x0A as I would have expected (from seeing other command replied) but with 0x0D 0x00

The binary file is 173Kb in size and the text file was 486Kb in case there is a file limit issue with the command.

The command content I was sending was AT+S.FSP=/firmware.hex,0,256

It does not matter if I try to list the entire file using

AT+S.FSP=/firmware.hex,, as this also fails in the same manner.

So is there a known issue with either file size, or using the user flash space with the FSP command?

brianshankland9 · ‎2018-04-03

Posted on April 03, 2018 at 10:22

Unfortunately not, this is not a dev board but a production model prototype. What I can do is single step through the code to add significant delays between commands if there is a belief that the FSL command needs a delay afterward before the next command is received.

I was under the belief that it was of LF character that was unexpected since the stack app note talks about <VR> in all of its examples, but as I often see <CR><LF> when manuals say just <CR> I didn't think anything of it.

I don't think the <LF> is being added by the UART library as I have had a working TCP socket for many weeks now and have not seen any data corruption which would be expected if this was the case. I can check my binary image print to see if I have a <CR> without a <LF> following in which case it is definitely not the UART adding it.