1 Known Issues for MCC Melody 8-Bit MDFU Client Library

M8BTL-4075

Issue Title:

DFU failure for K22 devices due to incorrect initialization of IOC functionality on Port B

Issue Description:

In the PIC18FxxK22 series of devices, the PIN_MANAGER_Initialize() initializes the Port B Interrupt-On-Change (IOCx) Interrupt Enable bit (RBIE). This causes an interrupt to occur but its not serviced anywhere in the firmware causing the device to re-enter the same ISR on repeat. This prevents further execution of the non ISR code.

Workaround:

Comment out the line that sets the RBIE bit in the PIN_MANAGER_Initialize() function.

M8BTL-4076

Issue Title:

MDFU I2C com_adapter experiences failures when the delay timing is set to a very large number

Issue Description:

The MDFU Client firmware can experience an issue if the inter-message delay value of the FTP is set to a value that is too large. This issue creates a failure message on the host but the update is still successful.

Workaround:

None.

M8PD-12645

Issue Title:

FLASH_PageErase function does not set the WR bit for the K22 variant and the page erase fails because of this.

Issue Description:

The current K22 NVM driver has a bug in it based on what the data sheet recommends for page erase operations. In the data sheet it says to set the WR bit but that action is never taken by the driver which makes it so that the NVM never actually performs an erase.

Workaround:

The WR bit can be manually set in the FLASH_PageErase function within the nvm.c file, immediately following the execution of the unlock sequence.

M8PD-11763

Issue Title:

Flash_RowWrite function does not restore context of TBLPTR

Issue Description:

The TBLPTR is not being restored after the Row Write, causing a crash when attempting to read from Flash later in the application.

Workaround:

The workaround is to manually update the FLASH_RowWrite function in nvm.c file to add the code to save and restore the TBLPTR context, as is done in some of the other NVM functions.

Example - PIC18F47K42

nvm_status_t FLASH_RowWrite(flash_address_t address, flash_data_t *dataBuffer){
//Save the table pointer
uint32_t tablePointer = (
    (uint32_t) TBLPTRU << 16) |
    ((uint32_t) TBLPTRH << 8) |
    ((uint32_t) TBLPTRL
    );

...
...
...
...
...
...

//Restore the table pointer at the end
TBLPTRU = (uint8_t) (tablePointer >> 16);
TBLPTRH = (uint8_t) (tablePointer >> 8);
TBLPTRL = (uint8_t) tablePointer; 
return rowWriteStatus;
} 

M8BTL-3919

Issue Title:

Some hardware platforms will require the use of Weak Pull-ups on the SDA line for I2C

Issue Description:

Depending on the hardware configuration, some devices will require the use of a pull-up on the SDA pin to operate most optimally. This issue was most clearly seen when using the High Pin Count Curiosity Board and a PDIP microcontroller platform.

Workaround:

Navigate to the Pins Tab in MCC and enable Weak Pull-ups for the SDA pin.

M8BTL-4067

Issue Title:

A few K-Series devices do not generate correct I2C register configurations causing the DFU operation to fail.

Issue Description:

There is a set of K series devices including the K22 and K80, that will generate their driver code with incorrect register initializations. There is no active workaround yet, but plans have been made to fix these issues at the driver level, so there are no plans to change the MDFU driver code as of now.

Workaround:

There is no active workaround to this issue as the register initializations could vary from implementation to implementation. Please look into your specific device data sheet for your required I2C register configurations.

M8BTL-3945

Issue Title:

The Read API in the PIC18F NVM driver can cause crashes during the verification due to the TBLPTR when interrupts are being used.

Issue Description:

The Flash_Read() function in the nvm.c file can create device crashes when the global interrupts are enabled. This causes an error where the bootloader can successfully load a new application, but it is unable to communicate that verification status back to the host. The bootloader is still able to verify the application and run the end application, but sending that status back to the host is not possible.

Workaround:

The workaround to resolve this issue us to simply disable the global interrupts while the TBLPTR is being used in the function:

static void CRC32_Calculate(flash_address_t startAddress, uint32_t length, uint32_t *crcSeed)
{
    uint32_t byteIndex;

    for (byteIndex = 0U; byteIndex < length; byteIndex++)
    {
        // Workaround Part 1: Disable the global interrupts
        INTERRUPT_GlobalInterruptHighDisable();
        // ------------------------------------

        uint8_t readByte = FLASH_Read((flash_address_t) (startAddress + byteIndex));
        
        // Workaround Part 2: Re-enable GIE once completed
        INTERRUPT_GlobalInterruptHighEnable();
        // ------------------------------------
        *crcSeed ^= (uint32_t) readByte;

        for (uint8_t bit = 8U; bit > 0U; --bit)
        {
            if ((*crcSeed & 0x01U) != 0U)
            {
                *crcSeed = (*crcSeed >> 1U) ^ CRC_POLYNOMIAL;
            }
            else
            {
                *crcSeed >>= 1U;
            }
        }
    }
    *crcSeed ^= CRC_XorOut;
}

M8BTL-3377

Issue Title:

Operating UART without a pull-up resistor on the RX pin may lead to unstable behavior

Issue Description:

There is unstable behavior with the UART peripheral when utilizing the pin re-entry mechanism at POR on a CNano Base Board for Click Boards (AC164162). We believe it is related to how the MCU and debugger are being powered when attached to a baseboard.

It was recently discovered that the root cause of this issue is related to the floating signal on the Rx pin. Utilizing a pull-up on an Rx line is suggested to prevent from the floating signal from triggering some condition on the UART peripheral.

Workaround:

The issue is avoided when a pull-up is configured on the Rx pin. Navigate to the Pins Tab, and enable the Pull-up option for the UART RX pin.

M8BTL-3325

Issue Title:

AVR DU/EB CNano Evaluation Boards fail to update with factory default settings

Issue Description:

The AVR DU and EB CNano devices have Device Configuration Protection enabled by default in the on-board debugger which prevents the correct BOOT fuse value from being programmed.

Note: This is not an issue with the library design or embedded code

Workaround:

To work around this:

1. Install Python 3.
2. Run the package installation command from a command line interface with access to Python:

   pip install pydebuggerconfig

3. First, run the read command to check the device's configuration. Check to see that the FUSE_PROTECTION bit in the TARGET_DEBUG_FEATURES register is set.

   pydebuggerconfig read

4. Next, disable the Fuse Configuration Protection by running:

   pydebuggerconfig replace -r TARGET_DEBUG_FEATURES=0x07

If that process yields no errors, then you have successfully disabled Fuse configuration protection in the on-board debugger.

pydebuggerconfig restore

If you do this please remember that this command will only restore the factory settings of the debugger and will not reset your device's Fuse values. If you have changed a Fuse then that value will be held until the debugger protection is disabled once again and you reprogram the device.