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

M8BTL-4245

Issue Title:

Flash_Read in verification can cause corruption of the application interrupt logic on the AVR devices with memory that exceeds 0x10000 bytes.

Issue Description:

There is an existing issue for AVR devices that have larger flash memories where the RAMPZ register is set during verification sequences and it is never cleared. This causes interrupts to not be serviced correctly by the ISRs of the application code.

Workaround:

flash_data_t FLASH_Read(flash_address_t address)
{
    // Workaround:
    // Store the read result
    flash_data_t result = pgm_read_byte_far(address);

    // Clear RAMPZ
    RAMPZ = 0;

    // Return the data byte
    return result;
}

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.

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.

M8PD-11070

Issue Title:

PIC18F-Q10 devices have an incorrect page size in the exported payload

Issue Description:

A page size of 128 (0x80) is exported by the NVM driver payload and to the MDFU Client for PIC18FxxQ10 devices which leads to an incorrect assignment to WRITE_BLOCK_SIZE in the bootloader_configuration.toml file. This in turn results in an update failure. Instead, the NVM driver needs to export 256 (0x100) as per the PIC18FxxQ10 datasheets.

Workaround:

To workaround this issue, assign the WRITE_BLOCK_SIZE in the bootloader_configuration.toml file with a value of 0x100. Once this value is changed, save the file and pass the updated configuration file as a parameter to the pyfwimagebuilder.

M8BTL-4664

Issue Title:

Reset function after END_TRANSFER needs longer delays for PIC devices

Issue Description:

During internal testing, it was identified that certain PIC devices using I2C may experience a bus lockup after the END transfer command due to a missing device-specific delay in the firmware. This issue does not affect UART or SPI interfaces. Users may observe that, although the application runs after an update, pymdfu reports a failure following the END transfer. To resolve this, a delay (approximately 14ms, depending on clock settings) should be added and tested to ensure reliable operation.

Workaround:

static void DeviceResetCheck(void)
{
    if (resetPending == true)
    {
#if defined(PIC_ARCH)
        __delay_ms(10U);
        RESET();
#elif defined(AVR_ARCH)
        _delay_ms(10U);
        ccp_write_io((void *) &RSTCTRL.SWRR, RESET_BIT_MASK);
#endif
    }
}