Helpful ReplyHot!Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version Read

Page: 12 > Showing page 1 of 2
Author
SebKister
Junior Member
  • Total Posts : 43
  • Reward points : 0
  • Joined: 2016/05/14 15:32:13
  • Location: Playa del Carmen, Mexico
  • Status: offline
2016/11/21 23:08:47 (permalink)
5 (2)

Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version Read

After generating a bootloader with MCC  3.25 + 8b bootloader library 2.2.0 these are the changes needed so that the resulting code compiles:

In the AutoBaud section:
BAUDCONbits has to be replaced by BAUDxCONbits depending on which EUSART is used
Same for RCREGS with RCxREG
In Get_Version_Data() :
NVMCON1bits.CFGS = 1; replaced by
NVMCON1bits.NVMREG0 = 1;
In Read_EE_Data() and Write_EE_Data():
NVMDATA replaced by NVMDAT
In Write_Config ():
EECON1 replaced by NVMCON1
 
On top of that add here and there
NVMCON1bits.NVMREG0 = 0;
NVMCON1bits.NVMREG1 = 1;
as required by silicon errata sheet DS80000713A
 
But then when the bootloader works (at least the polling loop and Get_Version_Data()) as it i supposed to on the MCU, the Unified Bootloader closes COM after displaying "Bootloader Version Read Successful" in the console. The next message that should be displayed in the console before any other COM activity is ""Erasing Device ..." and that one doesn't get displayed.
The significant function that is called in the unified bootloader before "Erasing Device ...." is  createAllExceptReadVersion();
There seems to be something not going as it is supposed to there. Are my parameters wrong  ? This is a port from a working solution on the 16F18877 to the 18F47K40. (using 0x1000  for Bootloader Offset and 0x40000 for Program size )
 
Seeing the draft-style generated code, I'm not sure anyone actually tested the bootloader host/client on that PIC. Maybe Dan can bring some light on the subject ?
Thanks in advance.
 
PS/ For info this is the significant COM activity
 IRP_MJ_WRITE DOWN  55 00 00 00 00 00 00 00 00 00  
 IRP_MJ_READ UP  55 00 00 00 00 00 00 00 00 00 19 00 00 01 00 00 69 00 00 00  80 80 8C FF FF D7   
 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK DOWN 00 00 00 00 
 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_WAIT_MASK UP 
 IRP_MJ_CLOSE DOWN 
 IRP_MJ_CLOSE UP   
 
#1
Danno
Super Member
  • Total Posts : 206
  • Reward points : 0
  • Joined: 2005/09/07 10:12:10
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2016/11/22 15:45:12 (permalink)
3 (1)
PIC18F's are byte based so the addresses entered are the actual sizes in the datasheet.  (Only need to multiply by 2 for the word based PIC16F's).
 
Suggest try it with the memory size of 0x20000.  (and halve the offset if you'd previously multiplied by 2).
 
#2
SebKister
Junior Member
  • Total Posts : 43
  • Reward points : 0
  • Joined: 2016/05/14 15:32:13
  • Location: Playa del Carmen, Mexico
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2016/11/22 19:40:58 (permalink)
0
I tried with proper parameter ( in my case offset of 0x800 ) and memory size of 0x20000. Had the same result as described before. Btw pressing again "Program Device" after 1st unsuccessful attempt won't go any further then "Device: COM7 Bootloading started" message. You need to restart the unified bootloader to go as far as "Bootloader Version Read Successful".
 
#3
SebKister
Junior Member
  • Total Posts : 43
  • Reward points : 0
  • Joined: 2016/05/14 15:32:13
  • Location: Playa del Carmen, Mexico
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2016/11/26 16:46:52 (permalink)
4 (2)
I ended up programming my own bootloader host using the same protocol then the one defined by the 8bit bootloader library generated code. That solved the issue. So apparently the problem lies with the unified bootloader. The code generated for 18F47K40 by MCC a part from modifications mentioned above is ok. 
#4
SebKister
Junior Member
  • Total Posts : 43
  • Reward points : 0
  • Joined: 2016/05/14 15:32:13
  • Location: Playa del Carmen, Mexico
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2016/11/28 19:41:37 (permalink)
0
I unfortunately have to signal another problem in the MCC generated bootloader. The High/Low interrupt priority vector implementation is not working. I had to replace 
 
void interrupt high_priority service_isr_high() {
asm("pagesel " str(NEW_INTERRUPT_VECTOR_HIGH));
asm("goto " str(NEW_INTERRUPT_VECTOR_HIGH));
}
void interrupt low_priority service_isr_low() {
asm("pagesel " str(NEW_INTERRUPT_VECTOR_LOW));
asm("goto " str(NEW_INTERRUPT_VECTOR_LOW));
}
 
by the standard 
void interrupt service_isr(){
asm ("pagesel " str (NEW_INTERRUPT_VECTOR_HIGH));
asm ("goto " str (NEW_INTERRUPT_VECTOR_HIGH));
}
 
so that my production code continues working once loaded. The I2C interrupt seemed not to function as it should have ( and that whether it was placed in High or Low priority ).
 
The problem can be reproduced for the simple scenario of a blinking LED on Timer 1 Interrupt. If loaded by the bootloader when interrupt is High priority blinking happens, when low priority nothing happens.
Replacing by the standard  interrupt service_isr solves the problem.
 
I haven't looked precisely at the assembly generated, just noticed that the High/Low services backed-up and restored  STATUS, WREG and BSR. The standard service doesn't.
 
 
 
#5
Danno
Super Member
  • Total Posts : 206
  • Reward points : 0
  • Joined: 2005/09/07 10:12:10
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2016/12/08 16:44:52 (permalink)
0
Sorry..  this was meant to be a PM.
post edited by Danno - 2016/12/08 16:50:01
#6
WB
Super Member
  • Total Posts : 230
  • Reward points : 0
  • Joined: 2012/06/25 15:58:55
  • Location: Chandler, AZ
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2016/12/09 10:36:28 (permalink)
3 (1)
SebKister
The problem can be reproduced for the simple scenario of a blinking LED on Timer 1 Interrupt. If loaded by the bootloader when interrupt is High priority blinking happens, when low priority nothing happens.
Replacing by the standard  interrupt service_isr solves the problem.

 
I tried this and it works. Perhaps you are missing some initialization. Here's my sample code as an example you can use for comparison.
 
Configuration file:
// PIC18F46K40 Configuration Bit Settings

// 'C' source line config statements

// CONFIG1L
#pragma config FEXTOSC = OFF // External Oscillator mode Selection bits (Oscillator not enabled)
#pragma config RSTOSC = HFINTOSC_64MHZ// Power-up default value for COSC bits (HFINTOSC with HFFRQ = 64 MHz and CDIV = 1:1)

// CONFIG1H
#pragma config CLKOUTEN = OFF // Clock Out Enable bit (CLKOUT function is disabled)
#pragma config CSWEN = OFF // Clock Switch Enable bit (The NOSC and NDIV bits cannot be changed by user software)
#pragma config FCMEN = OFF // Fail-Safe Clock Monitor Enable bit (Fail-Safe Clock Monitor disabled)

// CONFIG2L
#pragma config MCLRE = EXTMCLR // Master Clear Enable bit (If LVP = 0, MCLR pin is MCLR; If LVP = 1, RE3 pin function is MCLR )
#pragma config PWRTE = OFF // Power-up Timer Enable bit (Power up timer disabled)
#pragma config LPBOREN = OFF // Low-power BOR enable bit (ULPBOR disabled)
#pragma config BOREN = SBORDIS // Brown-out Reset Enable bits (Brown-out Reset enabled , SBOREN bit is ignored)

// CONFIG2H
#pragma config BORV = VBOR_2P45 // Brown Out Reset Voltage selection bits (Brown-out Reset Voltage (VBOR) set to 2.45V)
#pragma config ZCD = OFF // ZCD Disable bit (ZCD disabled. ZCD can be enabled by setting the ZCDSEN bit of ZCDCON)
#pragma config PPS1WAY = OFF // PPSLOCK bit One-Way Set Enable bit (PPSLOCK bit can be set and cleared repeatedly (subject to the unlock sequence))
#pragma config STVREN = ON // Stack Full/Underflow Reset Enable bit (Stack full/underflow will cause Reset)
#pragma config DEBUG = OFF // Debugger Enable bit (Background debugger disabled)
#pragma config XINST = OFF // Extended Instruction Set Enable bit (Extended Instruction Set and Indexed Addressing Mode disabled)

// CONFIG3L
#pragma config WDTCPS = WDTCPS_31// WDT Period Select bits (Divider ratio 1:65536; software control of WDTPS)
#pragma config WDTE = OFF // WDT operating mode (WDT Disabled)

// CONFIG3H
#pragma config WDTCWS = WDTCWS_7// WDT Window Select bits (window always open (100%); software control; keyed access not required)
#pragma config WDTCCS = SC // WDT input clock selector (Software Control)

// CONFIG4L
#pragma config WRT0 = OFF // Write Protection Block 0 (Block 0 (000800-003FFFh) not write-protected)
#pragma config WRT1 = OFF // Write Protection Block 1 (Block 1 (004000-007FFFh) not write-protected)
#pragma config WRT2 = OFF // Write Protection Block 2 (Block 2 (008000-00BFFFh) not write-protected)
#pragma config WRT3 = OFF // Write Protection Block 3 (Block 3 (00C000-00FFFFh) not write-protected)

// CONFIG4H
#pragma config WRTC = OFF // Configuration Register Write Protection bit (Configuration registers (300000-30000Bh) not write-protected)
#pragma config WRTB = OFF // Boot Block Write Protection bit (Boot Block (000000-0007FFh) not write-protected)
#pragma config WRTD = OFF // Data EEPROM Write Protection bit (Data EEPROM not write-protected)
#pragma config SCANE = ON // Scanner Enable bit (Scanner module is available for use, SCANMD bit can control the module)
#pragma config LVP = OFF // Low Voltage Programming Enable bit (HV on MCLR/VPP must be used for programming)

// CONFIG5L
#pragma config CP = OFF // UserNVM Program Memory Code Protection bit (UserNVM code protection disabled)
#pragma config CPD = OFF // DataNVM Memory Code Protection bit (DataNVM code protection disabled)

// CONFIG5H

// CONFIG6L
#pragma config EBTR0 = OFF // Table Read Protection Block 0 (Block 0 (000800-003FFFh) not protected from table reads executed in other blocks)
#pragma config EBTR1 = OFF // Table Read Protection Block 1 (Block 1 (004000-007FFFh) not protected from table reads executed in other blocks)
#pragma config EBTR2 = OFF // Table Read Protection Block 2 (Block 2 (008000-00BFFFh) not protected from table reads executed in other blocks)
#pragma config EBTR3 = OFF // Table Read Protection Block 3 (Block 3 (00C000-00FFFFh) not protected from table reads executed in other blocks)

// CONFIG6H
#pragma config EBTRB = OFF // Boot Block Table Read Protection bit (Boot Block (000000-0007FFh) not protected from table reads executed in other blocks)

Main file:
#include <xc.h>

void interrupt high_priority HPISR(void){
    // flash LED on RB1 at Timer1 overflow rate
    LATBbits.LB1 = !LATBbits.LB1;
    PIR4bits.TMR1IF = 0;
}

void interrupt low_priority LPISR(void){
    // flash LED on RB2 at Timer3 overflow rate
    LATBbits.LB2 = !LATBbits.LB2;
    PIR4bits.TMR3IF = 0;
}

void main(void){
    // setup Timer1 and Timer3 for interrupts which will toggle RB1 and RB2 respectively
    
    // Enable I/Os
    TRISBbits.RB1 = 0;
    TRISBbits.RB2 = 0;
    ANSELBbits.ANSELB1 = 0;
    ANSELBbits.ANSELB2 = 0;
    // Enable timers
    T1CLKbits.CS = 0x5; // MFINTOSC (500 kHz)
    T1CONbits.CKPS = 0x1; // 1:2 prescale -> Rolls over every 0.262 seconds
    T3CLKbits.CS = 0x5; // MFINTOSC (500 kHz)
    T3CONbits.CKPS = 0x2; // 1:4 prescale -> Rolls over every 0.524 seconds
    T1CONbits.ON = 1; // start Timer1
    T3CONbits.ON = 1; // start Timer3
    // Enable interrupts
    IPR4bits.TMR1IP = 1; // Timer1 high priority
    IPR4bits.TMR3IP = 0; // Timer3 low priority
    PIE4bits.TMR1IE = 1;
    PIE4bits.TMR3IE = 1;
    INTCONbits.IPEN = 1; // enable priority interrupts
    INTCONbits.GIEL = 1; // enable low priority
    INTCONbits.GIEH = 1; // enable high priority
    
    while(1); // ISRs do the rest
}


-WB-
#7
SebKister
Junior Member
  • Total Posts : 43
  • Reward points : 0
  • Joined: 2016/05/14 15:32:13
  • Location: Playa del Carmen, Mexico
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2017/01/09 18:22:54 (permalink)
3 (1)
Sorry for the delay in the reply but I finally had the time to go back to this project. 
In the blinking led demo I was referring to in my former post I forgot to correct the MCC bug which assigns the low priority  interrupt address to high and vis versa.
 
I managed to run the firmware with bootloader on the PIC18F47K40 but only in PIC16F interrupt compatibility mode. If I use the High/Low priority interrupt the displayed text on the I2C LCD show corrupted characters. Might well be a consequence of the silicon issue. 
post edited by SebKister - 2017/01/09 19:56:20
#8
srobison
New Member
  • Total Posts : 6
  • Reward points : 0
  • Joined: 2014/01/28 11:44:24
  • Location: 0
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2017/01/10 22:15:03 (permalink)
3 (1)
After struggling for hours with this to get anywhere, I realized my problem was with bad baud rates being detected on account of running the INTOSC to slow.  Now that I'm at 16 MHz, I made it a little further.  I can now read the version and get the console message "Erasing Device ...". The Status in the main window shows Connected Successfully.  However, after a few moments of apparently erasing the application program flash, the status turns to "Disconnected after Programming Failed." again.  I'm on MPLAB 3.50 with bootload generator 2.2 on a PIC16F1947.  Any suggestions on what might be the issue?  Can you say more about writing your own bootloader host? Thanks in advance.

 
#9
SebKister
Junior Member
  • Total Posts : 43
  • Reward points : 0
  • Joined: 2016/05/14 15:32:13
  • Location: Playa del Carmen, Mexico
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2017/01/10 22:39:45 (permalink) ☄ Helpfulby srobison 2017/01/11 10:58:05
5 (1)
Hi,
 
if you want I can give you details about implementing your own host but I only went into that direction because Microchip s unified bootloader was not working for the PIC18FxxK40. I used the unified bootloader successfully with PIC 16F18877 and 16F1619.
In your case if your main application is located at 0x300 (words), the offset should be 0x600 and the program memory size should be 0x8000 for the PIC16F1947. Hope that will help. Cheers.
 
#10
PIC16F1788
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2017/10/24 05:09:31
  • Location: 0
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2017/11/23 05:46:03 (permalink)
0

PIC16F1789 bootloader Problems while using unified bootloader application(Host)

MPLAB X IDE v3.5(with XC8), Unified bootloader v0.1.8, Explorer 8, Pic Kit3 and PIC16F1789 are used.
 
Hi everyone. I am working with The bootloader for the first time, I have generated it from MCC and now trying to send the application Hex file to the bootloader Via unified Host software provided by Microchip. Initially i had alot of problems regarding device detection etc but thankfully i have moved a step forward now. At present i am stuck at a step where the checksum is retrieved i.e. when i press 'Program device' in the Unified bootloader application(Host), it shows following progress in the Console window of the application:
 
> Device: COM8 Bootloading started
> Reading Version ...
> Bootloader Version Read Successful
> Erasing Device ...
> Erase Successful
> Programming Flash ...
> Flashed Programmed
> Retrieving Checksum ...
 
and then at this point i get the status: Disconnected after Programming failed in the host.
 
I am already trying to solve it from couple of days and till now I did not find any solution. I hope there will be someone over here who can help me out.
 
Thank you in Advance!
#11
SebKister
Junior Member
  • Total Posts : 43
  • Reward points : 0
  • Joined: 2016/05/14 15:32:13
  • Location: Playa del Carmen, Mexico
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2017/11/23 19:14:11 (permalink)
0
Hi, 
 
which version of MCC are you using ? When you check the PIC Memory did the programming actually occur ? Successfully ? 
#12
Danno
Super Member
  • Total Posts : 206
  • Reward points : 0
  • Joined: 2005/09/07 10:12:10
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2017/11/27 13:45:32 (permalink) ☄ Helpfulby PIC16F1788 2017/11/28 06:55:20
5 (1)
PIC16F1788 (on you PIC16F1789 project):
 
Take a look at the disassembly for the addition step in the checksum code. 

checksum += EEDATA;

It was originally written to use 16 bit math but that proved to be inconsistent.  Instead we now do two 8 bit adds.

checksum += EEDATL;
checksum += (EEDATH << 8);

 
HTH!
#13
PIC16F1788
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2017/10/24 05:09:31
  • Location: 0
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2017/11/28 07:11:13 (permalink)
0
Thank you Brother!!!! The checksum already worked. Application part although started working earlier (I built some test apps with blinking LED codes). At the moment i am trying to write applications of size 26 kB and above (e.g. the one provided by microchip for explorer 8 board) till now it's not showing a  positive response but as far as i have understood it's because i did not manage the correct address or a codeoffset. I am working on that right now. If you have any suggestions then i would love to hear them.
 
one more point to clear:
 

extern volatile  uint16_t         EEDAT               @0x81C; 

 
The statement above is created by the MCC after the code is generated but if i don't comment it i am getting errors related to redeclaration i.e. the following in the output window:
 
"
mcc_generated_files/pic16f1_bootload.c:102: error: (984) type redeclared
mcc_generated_files/pic16f1_bootload.c:102: error: (1098) conflicting declarations for variable "EEDAT" (mcc_generated_files/pic16f1_bootload.c:102)
(908) exit status = 1
nbproject/Makefile-With_Configuration.mk:164: recipe for target 'build/With_Configuration/production/mcc_generated_files/pic16f1_bootload.p1' failed
make[2]: *** [build/With_Configuration/production/mcc_generated_files/pic16f1_bootload.p1] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory 'C:/Arsalan/V1.0/V1.0/BT_Test1_1789.X'
nbproject/Makefile-With_Configuration.mk:84: recipe for target '.build-conf' failed
make[1]: Leaving directory 'C:/Arsalan/V1.0/V1.0/BT_Test1_1789.X'
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
BUILD FAILED (exit value 2, total time: 3s)
"
 
 
Thanks again!
 
Best Regards,
 
Danno
PIC16F1788 (on you PIC16F1789 project):
 
Take a look at the disassembly for the addition step in the checksum code. 

 
checksum += EEDATA;
 

It was originally written to use 16 bit math but that proved to be inconsistent.  Instead we now do two 8 bit adds.

 
checksum += EEDATL;
 
checksum += (EEDATH << 8);
 

 
HTH!




#14
Danno
Super Member
  • Total Posts : 206
  • Reward points : 0
  • Joined: 2005/09/07 10:12:10
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2017/12/04 16:41:07 (permalink)
0
PIC16F1788 - did you get it working? 
 
Just remove the EEDAT definition.  Some parts have (had?) it defined as a 16 bit register and some did not :-(
#15
PIC16F1788
New Member
  • Total Posts : 24
  • Reward points : 0
  • Joined: 2017/10/24 05:09:31
  • Location: 0
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2017/12/05 03:12:30 (permalink)
0
Yes its working now. I already removed this EEDAT statement. I am now moving forward at present looking into the hex and yes they have the right checksums (which i calculated from random lines of the hex file and they were same as calculated by the boot-loader).
 
But with the larger application which is provided by microchip i believe have many features and configs that are different in my boot-loader and also many of the features are not supported by the boot-loader which are present in the app that's why i believe it is not working with my boot-loader. I will now make my own applications with all those features that i need for my project and then i hope everything will work out. If something goes wrong then for sure will come back to you. :)
 
Thanks again to all in special Danno.
 
Best Regards and Happy Holiday season in advance :)
 
Danno
PIC16F1788 - did you get it working? 
 
Just remove the EEDAT definition.  Some parts have (had?) it defined as a 16 bit register and some did not :-(




#16
hungChun
New Member
  • Total Posts : 1
  • Reward points : 0
  • Joined: 2016/05/31 02:08:06
  • Location: 0
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2017/12/20 01:03:50 (permalink)
0
18F67K40, exactly the same problems
MPLAB X 4.05
MCC 3.45.1
XC8 1.45
 
All latest version so far, nothing fixed (include +NVMREG in errorta...)
 
when I attend the MASTERs courses , the teaching assistant almost failed doing the bootloader labs, just because the buggy environment.
 
 
I also asked about the source code of host application(jar), the replay is the microchip team don't wanna provide it since this year, and  No example of bootloader protocol.
 
In my application, I want to save the hex file in external Flash and the bootloader just load it and do programming,
but no option about this in MCC. I have to read the code with many magical parts and insert my custom code, without enough document (maybe not so hard if I can compile successfully after generate...)
 
Will the error code generated by MCC be fixed?
"C:\Program Files (x86)\Microchip\xc8\v1.45\bin\xc8.exe" --pass1 --chip=18F67K40 -Q -G --double=24 --float=24 --emi=wordwrite --opt=+asm,+asmfile,-speed,+space,-debug,-local --addrqual=ignore --mode=free -P -N255 --warn=-3 --asmlist -DXPRJ_default=default --summary=default,-psect,-class,+mem,-hex,-file --errata=+NVMREG --output=default,-inhx032 --runtime=default,+clear,+init,-keep,-no_startup,-download,+config,+clib,-plib --output=-mcof,+elf:multilocs --stack=compiled:auto:auto:auto "--errformat=%f:%l: error: (%n) %s" "--warnformat=%f:%l: warning: (%n) %s" "--msgformat=%f:%l: advisory: (%n) %s" -obuild/default/production/mcc_generated_files/mcc.p1 mcc_generated_files/mcc.c 
mcc_generated_files/pic18f_uart.c:76: error: (192) undefined identifier "BAUDCONbits"
mcc_generated_files/pic18f_uart.c:76: error: (196) struct/union required
mcc_generated_files/pic18f_uart.c:77: error: (196) struct/union required
mcc_generated_files/pic18f_uart.c:79: error: (196) struct/union required
mcc_generated_files/pic18f_uart.c:81: error: (196) struct/union required
mcc_generated_files/pic18f_uart.c:82: error: (196) struct/union required
mcc_generated_files/pic18f_uart.c:83: error: (196) struct/union required
mcc_generated_files/pic18f_uart.c:87: error: (192) undefined identifier "RCREG"
mcc_generated_files/pic18f_uart.c:87: warning: (373) implicit signed to unsigned conversion
(908) exit status = 1
mcc_generated_files/pic18f_bootload.c:237: error: (255) not a member of the struct/union ""
mcc_generated_files/pic18f_bootload.c:237: error: (182) illegal conversion between types
int -> volatile union S1317
mcc_generated_files/pic18f_bootload.c:251: error: (255) not a member of the struct/union ""
mcc_generated_files/pic18f_bootload.c:251: error: (182) illegal conversion between types
int -> volatile union S1317
mcc_generated_files/pic18f_bootload.c:352: error: (192) undefined identifier "NVMDATA"
mcc_generated_files/pic18f_bootload.c:352: warning: (373) implicit signed to unsigned conversion
mcc_generated_files/pic18f_bootload.c:371: warning: (373) implicit signed to unsigned conversion
mcc_generated_files/pic18f_bootload.c:372: error: (192) undefined identifier "NVMDATA"
mcc_generated_files/pic18f_bootload.c:421: error: (192) undefined identifier "EECON1"
nbproject/Makefile-default.mk:170: recipe for target 'build/default/production/mcc_generated_files/pic18f_uart.p1' failed
(908) exit status = 1
nbproject/Makefile-default.mk:162: recipe for target 'build/default/production/mcc_generated_files/pic18f_bootload.p1' failed
make[2]: *** [build/default/production/mcc_generated_files/pic18f_uart.p1] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [build/default/production/mcc_generated_files/pic18f_bootload.p1] Error 1
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
make[2]: Leaving directory 'D:/MicrochipProject/485ControlBoxBoot.X'
nbproject/Makefile-default.mk:90: recipe for target '.build-conf' failed
make[1]: Leaving directory 'D:/MicrochipProject/485ControlBoxBoot.X'
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
BUILD FAILED (exit value 2, total time: 2s)
#17
mbrowning
Just a Member
  • Total Posts : 1067
  • Reward points : 0
  • Joined: 2005/03/16 14:32:56
  • Location: Melbourne, FL
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2017/12/20 10:38:38 (permalink)
0
It is frustrating that the bootloader generator makes code that won't even compile. I didn't find it very difficult to fix the register names - in my case for K42 rather than K40 - and then it just worked.
 
I did find a K40/K42 bug in the Write_Config() function and reported it (with a support ticket) - it tests if the address is userID or config and uses a different NVMCON1 setting. For K40/K42 the user id and config spaces use the same NVMCON1 setting.
 
Because I can't use the java gui host application in production, I used the bootloader generator user guide and wrote my own host command line application in visual studio 2017 visual basic. It was pretty easy.
 
I've done bootloaders in the past that do what you want - save the downloaded file in external flash. In my case I was loading code wirelessly and I did the code loading to external in the main code and the bootloader just looked in the external flash to see if a new version was available and moved it to internal flash.

Go Navy! Beat Army!
#18
indisky
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2012/09/11 11:40:12
  • Location: 0
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2018/01/05 18:41:33 (permalink)
0
Regarding the checksum issue, I had the same problem with pic16f1705 (mplab4.05/xc 1.45/mcc3.45.1), along with memory usage which exceeds the 0x300 nominal word size for the bootloader:
changed:
        check_sum += PMDAT;
to:
        check_sum += PMDATL;
        check_sum += (PMDATH << 8);
 
The same problem existed with the PMADR/PMDAT blank vector check in the bootloader startup, had to split that up into the high and low bytes, after which it finally installed the application code as intended.

In my case the un-optimized code takes up 0x3e2 words, so I had to adjust offsets accordingly, that could be due to the startup housekeeping code, for environment (vars, stack, etc.) initialization.  If you don't check you may find that you've overwritten your bootloader during this sort of development, as I don't see any bootloader memory space protection in the code (cursory inspection).
post edited by indisky - 2018/01/05 20:14:16
#19
qɥb
Monolothic Member
  • Total Posts : 3329
  • Reward points : 0
  • Joined: 2017/09/09 05:07:30
  • Location: Jupiter
  • Status: offline
Re: Bug on 8bit Bootloader 2.2.0 with 18F47K40 + Unified Bootloader hanging after Version 2018/01/06 16:47:37 (permalink)
0
Danno

checksum += EEDATA;

It was originally written to use 16 bit math but that proved to be inconsistent.  Instead we now do two 8 bit adds.

checksum += EEDATL;
checksum += (EEDATH << 8);

That is because you used the wrong SFR name.
If you look in pic1f1788.h, you will see that "EEDATA" is a synonym for "EEDATL"
// aliases
extern volatile unsigned char           EEDATA              @ 0x193;

to do a 16 bit addition, you should have used "EEDAT"
extern volatile unsigned short          EEDAT               @ 0x193;




This forum is mis-configured so it only works correctly if you access it via https protocol.
The Microchip website links to it using http protocol. Will they ever catch on?
PicForum "it just works"
#20
Page: 12 > Showing page 1 of 2
Jump to:
© 2018 APG vNext Commercial Version 4.5