| View previous topic :: View next topic |
| Author |
Message |
soonc
Joined: 03 Dec 2013
Posts: 215
|
| CCS Bootloader not working as expected. |
 Posted: Sun Oct 21, 2018 3:12 pm |
 |
|
PIC18F46K42
Compiler: V5.081
Using CCS Bootloader code.
In the BootLoader main()
| Code: |
void main()
{
output_high(PIN_A3); // Keep alive
if( read_eeprom( BOOTLOAD_REQUEST ) == 0XBC )
{
output_high(PIN_E0); // UnIsolate BLE
load_program();
}
application();
}
|
All looks normal and debugging this BootLoader code works in that it reaches
load_program() and does it's thing when send a few lines of the program hex file.
In my program code I do include the mandatory
#include "..\BootLoader\bootloader.h"
I'm also using this to produce a combined HEX file.
#IMPORT (FILE="..\BootLoader\main.hex",HEX,RANGE=0:LOADER_SIZE)
#EXPORT (HEX,FILE = __FILE__"For_PRODUCTION.HEX")
CCSLOAD accepts it and when I program the chip it will run the code
if I click "RunStop Program" button in CCSLOAD.
As soon as I power down and power back up the program is not running.
Looking at the Bootloader .lst file I found this:
| Code: |
.................... application();
003C6: MOVLB 0
003C8: RCALL 0500
....................
and at 00500 I found the reason why the code hangs.
.................... void application(void)
.................... {
.................... while(TRUE);
*
00500: BRA 0500 // endless loop
00502: RETURN 0
.................... }
|
As usual I guess I'm doing something wrong!
Should I be replacing the void application(void) statement with a call to my program main() ?
Edit post after some more research:
There are fuses NOBOOTBLOCK BOOTLOCK that are not described in fuses.txt
I tried using #FUSES BOOTBLOCK
I also tried #FUSES BBSIZ1K
Anyway I declared the fuse and nothing changed the LOADER_SIZE remains at 0X4FF which is kind of strange as I added more code to see if it would change and it did not.
Edit#2
OK I can now see what's going on.
The code in the BootLoader
00500: BRA 0500
00502: RETURN 0
Gets overlaid with the code in the program.
00500: GOTO 8376 // the start of void main(void)
I'm suspect the combining is not being done correctly.
#IMPORT (FILE="..\BootLoader\main.hex",HEX,RANGE=0:LOADER_SIZE)
#EXPORT (HEX,FILE = __FILE__"For_PRODUCTION.HEX")
The stand alone program code runs fine, and I debugged the bootloader as described above... !
Any suggestion as to why the program code runs when started from the CCSLOAD but not when it power up ! |
|
 |
soonc
Joined: 03 Dec 2013
Posts: 215
|
| None of the Above ! But still not working |
| Posted: Sun Oct 21, 2018 9:52 pm |
|
|
Why is the code not working when unit powers up appears to be the Serial Port Tx Pin is not sending data.
When Debugging or starting the program from CCSLOAD it works everytime.
It's like the UART has not been initialized.
I tried:
| Code: |
void main()
{
set_uart_speed(0,BLE); // disable UART
// other initialization
set_uart_speed(115200,BLE); // Enable UART
...
}
|
It still does not send first time as it does with None Bootloader code.
The Program code uses this:
| Code: | #pin_select U1TX = PIN_C6
#pin_select U1RX = PIN_C7
#use rs232(baud = 115200, parity = N, xmit = PIN_C6, rcv = PIN_C7, bits = 8, stream = BLE, errors)
|
In the BootLoader I also have a serial port statement
| Code: |
#pin_select U1TX = PIN_C6
#pin_select U1RX = PIN_C7
#use rs232(baud=115200,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,stream=BLE, errors)
|
Loading old code which has no BootLoader stuff in it, the Serial works immediately upon power on.
Because the startup message did not appear I assumed the program code was not running.
After sending a few bytes to the uart things are working normally.
There has to be an issue between the declaration for Serial in the two sets of code.
Loading old code that has NO bootloader stuff just works every time. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19217
|
|
| Posted: Sun Oct 21, 2018 10:55 pm |
|
|
First, the application endless loop is not a problem.
This is the 'dummy' application that is replaced by the loaded code. Your
main code should be overwriting this when it is loaded.
I'd say fuses.
You need to have the option enabled to allow peripherals to be configured
more than once. Otherwise the bootloader configuration of the peripherals
will lock these so the main code can't then configure them. Normally
NOIOL1WAY. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
|
| Posted: Mon Oct 22, 2018 5:48 am |
|
|
| Ttelmah wrote: | First, the application endless loop is not a problem.
This is the 'dummy' application that is replaced by the loaded code. Your
main code should be overwriting this when it is loaded.
I'd say fuses.
You need to have the option enabled to allow peripherals to be configured
more than once. Otherwise the bootloader configuration of the peripherals
will lock these so the main code can't then configure them. Normally
NOIOL1WAY. |
NOIOL1WAY is not in the #device PIC18F46K42 file so compiler does not support it for this chip.
Thanks |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19217
|
|
| Posted: Mon Oct 22, 2018 5:57 am |
|
|
As I said. _Normally_.
Unfortunately, Microchip have the habit of changing fuse names between devices. On your chip the fuse is NOPRLOCK1WAY. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
|
| Posted: Mon Oct 22, 2018 6:06 am |
|
|
| Ttelmah wrote: | As I said. _Normally_.
Unfortunately, Microchip have the habit of changing fuse names between devices. On your chip the fuse is NOPRLOCK1WAY. |
Thanks I'm about to test... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19217
|
|
| Posted: Mon Oct 22, 2018 6:19 am |
|
|
| Remember the bootloader needs to have this fuse set, since it is this that actually determines the fuses. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
|
| Posted: Mon Oct 22, 2018 6:25 am |
|
|
| soonc wrote: | | Ttelmah wrote: | As I said. _Normally_.
Unfortunately, Microchip have the habit of changing fuse names between devices. On your chip the fuse is NOPRLOCK1WAY. |
Thanks I'm about to test... |
NOPRLOCK1WAY did not fix the problem. I still have to send a few bytes to liven up the UART! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19217
|
|
| Posted: Mon Oct 22, 2018 12:05 pm |
|
|
Some comments.
BBSIZE has nothing to do with LOADER_SIZE. BBSIZE tells the hardware what size block to protect from writing for the bootloader. LOADER_SIZE needs to be set by _you_ to the page boundary above the end of your bootloader.
You have to compile your bootloader, look at it's size in the listing, and then set LOADER_SIZE to the next erase page boundary above this, and recompile.
If you want to protect the bootloader, you then need to set the BBSIZE to the same figure.
You do realise, that when running from CCSLoad, the MCLR line is controlled for you by the programmer, while when running on it's own, this line will have to be operated by the hardware unless you are using NOMCLR. Also, that for the code to run properly, (BOOTLOAD_REQUEST) will have to be not 0xBC. Your 'load_program' code really needs to turn this off when it finished. Otherwise your code would potentially be loading every time you code boots, and the UART won't work till this has finished. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
|
| Posted: Mon Oct 22, 2018 7:20 pm |
|
|
| Ttelmah wrote: | Some comments.
BBSIZE has nothing to do with LOADER_SIZE. BBSIZE tells the hardware what size block to protect from writing for the bootloader. LOADER_SIZE needs to be set by _you_ to the page boundary above the end of your bootloader.
You have to compile your bootloader, look at it's size in the listing, and then set LOADER_SIZE to the next erase page boundary above this, and recompile.
If you want to protect the bootloader, you then need to set the BBSIZE to the same figure.
You do realise, that when running from CCSLoad, the MCLR line is controlled for you by the programmer, while when running on it's own, this line will have to be operated by the hardware unless you are using NOMCLR. Also, that for the code to run properly, (BOOTLOAD_REQUEST) will have to be not 0xBC. Your 'load_program' code really needs to turn this off when it finished. Otherwise your code would potentially be loading every time you code boots, and the UART won't work till this has finished. |
Thanks for the info about LOAD_SIZE and BBSIZE. I'll try it all tomorrow.
Yes I understand the potential for looping if BOOTLOAD_REQUEST is not Cleared. I've been using that scheme a lot and when the program code runs first thing is to check value of BOOTLOAD_REQUEST and if 0XBC then Set it to 00. The scheme works.
I'll report back on my progress. CCS were not able to help. |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
| LOADER_SIZE and BBSIZE |
| Posted: Tue Oct 23, 2018 8:20 am |
|
|
| Ttelmah wrote: | Some comments.
BBSIZE has nothing to do with LOADER_SIZE. BBSIZE tells the hardware what size block to protect from writing for the bootloader. LOADER_SIZE needs to be set by _you_ to the page boundary above the end of your bootloader.
You have to compile your bootloader, look at it's size in the listing, and then set LOADER_SIZE to the next erase page boundary above this, and recompile.
If you want to protect the bootloader, you then need to set the BBSIZE to the same figure.
|
I skinny'ed down the bootloader code so it is less than 512 bytes
and used BBSIZ512
in loader.c the compilers uses
| Code: |
#ifndef LOADER_END
#define LOADER_END getenv("PROGRAM_MEMORY")-1
#define LOADER_SIZE (getenv("PROGRAM_MEMORY") % (getenv("FLASH_ERASE_SIZE")) - 1)
#endif |
and LOADER_SIZE is set to 512.
Still the serial port needs a couple of byte to get it started.
I put a 1 wire printf() statement as the first line of the program main()
to prove the the program code starts at the correct place, and it does.
Changing BBSIZ512 to BBSIZ1K and setting LOAD_SIZE to 1024 does not change anything in the lst. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19217
|
|
| Posted: Tue Oct 23, 2018 11:10 am |
|
|
BBSIZE, has _nothing_ directly to do with the size of the bootloader!....
It is a specification for a block to be protected from writing. You can make your bootloader larger or smaller than this. However if you want the bootloader protected, you would then set this to match the actual size of the loader. However at present all it will do is get in the way....
The way to specify the loader size, is simply:
| Code: |
//Processor include
//fuses
//clock
#define _BOOTLOADER //for the bootloader
#define LOADER_END 0x7FF
#include <bootloader.h>
|
All you need to do is set the _LOADER_END_ value before loading bootloader.h. This tells it how large your bootloader is. LOADER_SIZE, is set _from_ this.
There is nothing called 'LOAD_SIZE'.
The printf really proves nothing. The code in front of main, is the variable initialisation, constant arrays, and the delay routines. The code can run through this and reach the main even if this is damaged... |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
| Problem Solved. |
| Posted: Tue Oct 23, 2018 12:53 pm |
|
|
As I never got the Copyright message when booting up, I assumed the UART was not sending. Fact is it was sending but using a garbage Baud Rate because the system clock had not yet stabilized.
When I eventually sent two commands and got normal responses I started to be suspicious and captured the TX pin on my scope and found the garbage Baud Rate. SioW was not displaying the Startup message because the Baud rate was garbage...
This chips has several PUT values for the fuses.
#FUSES PUT_64MS
Problem fixed.
Thanks for all the help.
At least it was not a complete waste of time for me as it gave me a better understanding of how the BL works. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19217
|
|
| Posted: Wed Oct 24, 2018 12:57 am |
|
|
So, when you were testing the code without the bootloader, you were using different fuses.
Wrong.
When testing you always need to keep as many factors as possible 'constant' so you can tell where the problem genuinely is....  |
|
|
soonc
Joined: 03 Dec 2013
Posts: 215
|
|
| Posted: Wed Oct 24, 2018 10:03 am |
|
|
| Ttelmah wrote: | So, when you were testing the code without the bootloader, you were using different fuses.
Wrong.
When testing you always need to keep as many factors as possible 'constant' so you can tell where the problem genuinely is.... |
The Fuses in the bootloader and Program Code Main were the same.
They changed for various attempts at solving the issue but always the same.
The Fuse was NOPUT... in both.
It worked fine if Not using bootloader code. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
