Hot!Bug MCC bootloader PIC18F25K42

Page: 12 > Showing page 1 of 2
Author
Post
Essentials Only Full Version
werner
Starting Member
  • Total Posts : 53
  • 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

20 Replies Related Threads
    mbrowning
    Just a Member
    • Total Posts : 1026
    • 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

    Can't remember. I've slept since then - Mark
    #2
    werner
    Starting Member
    • Total Posts : 53
    • 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
    Just a Member
    • Total Posts : 1026
    • 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.

    Can't remember. I've slept since then - Mark
    #4
    mbrowning
    Just a Member
    • Total Posts : 1026
    • 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.
     

    Can't remember. I've slept since then - Mark
    #5
    mbrowning
    Just a Member
    • Total Posts : 1026
    • 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

    Can't remember. I've slept since then - Mark
    #6
    qhb
    Superb Member
    • Total Posts : 6262
    • 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 : 8214
    • 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.5 (2)
    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
    Just a Member
    • Total Posts : 1026
    • 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

    Can't remember. I've slept since then - Mark
    #9
    Danno
    Super Member
    • Total Posts : 202
    • 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
    Just a Member
    • Total Posts : 1026
    • 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 .

    Can't remember. I've slept since then - Mark
    #11
    cemerick
    New Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2017/10/20 09:58:53
    • Location: 0
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/11/29 11:40:57 (permalink)
    0
    I have been struggling to get a working bootloader for 18F26K42. I tired using the same approach you did by using a K40 and then modifying for K42.  Would you mind clarifying what PC application you are using (and version)  to send the hex file to the bootloader ? My bootloader compiles but the PC application never gets past the get version step.  Am currently getting the QT environment setup so I can debug what is going wrong.  Would you mind sharing whatever code you can that might others get this working ?  Is there actually a version of MCC coming that supports the 18F26K42 soon ?  
    #12
    mbrowning
    Just a Member
    • Total Posts : 1026
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/11/29 13:04:13 (permalink)
    5 (1)
    I used the unifiedhost-0.1.8-dist.zip bootloader application from http://www.microchip.com/promo/8-bit-bootloader. It's a jar file, so you have to install java if you don't already have it. The MCC bootloader generator generates code that works with it, although if you have more skills than I in writing PC code you could probably make your own.
     
    I had to fix a lot of register name issues in converting to k42, and ultimately rewrite the StartWrite function as shown above because the compiler wouldn't generate proper unlocking assembly code. I just ran the bootloader with pickit3 as debugger and worked through most problems pretty quickly.
     
    I did a lot of rewriting the MCC code to try to get the code down to less than 1Kbyte, but only got it down to 1186 bytes (xc8 free). I'm sure I could get it less with more inline assembly work, but my application plus bootloader is less than 16Kbytes so it seems unnecessary.

    Can't remember. I've slept since then - Mark
    #13
    cemerick
    New Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2017/10/20 09:58:53
    • Location: 0
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/11/29 20:52:17 (permalink)
    0
    I am still stuck at the getting version stage.
    Do you see anything wrong with the communications compared to what you send/receive ?
     
    Clark
     

    Attached Image(s)

    #14
    mbrowning
    Just a Member
    • Total Posts : 1026
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/11/30 11:00:16 (permalink)
    0
    The bytes transferred look good. I didn't have any problems with this and never looked at the datastream.

    Can't remember. I've slept since then - Mark
    #15
    mbrowning
    Just a Member
    • Total Posts : 1026
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/11/30 12:58:08 (permalink)
    0
    I edited the original bootloader code from MCC so much I wasn't sure if I had fixed something along the way, so I started from scratch and created another one. Starting with pic18f46k40, I followed the bootloader generator user's guide and created a new project with bootloader. I use offset 0x800, UART1, and the check reset vector method, and hit "generate"
     
    I then closed MCC, changed the device to pic18f56k42 and compiled. I fixed the compile errors and made a few other changes along the way. In the Unified Bootloader app (0.1.8) I set offset=0x800, eeprom=0x310000, progsize=0x8000, eepromsize=0x400, selected program eedata, 115200baud, and it worked.
     
    I did use exactly the same config settings in bootloader and application.
     
    Here's a complete list of the changes:
    mcc.c
        swapped out the config bits for that of my main project

    memory.c
        changed all instances of "INTCON" to "INTCON0"
        MEMORY_Tasks function
            commented out NVMIF=0 line

    eusart.c
        EUSART1_Initialize function
            swapped out code for proper K42 initialization
        EUSART1_Read function
            changed PIR3bits.RC1IF to PIR3bits.U1RXIF
            commented out the if(OERR) section
            changed RC1REG to U1RXB
        EUSART1_Write function
            changed PIR3bits.TX1IF to PIR3bits.U1TXIF
            changed TX1REG to U1TXB

    pic18f_bootload.c
        Get_Version_Data function
            changed NVMCON1bits.CFGS to NVMCON1bits.NVMREG
        Write_Config function
            changed EECON1 to NVMCON1
        StartWrite function
            replaced original code with inline assembly

        commented out the service_isr functions

    pic18f_uart.c
        Run_Bootloader function
            changed TXSTA1bits.TRMT to U1ERRIRbits.TXMTIF
            changed BAUDCONbits.ABDEN to U1CON0bits.ABDEN
            changed BAUDCONbits.ABDOVF to U1ERRIRbits.ABDOVF
            changed RCREG to U1RXB

    pin_manager.c
        PIN_MANAGER_Initialize function
            replaced LAT thru ODCON initialization with my own
            replaced uart PPS initialization with my own
           
     
     

    Can't remember. I've slept since then - Mark
    #16
    cemerick
    New Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2017/10/20 09:58:53
    • Location: 0
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/12/01 10:00:12 (permalink)
    0
    I found that the problem with the check version was that the STX was defined as 0x0F.  I changed that to 0x55 and the check version worked.  I then could get all the way through a successful write but then the checksum did not return with a success code.  Looking at the code I don't see where it provides the command success code like the document indicates it should. See below.  
    // *****************************************************************************************
    // Calculate Checksum
    // In: [<0x08><DataLengthL><DataLengthH> <unused><unused> <ADDRL><ADDRH><ADDRU><unused>...]
    // OUT: [9 byte header + ChecksumL + ChecksumH]
    // Cmd Length----- Address--------------- Data ---------
    // In: [<0x08> <0x00><0x00><0x00><0x00> <0x00><0x00><0x00><0x00>]
    // OUT: [<0x08> <0x00><0x00><0x00><0x00> <0x00><0x00><0x00><0x00> <CheckSumL><CheckSumH>]
    // *****************************************************************************
    uint8_t Calc_Checksum()
    {
    TBLPTRL = frame.address_L;
    TBLPTRH = frame.address_H;
    TBLPTRU = frame.address_U;
    NVMCON1 = 0x80;
    check_sum = 0;
    for (uint16_t i = 0;i < frame.data_length; i += 2)
    {
    asm("TBLRD *+");
    check_sum += (uint16_t)TABLAT;
    asm("TBLRD *+");
    check_sum += (uint16_t)TABLAT << 8;
    }
    frame.data[0] = (uint8_t) (check_sum & 0x00FF);
    frame.data[1] = (uint8_t)((check_sum & 0xFF00) >> 8);
    return (11);
     
     The bootloader docs indicate in one place for checksum :
    Rx from Device: Command String:0x08 0x00 0x3B 0x00 0x00 0x00 0x05 0x00 0x00 Checksum:0x15 0x4D
     
    But then example includes a command success status ahead of the checksum.
    So I am not 100% sure what the PC application requires for success.
     
     
     
    #17
    mbrowning
    Just a Member
    • Total Posts : 1026
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/12/01 10:48:23 (permalink)
    0
    I gather you are trying to get your own bootloader application working? I had no problem with the Microchip supplied one. Have you tried that one to make sure your PIC code is functional?
     
    The command success/fail byte is only included in Write_Flash, Erase_Flash, and Write_Config functions. Obviously the user guide has some issues - mainly in the Figures.

    Can't remember. I've slept since then - Mark
    #18
    cemerick
    New Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2017/10/20 09:58:53
    • Location: 0
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/12/01 18:19:10 (permalink)
    0
    I added the command success and checksum per the doc and still no luck.
    Stuck at :
    17:13:27.424 > Bootloader Version Read Successful
    17:13:27.424 > Erasing Device ...
    17:13:27.773 > Erase Successful
    17:13:27.773 > Programming Flash ...
    17:13:27.870 > Flashed Programmed
    17:13:27.870 > Retrieving Checksum ..
     
    No way I know of to debug what is making PC ap unhappy and not moving onto next block to program.
    It did write the first block ok but won't continue without the checksum stage working.
     
     
    #19
    cemerick
    New Member
    • Total Posts : 7
    • Reward points : 0
    • Joined: 2017/10/20 09:58:53
    • Location: 0
    • Status: offline
    Re: Bug MCC bootloader PIC18F25K42 2017/12/02 10:40:43 (permalink)
    0
    Debugging the jar I see the checksum not matching per the debug output below :
    Theoretical Checksum:78FB4B4C
    Receieved Checksum:5501
     
    So the 16bit checksum is not going to match the 32bit checksum the jar program is using.
     
     
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2018 APG vNext Commercial Version 4.5