6 Assumptions of Use

AoU-1. When configuring interrupts in the client code for PIC18F devices that do not support the Interrupt Vector Table, it is assumed that the low priority interrupt vector will not be used.

Description: We assume that, by default, the user will not compile any ISR into the low priority interrupt vector. Instead, we provide a placeholder function to prevent conflicts between the high priority and low priority vector addresses. If you wish to use the low priority vector in your client project, you must remove this placeholder function. To locate this placeholder function, navigate to mcc_generated_files/bootloader/library/core/bl_interrupt.c; it is located at the bottom of the file.

AoU-2. When configuring the client code for I2C communication, it is assumed that the I2C driver will be interrupt-driven.

Description: The client firmware can operate with a polled I2C driver, but specific actions are required to prevent the device from clock stretching beyond the duration recommended by the MDFU protocol. To avoid excessive clock stretching during memory operations in polled mode, the 8-Bit MDFU Client code disables the I2C peripheral before processing any command. This action causes the device to automatically NACK its own address, thereby preventing clock stretching beyond the acceptable limit. This is not the most optimal behavior, which is why we recommend using interrupts for I2C when possible.

AoU-3. When configuring the LED indicator, it is assumed that the LED will be initialized in the OFF state and that the 8-Bit MDFU Client code will control the LED by toggling from its initial state.

Description: The LED pin is configured to start in a high state by default, with the assumption that LED pins are active low. This ensures the LED begins in the OFF state when the 8-Bit MDFU Client starts. The client indicates its status by changing the pin state from this initial high condition, effectively turning the LED ON during bootloader operations. If you are using an active high LED or have toggled the "Inverted I/O" setting in your configuration, you must manually adjust the initial pin state in your code to ensure the LED starts in the OFF condition. Failure to properly initialize the LED state may result in inverted or unexpected LED behavior during bootloader operation.

AoU-4. When configuring I2C communication, it is assumed that the internal weak pull-ups on the SDA line are not required for stable operation.

Description:By default, the I2C configuration does not enable internal weak pull-ups on the SDA line, as most PIC devices operate reliably without them. However, certain devices (such as some PIC18F devices) may experience I2C stability issues including excessive communication retries and bus lockups without these internal weak pull-ups enabled. This requirement is hardware-specific and varies between device families - some devices require the additional internal pull-up support while others operate reliably with the default configuration. If you encounter I2C communication instability during bootloader operation, enable the weak pull-up on the SDA pin in your pin configuration settings to improve signal integrity and prevent bus lockups.