Hot!Bug MCC bootloader PIC18F25K42

Author
werner
Starting Member
  • Total Posts : 45
  • Reward points : 0
  • Joined: 2003/11/07 12:38:58
  • Status: offline
2017/09/27 02:03:55 (permalink)
0

Bug MCC bootloader PIC18F25K42

Dear MCC team,
 
MCC version: v3.26.2
MPLAB X version: v4.01 (the same with MPLAB XPress)
OS: Windows 7
Area: GUI (or Generated Code)
Device: PIC18F25K42
Peripheral: Bootloader with UART1
 
Description:
  1. Start MCC
  2. Add UART1, Memory, Bootloader to the "Project Resources"
  3. In the bootloader easy setup it is not possible to select any UART. The generated code is not complete
Please fix it in the next release,
Werner
#1

10 Replies Related Threads

    mbrowning
    Caffeine Caffeine
    • Total Posts : 561
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/09/27 03:47:17 (permalink)
    0
    You aren't using the latest mcc 3.36 where they fixed that bug. Unfortunately when you hit generate 3.36 says no compatible timer found. So still not working

    Mark
    #2
    werner
    Starting Member
    • Total Posts : 45
    • Reward points : 0
    • Joined: 2003/11/07 12:38:58
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/09/27 08:02:30 (permalink)
    0
    Sorry, I don't remarked the different versions of MCC. With MPLAX I tried with V3.36, with MPLAB XPress it was V3.26.2. With both I got the error with UART, so I am wondering why you don't got this error.
    The warning with no compatible timer I have also, but I ignored it.
    Now I am trying to use generated code from 25K40 and adapt it.
    Werner
    #3
    mbrowning
    Caffeine Caffeine
    • Total Posts : 561
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/09/27 08:26:35 (permalink)
    3 (1)
    I thought to do the k40 thing also. I found a bunch of code issues to fix, but I haven't gone further than just getting it to compile. There are some forum threads about fixing the code bugs and getting the bootloader application to work with the K40. I think it has to do with larger flash sizes.
     
    I've got a few months before board layout is complete and assembled so I'm hoping the bootloader and gui are updated to the K42 by then. I'm laying out a small proto board with just the PIC related stuff to make sure the K42 works in my application and there aren't any bugs that haven't made it into the 56k42 errata yet. If I have time and they haven't updated the bootloader, I may need to revisit creating my own.

    Mark
    #4
    mbrowning
    Caffeine Caffeine
    • Total Posts : 561
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/09/27 08:31:48 (permalink)
    0
    By the way, I tried the bootloader with 56K42 selected. Maybe there's a difference with the 25K42.
     

    Mark
    #5
    mbrowning
    Caffeine Caffeine
    • Total Posts : 561
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/11/13 10:24:02 (permalink)
    0
    I revisited generating a bootloader for the PIC18F56K42 again and have gotten it working. The bootloader generator doesn't work for K42 parts yet (for me it complained about "no compatible timer found" which is nonsensical since the bootloader code doesn't even use a timer!).
     
    I changed parts to PIC18F46K40 and fixed all the compile errors. Then made appropriate changes to the config #pragmas, port initialization code, changed all the PIR and UART registers to the K42 register names, and got rid of the interrupt goto's (not usable with IVT, which is inherently relocatable).
     
    I had to totally change the StartWrite() function from
    void StartWrite() {
        NVMCON2 = EE_Key_1;
        NVMCON2 = EE_Key_2;
        NVMCON1bits.WR = 1;       // Start the write
        return;
    }

    to
    void StartWrite() {
    //    NVMCON2 = EE_Key_1;
    //    NVMCON2 = EE_Key_2;
    //    NVMCON1bits.WR = 1;       // Start the write
        
        asm("banksel NVMCON2");
        asm("movf  _EE_Key_1,w,c");
        asm("movwf NVMCON2");
        asm("movf  _EE_Key_2,w,c");
        asm("movwf NVMCON2");
        asm("bsf   NVMCON1,1");
    }

    because XC8 used MOVFFL instructions to implement the "NVMCON2 = EE_Key_x" lines, and put a movlb right before the NVMCON1bits.WR=1 line.
     
    I made a lot of other changes to try to get the code size down including in-lining where appropriate, stripping out all the superfluous stuff that MCC adds, etc. I got it down to 1334 bytes, so fits in the 1Kword boot block size, but not the 512word boot block. I imagine PRO mode would cut it down to size, but I won't need the whole 64Kbyte program flash anyway so 2Kbytes for bootloader isn't a problem.
    post edited by mbrowning - 2017/11/13 10:25:21

    Mark
    #6
    qhb
    Superb Member
    • Total Posts : 6255
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/11/13 18:39:50 (permalink)
    3 (1)
    mbrowning
    ....
    because XC8 used MOVFFL instructions to implement the "NVMCON2 = EE_Key_x" lines, and put a movlb right before the NVMCON1bits.WR=1 line.

    Pro mode would probably fix that, but then there should be possible a way to do it in Free mode without resorting to inline assembly.
    #7
    1and0
    Access is Denied
    • Total Posts : 7134
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/11/14 09:10:15 (permalink)
    3 (1)
    mbrowning
    void StartWrite() {
        asm("banksel NVMCON2");
        asm("movf  _EE_Key_1,w,c");
        asm("movwf NVMCON2");
        asm("movf  _EE_Key_2,w,c");
        asm("movwf NVMCON2");
        asm("bsf   NVMCON1,1");
    }

    because XC8 used MOVFFL instructions to implement the "NVMCON2 = EE_Key_x" lines, and put a movlb right before the NVMCON1bits.WR=1 line.

    Why are you using variables to store the two magic numbers?
    #8
    mbrowning
    Caffeine Caffeine
    • Total Posts : 561
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/11/14 09:15:50 (permalink)
    0
    The microchip boot loader application passes the magic numbers with every command frame and they get cleared by the boot loader after processing each command. I thought it was odd and unnecessary but maintained it. I guess someone thought there might be a pic someday that uses different numbers. Go figure

    Mark
    #9
    Danno
    Super Member
    • Total Posts : 160
    • Reward points : 0
    • Joined: 2005/09/07 10:12:10
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/11/14 10:11:26 (permalink)
    5 (1)
    The dynamic keys ("magic numbers") eliminate any possibility of rogue code corrupting memory.
    #10
    mbrowning
    Caffeine Caffeine
    • Total Posts : 561
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/11/14 12:01:22 (permalink)
    0
    Danno
    The dynamic keys ("magic numbers") eliminate any possibility of rogue code corrupting memory.

    Thank you very much for the clarification .

    Mark
    #11
    Jump to:
    © 2017 APG vNext Commercial Version 4.5