werner
Starting Member
- Total Posts : 53
- Reward points : 0
- Joined: 2003/11/07 12:38:58
- Status: offline
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: - Start MCC
- Add UART1, Memory, Bootloader to the "Project Resources"
- 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
|
mbrowning
Just a Member
- Total Posts : 1123
- Reward points : 0
- Joined: 2005/03/16 14:32:56
- Location: Melbourne, FL
- Status: online
Re: Bug MCC bootloader PIC18F25K42
2017/09/27 03:47:17
(permalink)
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
|
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)
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
|
mbrowning
Just a Member
- Total Posts : 1123
- Reward points : 0
- Joined: 2005/03/16 14:32:56
- Location: Melbourne, FL
- Status: online
Re: Bug MCC bootloader PIC18F25K42
2017/09/27 08:26:35
(permalink)
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.
|
mbrowning
Just a Member
- Total Posts : 1123
- Reward points : 0
- Joined: 2005/03/16 14:32:56
- Location: Melbourne, FL
- Status: online
Re: Bug MCC bootloader PIC18F25K42
2017/09/27 08:31:48
(permalink)
By the way, I tried the bootloader with 56K42 selected. Maybe there's a difference with the 25K42.
|
mbrowning
Just a Member
- Total Posts : 1123
- Reward points : 0
- Joined: 2005/03/16 14:32:56
- Location: Melbourne, FL
- Status: online
Re: Bug MCC bootloader PIC18F25K42
2017/11/13 10:24:02
(permalink)
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
|
qhb
Superb Member
- Total Posts : 7477
- Reward points : 0
- Joined: 2016/06/05 14:55:32
- Location: One step ahead...
- Status: online
Re: Bug MCC bootloader PIC18F25K42
2017/11/13 18:39:50
(permalink)
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.
|
1and0
Access is Denied
- Total Posts : 8458
- 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)
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?
|
mbrowning
Just a Member
- Total Posts : 1123
- Reward points : 0
- Joined: 2005/03/16 14:32:56
- Location: Melbourne, FL
- Status: online
Re: Bug MCC bootloader PIC18F25K42
2017/11/14 09:15:50
(permalink)
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
|
Danno
Super Member
- Total Posts : 217
- Reward points : 0
- Joined: 2005/09/07 10:12:10
- Status: offline
Re: Bug MCC bootloader PIC18F25K42
2017/11/14 10:11:26
(permalink)
The dynamic keys ("magic numbers") eliminate any possibility of rogue code corrupting memory.
|
mbrowning
Just a Member
- Total Posts : 1123
- Reward points : 0
- Joined: 2005/03/16 14:32:56
- Location: Melbourne, FL
- Status: online
Re: Bug MCC bootloader PIC18F25K42
2017/11/14 12:01:22
(permalink)
Danno
The dynamic keys ("magic numbers") eliminate any possibility of rogue code corrupting memory.
Thank you very much for the clarification .
|
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)
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 ?
|
mbrowning
Just a Member
- Total Posts : 1123
- Reward points : 0
- Joined: 2005/03/16 14:32:56
- Location: Melbourne, FL
- Status: online
Re: Bug MCC bootloader PIC18F25K42
2017/11/29 13:04:13
(permalink)
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.
|
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)
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)
|
mbrowning
Just a Member
- Total Posts : 1123
- Reward points : 0
- Joined: 2005/03/16 14:32:56
- Location: Melbourne, FL
- Status: online
Re: Bug MCC bootloader PIC18F25K42
2017/11/30 11:00:16
(permalink)
The bytes transferred look good. I didn't have any problems with this and never looked at the datastream.
|
mbrowning
Just a Member
- Total Posts : 1123
- Reward points : 0
- Joined: 2005/03/16 14:32:56
- Location: Melbourne, FL
- Status: online
Re: Bug MCC bootloader PIC18F25K42
2017/11/30 12:58:08
(permalink)
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
|
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)
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.
|
mbrowning
Just a Member
- Total Posts : 1123
- Reward points : 0
- Joined: 2005/03/16 14:32:56
- Location: Melbourne, FL
- Status: online
Re: Bug MCC bootloader PIC18F25K42
2017/12/01 10:48:23
(permalink)
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.
|
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)
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.
|
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)
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.
|