PIC32MZ EF SQI issue with odd size buffer

[lucapascarella]

I isolated an unexpected behavior in the SQI driver when used with PIC32MZ EF, SST26, and RTOS.

Two consecutive reads at the same address return correct results only when buffers have even size. When the buffer length is an odd number the last byte of the first call appears as the first byte of the second call. In other words, everything is shifted to the right. As if something in the first call is pending even though the request returns all bytes.

Although the problem appears with MPFS in #5, the following snippet isolates and reproduces the problem when nBytes is an odd number.

` uint16_t j; for (j = 0; j < 2; j++) { // Test MPFS uint16_t diskNum = 0; uint32_t address = 0x00000001; uint32_t nBytes = 3; uint8_t *source; SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE commandHandle = SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE_INVALID; SYS_FS_MEDIA_COMMAND_STATUS commandStatus = SYS_FS_MEDIA_COMMAND_UNKNOWN;

source = ((uint8_t *) address);
commandHandle = SYS_FS_MEDIA_MANAGER_Read(diskNum, buffer, source, nBytes);

if (commandHandle != SYS_FS_MEDIA_BLOCK_COMMAND_HANDLE_INVALID) {
    commandStatus = SYS_FS_MEDIA_MANAGER_CommandStatusGet(diskNum, commandHandle);
    while ((commandStatus == SYS_FS_MEDIA_COMMAND_IN_PROGRESS) || (commandStatus == SYS_FS_MEDIA_COMMAND_QUEUED)) {
        SYS_FS_MEDIA_MANAGER_TransferTask(diskNum);
        commandStatus = SYS_FS_MEDIA_MANAGER_CommandStatusGet(diskNum, commandHandle);
    }
    printBytes(buffer, nBytes);
}

} `

Unfortunately, I couldn't find yet a workaround.

[amitraddi]

@lucapascarella Thanks for reporting the issue. Will be fixed in next release

[dsettu]

@lucapascarella , This issue is fixed now. Please check it out and close. thank you.