FTP list wip_read reset

Legacy Open AT
1

Hi All,

I’m getting an intermittent reset with my FTP read of the directory listing. It’s happening when I call the wip_read function.
I can get the list and download files usually without any problem, then on the odd FTP attempt, my application will reset during the wip_read. A common Trace when the reset occurs is “ARM Data Abort caught at XXXXXXXXX, Current Task 0x2F by ADEC”.

Just to note: I tried disabling the software and hardware watchdogs. I also tried increasing the stack size. Neither of these helped.

case WIP_CEV_READ:
{
s16 nread = 0;
u8 buffer[WIP_FTP_FILEINFO_SIZE];
wip_fileInfo_t * fi = wip_fileInfoInit(&buffer, sizeof(buffer), WIP_FOPT_NAME, WIP_FOPT_TYPE_ASCII, 20,
WIP_FOPT_SIZE, WIP_FOPT_TYPE_U32, WIP_FOPT_END);

            do
            {
                     nread = wip_read(Ev->channel, fi, sizeof(buffer));
                     ...

Device: SL6087
Firmware: 7.46

Anyone have an idea what the cause is?

Thanks in advance.

2

Hi,

Did you try with latest firmware?
Can you please try with the latest firmware R7.51 if the module resets or not.

Thanks.

3

Hi Rex_alex,

I’ve tried with the latest firmware and it hasn’t helped unfortunately.
I have also tried monitoring the power supply to see if there were any dips that correlated with the resets, but the power to the module seems stable.

Thanks

5

Hi Unitronic,

Thanks for the response. I’ll only get a chance to test this tomorrow and will post back my results.

Thanks

6

Unfortunately that hasn’t helped. Still getting the intermittent reset on the wip_read.

7

Hi All,

This is working now. I had assumed that it was in the wip_read because the last TRACE I was getting was always just before the wip_read, but the problem happened to be straight after the wip_read function when the directory listing was being compared.
I was comparing the filename to 8 characters to search for a match and I would increment the starting point of my comparison.
This meant that if the length of the filename (plus extension) was 9 characters, I would start my comparison with the first character and compare the first 8 characters of the filename. If I didn’t find a match, I would increment the start point and compare from the second character. The reset occured when I used the third character as the start point, because the last character compared would be outside the range of the filename.

This obviously wouldn’t happen everytime, because it would sometimes get a match before using the third character as a start point.