Page Comparison

...

1. CWM Buffering

2. OKE Inbound File Transfer Throttling

3. Aborting an OKE Inbound File Transfer

4. Transferring Large Files

5. Faster Baud Rate Negotiation

6. Fastest Interface

7. File Transfer Throughput

8. File Transfer Status

9. File Status

10. Firmware

11. Writing from the OKC to an OKE System

12. Throttling File Fragments

13. Pseudocode Example

14. Common Problems

15. Debug Log Output

The CWL allows OKE systems to read and write files containing arbitrary data via the file transfer interface. Individual file transfers of up to 2^31-1 bytes (2GB) in size are allowed. The primary use of file transfer is for firmware updates since it is highly likely that all OKE controllers will support in-system updates. Other possible uses for file transfer include sending recipes to equipment, or for equipment to offload diagnostic logs to the OKC.

...

Bool CWPortGetInboundFileWriteBuf (uint8_t** buf, uint16_t *bufSize)
{
    static uint8_t ftBuf[CWMSGCMD_FT_MAX_SIZE];
    CW_REQUIRE(buf != NULL);
    CW_REQUIRE(bufSize != NULL);
    *buf = ftBuf;
    *bufSize = sizeof(ftBuf);
    CW_ENSURE(*buf != NULL);
    CW_ENSURE(*bufSize >= CWMSGCMD_FT_MAX_SIZE);
    return true;
}

bool CWPortExeFileWrite (int8_t* fileStr, uint32_t offset, uint8_t* data, uint16_t dataLen)
{
    CW_REQUIRE(fileStr != NULL);
    CW_REQUIRE(data != NULL);
    CW_REQUIRE(dataLen <= CWMSGCMD_FT_MAX_SIZE);
    if (offset == 0)
    {
        if (fpWrite != NULL) fclose(fpWrite); /* Close open files */
        CW_ASSERT((fpWrite = _fsopen(fileStr, "wb+", _SH_DENYNO)) != NULL);
    }

    CW_ASSERT(fwrite(data, 1, dataLen, fpWrite) == dataLen);
    if ((dataLen < CWMSGCMD_FT_MAX_SIZE) && (fpWrite != NULL))
    { fclose(fpWrite);}
    return true;
}

Anchor
common_problems common_problems

Common Problems

1. OKE implementation expects a hardcoded file name and file uploaded to OKC doesn’t match:
   It’s commonly seen that developers hard code an expected file name for certain file types, e.g. firmware.bin, menu.json. If someone subsequently uploads a file to the OKC with a different name (e.g. firmwareV1-2-3.bin), the file will be downloaded to the OKE (and indeed the status shown in Open Kitchen will be ‘downloaded’), but it isn’t loaded into the system because of the name mismatch. We recommend avoiding this approach and to instead encode identifiable information in the file header. If not avoidable, then ensure the file uploaded to the OKC is correctly named

2. Old CWM firmware and/or CWL version: In CWM1 firmware earlier than PIC154/SPH145 and ConnectWare Library versions < 1.0.15, there was a bug in the fragmentation layer that caused messages of certain lengths to be dropped. This can cause a multitude of issues including download rewinds due to dropped fragments (ultimately ended in an aborted download), and files that do ‘successfully' download to the CWM but aren’t loaded into the OKE. If you encounter such issues, please ensure your CWM firmware and CWL versions are up to date.

3. File name + extension longer than 16 characters: the OKC now prevents this from happening, but it may still be possible to do with the simulators. The CWL has a 16 character limit on the file name including the extension. If this limit is exceeded, the CWM will download the fragments from the OKC but just throw them away. Please ensure file names are <= 16 characters including extension.

4. File Name + Version + Account ID not unique combination: Currently, there is a unique index in Open Kitchen Database that requires a combination of File Name - Version - Account ID to be unique even the uploaded file has been deleted. If Version does not have value entered by user, it will have timestamp value. However, user can enter Version for it to be used to match with equipment data for file transfer status. If this is the case, it may cause violation of unique File Name + Version + Account ID combo key. In this scenario, if a firmware file needs to be uploaded from the same Account, it needs to have unique File Name and Version (if input by user) every time it is uploaded even after it is deleted from Open Kitchen.

Anchor
debug_log debug_log

Debugging Log Output

1. The file contents are transferred 512 bytes at a time from the CWM to the OKE, each 512 bytes is considered a fragment. Each one of the “Received… fragment” lines in the log output is showing that the fragment was received where offset is the absolute location of that fragment within the file being transferred. As you can see the offset advances 512 bytes between each log output.

2. Frame errors are usually indicative of hardware signaling problems, not usually software problems. This would more commonly occur at baud rates above 115200. Causes could be poor cabling, poor grounding, or exceeding the maximum bit rate specification of an RS232 transceiver (either side). Some transceivers rated for a maximum of 115200 can sort of work at higher baud rates, but can glitch out and cause frame errors, etc.

3. The serial protocol between the CWM and OKE has a robust ability to detect and recover from temporary errors on the serial communication bus. If you look at the log output and see “Received Fragment” messages after a burst of Frame Error messages, this means the next fragment in the sequence was successfully delivered despite the frame error burst.