1.15 Common Issues

IOL1WAY Configuration Bit.
To prevent accidental changes to the PPS (Peripheral Pin Select) configuration on the device, the IOL1WAY configuration bit can be set. PPS itself is a way to map certain peripheral features to designated device pins. However, setting the IOL1WAY Configuration Bit will cause the PPS configuration to only be written once. The problem with this in the bootloader is that if we set this configuration bit and program the PPS in the bootloader, the application code will not be able to change the PPS settings. This will prevent the application code from changing the configuration, such as configuring the UART to use specific pins. The resulting failure is that no data will be placed on these pins. This can be difficult to debug because the configuration will appear to be correct, but still not function. To help the user notice this issue, MCC checks for this bit and notifies the user if it's set. However, locking the PPS to prevent changes is an important safety feature. So if the user still wants to do this, there are several options available.

  1. Make sure the bootloader and application have exactly the same PPS configuration and allow the bootloader to configure the PPS.

  2. Enable IOL1WAY in the bootloader, and in the file pin_manager.c, remove the line of code that locks the PPS. This will leave the PPS unlocked in the bootloader code. Then, in the application code, in the pin_manager.c file, allow the PPS to be locked.

Peripheral will not function when using the bootloader.

If the peripheral works when not using the bootloader but fails when using the bootloader, one possible cause is that the bootloader is setting the IOL1WAY bit. This will not allow any modification to the PPS after it's set, which means the application code cannot change the settings. The only solution is to not allow the bootloader to set this bit.  

Bootloader project generates link errors
If the bootloader fails, there are a few possible things to check as possible sources of the issue.
  • If using ECDSA verification, make sure that the "Isolate each function in a section" and "Remove unused sections" are both checked in the compiler settings.

    1. Right click on the project and select the project properties

    2. Select the compiler node - typically "XC16"

    3. Check the boxes next to the "Isolate each function in a section" and "Remove unused sections" boxes

    4. Click the "Apply" button and try building again

  • If using ECDSA verification, make sure that the "Generate Example" and "Print debug statements in library" are both un-checked in the Crypto Authentication Library MCC settings.

    1. Open MCC for the Bootloader project

    2. Select the Crypto Authentication Library module in the Device Resources pane

    3. Un-check the "Generate Example" and "Print debug statements in library" boxes

    4. Click the MCC "Generate" button

    5. Try building the project again

  • If using ECDSA verification on a device with CodeGuard/Bootloader protection enabled, make sure that the required compiler/linker options are set.

    1. Go to Project Properties

    2. Go to XC16->xc16-ld

    3. Under additional options add the following: -add-flags-const=boot,-D__USE_BFA

  • If other modules were added to the bootloader project, then more space must be allocated to the boot loader project of the total system memory.

    1. Open the bootloader's MCC project in MPLAB X

    2. Open the Bootloader:Bootloader module

    3. Increase the value for the Bootloader end address field

    4. Click the MCC "Generate" button

    5. Try building the project again

Verification fails

If the bootloader verification function returns false (the verification failed), then check the following:

  • Make sure the post build script is attached to the application project. This is the script that calculates the verification value (checksum, CRC, etc.) and injects it back into the .hex file.

    1. Open the application project

    2. Right click on the project properties.

    3. Select the "Building" node from the Categories tree pane on the left of the window.

    4. Check the "Execute this line after build" box.

    5. Add the following line to the box below the checkbox:

      • add "cd mcc_generated_files/boot && postBuild.bat $(MP_CC_DIR) $(ProjectDir) $(ImageDir) $(ImageName)" (without quotes) if you are on a Windows machine

      • add "cd mcc_generated_files/boot && ./postBuild.sh $(MP_CC_DIR) $(ProjectDir) $(ImageDir) $(ImageName)" (without quotes) if you are on a Linux/Unix/Mac machine.

If version numbers are being used and checked in the bootloader, and the bootloader does not load the new application, then check the following:

Bootloader will not load or Verification fails
SYSTEM_Initialize never returns in bootloader when using ECDSA verification
If the bootloader verification function returns back a false (verification failed), then check the following:

  • Make sure an ATECC608 (or other supported crypto chip) is attached to the board appropriately so it connects with the communication lines selected in MCC (usually I2C1 by default).

  • Make sure the address for the ATECC608 is correct for the device in use. For a non-provisioned device, this will 0xC0 by default. This should be the default setting in MCC as well. If you have provisioned the device with a different address, you will need to change the address used in MCC.

    1. Open the bootloader project

    2. Open MCC.

    3. Select the Crypto Authentication Library module in the MCC Device Resources Pane.

    4. Change the "7-bit left-aligned device I2C address" to match your device address.

    5. Click the MCC "Generate" button and try building/running the project again.

Host application fails to connect
If the host application fails to connect, check the following:

  • Make sure the PPS pin settings for the UART were configured in the bootloader project correctly for the target board

  • Make sure the UART settings for the host application matches what is configured in the bootloader project. By default, both use 9600 baud.

Debugger fails upon interrupt when debugging the bootloader project on interrupt or fails to verify with ECDSA

Some devices only have a single interrupt table. On these devices the bootloader project configures if the interrupts are used by the bootloader or forwarded to the application. The default setting is forwarded to the application. For every interrupt required by the bootloader, the developer needs to select in the table to "keep in bootloader". If this table does not show up in the bootloader project, then this is not the source of the issue.  

For ESDSA verification using the ATECC608, the default setting for the I2C is interrupts enabled. For devices that only have a single IVT, or haven't enabled the AIVT feature, the bootloader project needs to set the I2C interrupt, "MI2CxInterrupt", as "keep in bootloader".

Another possible solution is to disable the I2C master Interrupts in the bootloader project forcing the I2C master to operate in a polled mode. This is done by going to Project Resources->System->Interrupt Module and disabling the I2C Master Interrupts. The user needs to understand that this could affect other devices on this I2C bus that need interrupt driven operation while the bootloader is running.

Unexpected resets

One cause of unexpected resets is if the interrupts have not been configured correctly or the boot peripherals were not disabled prior to the bootloader running the application. This can lead to the interrupts asserting unexpectedly and if the application was not expecting it, it may lead to a device reset.  

Another cause of unexpected device reset is on a system that has only a single interrupt table. For instance, if the device has only a single interrupt table and an interrupt is needed in the bootloader, the user needs to configure the interrupt to be used by the bootloader in the MCC Bootloader configuration screen. If they do not, the main interrupt table will try to vector the interrupt to the Applications table discussed in Bootloader Interrupt Handling With Single IVT Only.