antfs.c sample code bug during interrupted download

[rschmitz]

I am getting unexpected behavior when using the latest version of the antfs.c sample code.  I think this is a separate issue from what I reported here

When the ANT-FS download is interrupted momentarily during a download, I expect it to recover from the point where it left off.  However, it throws up a "Download Rejected" error that stops the download.

I'm using the ANT_s212_nrf52810_nrf52832_6.1.1 soft device (I said the version number incorrectly in the video).  I'm using the nRF5_SDK_16.0.0_98a08e2 SDK.

This video shows how the bug manifests itself.  This can be replicated using the ant-fs client sample code on an nRF52832 Dev Kit and running the ANT-FS PC hosts to download the data.  I induce an interruption in the download by holding my finger over the antenna on the dev kit momentarily.

https://youtu.be/dN0q408iVq4

The bug appears to be in this section of the code in antfs.c

                else
                {
                    // This is a request to resume a partially completed transfer.

                    if (m_saved_crc_offset > m_link_burst_index.data)
                    {
                        // We can not check the received CRC seed as the requested offset is before
                        // our last save point.

                        // Set CRC checking as invalid.
                        m_saved_crc_offset = ANTFS_MAX_FILE_SIZE;//This line seems to be incorrect
                    }
                    else
                    {
                        m_current_state.sub_state.trans_sub_state = ANTFS_TRANS_SUBSTATE_VERIFY_CRC;
                    }
                }

The line that I commented as seeming to be incorrect is the one that forces the "Download Rejected" error to show up in the ANT-FS PC host via the following code in antfs.c on the client.

        if (m_saved_crc_offset == ANTFS_MAX_FILE_SIZE)
        {
            // CRC checking was set as invalid. An invalid download was requested, so reject it.
            response = RESPONSE_INVALID_OPERATION;
        }
    }

    if ((response != 0) || (m_file_size.data == 0))
    {
        // Send the response right away if the download request was rejected or there is no data to
        // send.
        download_request_response_transmit(response);
    }
    else

If I comment out the line that I marked as incorrect, then the download starts over when the ANT-FS signal is momentarily interrupted.  This is better than stopping the download with an error, but not as good as continuing where it left off.

I have not been able to determine what the correct code should to get the download to continue from where it left off.

[Kenneth]

I have forwarded your case to the software developers. We will try to provide an update soon.

Kenneth

[rschmitz]

Hello Kenneth,  Is there any update on this bug?  It is holding up our software release now.  Thanks!

[Kenneth]

Hi,

Sorry for time this is taking, they are looking into it.

Best regards,
Kenneth

[Kenneth]

Looks like the person looking into the case is out of office this week. So likely no update until then, sorry for the delay.

Best regards,
Kenneth

[Kenneth]

Hello,

The team have found out why ANT FS Client failed to resume the file downloading process after temporary interruption.

It turns out that the CRC save point is updated systematically with every data packet that is sent from the Client to the Host during the file transfer. ANT protocol cannot detect disconnect straight away, so it keeps on sending data packets and updating CRC save points. Later on, if the ANT PC tool recognizes interrupted transmission, it tries resuming the downloading process by setting a dedicated bit in the download command. It also indicates the file offset from which the file transfer should continue. However, the offset of the CRC save point, which was calculated by the ANT FS Client, is greater than the file offset requested by the Host. The Client rejects the whole downloading operation because it cannot verify the CRC of data packets that were received on the Host end. One of the possible solutions to this issue is to store multiple CRC save points during the downloading process and roll back to the closest one when the file transfer is interrupted. Currently, there is only one CRC save point, and that's why this becomes a problem.

The team have included a modified version of antfs.c which handles the temporary transfer interrupts. However, this version skips the CRC verification step after the transmission is interrupted. As a test, they tried downloading the same file two times: once without any transfer interruptions and the second with at least one such interrupt. It turned out that both versions of the file were binary equal. This experiment demonstrates that the file transfer with resuming functionality is feasible. 

We hope that the modifications is a good starting point to improve ANT FS implementation further. Unfortunately the team don't have time to see this further as of now.

Best regards,
Kenneth

7587.antfs.c