• AVR Freaks

Hot!Bug report with unified bootloader generator in MCC for PIC18F26K40

New Member
  • Total Posts : 18
  • Reward points : 0
  • Joined: 2016/02/28 02:21:37
  • Location: 0
  • Status: offline
2019/02/19 15:35:26 (permalink)

Bug report with unified bootloader generator in MCC for PIC18F26K40

Hi All,

I have generated bootloader source through MCC (latest version as of 3 weeks ago) for PIC18F26K40 and got it working after a few tweaks and learning it in depth.
It was all working until in new version of my firmware app the data structure I'm putting in EEPROM started to grow over 256 bytes, where I noticed I'm getting corruption in the beginning section of EEPROM.
Looking at source code I noticed, to much of my surprise, that the Write_EE_Data() and Read_EE_Data functions only dealing with low byte of NVMADR register (NVMADRL actually) which can only address 256 bytes and rest of the data rolls back and overwrites into beginning of EEPROM, hence corruption. Here is generated code:

// *****************************************************************************
// Write_EE_Data
// Cmd Length----- Address--------------- Data ---------
// In: [<0x05> <0x00><0x00><0x55><0xAA> <0x00><0x00><0x00><0x00> <Data>..<data>]
// OUT: [<0x05> <0x00><0x00><0x00><0x00> <0x00><0x00><0x00><0x00> <0x01>]
// *****************************************************************************
uint8_t Write_EE_Data()
NVMADR = frame.address_L;
NVMCON1 = 0x04; // b'00000100'; // Setup for EEData
for (uint8_t i = 0; i < frame.data_length; i++)
while (NVMCON1bits.WR == 1); // wait until previous write complete

NVMDAT = frame.data[i];
StartWrite ();
frame.data[0] = COMMAND_SUCCESS;
return 10;

In my opinion, there are a few things wrong with it. Firstly, before writing a byte it waits for previous write operation to finish. This might not be a show stopper if it doesn't block before the very first data item.
Secondly, it increments (++NVMADR) before writing the first data item, wouldn't it be dislocated?!
Thirdly, knowing PIC18F26K40 has 1KB of EEPROM, why MCC generates a bootloader which only handles 256 byte? A possible bug?

Any thoughts folks?
If you think this is a bug to be reported, where is the official place to lodge that bug report, can someone please tell me or just do it on my behalf?
By the way my modified and working version is attached below, for what it's worth.

Thanks all,

// My modified version
uint8_t Write_EE_Data() {
NVMADRL = frame.address_L;
NVMADRH = frame.address_H;

NVMCON1 = 0x04; // b'00000100'; // Setup for EEData
for (uint8_t i = 0; i < frame.data_length; i++) {
NVMDAT = frame.data[i];

while (NVMCON1bits.WR == 1) // wait until previous write complete
CLRWDT(); // With default CONFIG register values (no configuration) WDT is ON and operating, so avoiding potential WDT resets
if (NVMADRL == 0) {
if (NVMADRH > 3) { // 000-3FF for PIC18F26K40
return 10;
frame.data[0] = COMMAND_SUCCESS;
return 10;


post edited by m_alizd - 2019/02/28 19:04:41

1 Reply Related Threads

    Superb Member
    • Total Posts : 9998
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: Bug report with unified bootloader generator in MCC for PIC18F26K40 2019/02/19 17:18:11 (permalink)
    4 (1)
    Your array indices are not appearing because you did not place code tags around your code.
    Put [ code ] before, and [ /code ] after your block of code (but without the embedded spaces), otherwise [] with "i" inside is taken as "start italics" by the forum.
    To be safe, the first "wait for WR" should be before ANY access to NVM registers, as they can't be changed if a previous cycle is active.
    Agree, the increment of NVMADRL appears to be in the wrong place, and it requires correct handling of NVMADRH.
    The official place to lodge bug reports is via a "Support Ticket".
    post edited by qhb - 2019/02/19 17:19:16

    Nearly there...
    Jump to:
    © 2019 APG vNext Commercial Version 4.5