Bootloaders and configs

[NickMu]

Hello everyone,

I just started collecting documentation on bootloaders and I remember reading somewhere that certain configs must be included in the bootloader.
Below is my set of configs and defines. I would like to match the bootloaders communication speed with my future Debug communication.
My question is which of them must go in the bootloader and which can be part of the new .HEX file to be loaded.



@__config_device_pic16f819
@__config_wdt_off
@__config_hs_osc
@__config_pwrt_on
@__config_mclr_off
@__config_lvp_off
@__config_protect_on
@__config_CCP1_RB2

DEFINE OSC 8

DEFINE DEBUG_REG PORTB
DEFINE DEBUGIN_REG PORTB
DEFINE DEBUG_BIT 6
DEFINE DEBUGIN_BIT 7
DEFINE DEBUG_MODE 1
DEFINE DEBUG_BAUD 38400

DEFINE ADC_BITS 8
DEFINE ADC_CLOCK 3
DEFINE ADC_SAMPLEUS 50
ADCON1=%01001110


CCP1CON = %00001100
PR2 = 15
CCPR1L = 0
CCP1CON.5 = 0
CCP1CON.4 =0


Any input on that will be greatly appreciated.

Nick

[tumbleweed]

My question is which of them must go in the bootloader and which can be part of the new .HEX file to be loaded
Put them all in the bootloader.

I'd be very leery of letting your bootloader reprogram config settings. If you get them wrong or things hiccup you can end up with a board that won't boot.

[NickMu]

Thanks, Tumleweed.
Are we are talking all configs only?
The defines can and will be programmed by the new .HEX file. True?

Nick

[tumbleweed]

Yeah, I'm talking only about the CONFIG settings.

Everything else is either a program or register setting that gets done at run-time, so you can always change these.

[NickMu]

Thanks again.
This makes it clear even for a beginner like me.

Nick

[HenrikOlsson]

The CONFIGs definitely needs to be in the bootloader code that gets programmed to the chip using a real device programmer.
You should not allow the downloaded "application" to change the CONFIG (besides it's not even possible on all PICs) because it might brick it. For example, if the bootloader is written for a board using a HSPLL oscillator running at 32MHz and the user, by mistake or unknowingly, downloads a piece of code that changes the oscillator CONFIG to INTOSC. This bricks the device and you need to reprogram it with a device programmer.

/Henrik.

[NickMu]

Thank you Henrik for the extra information.
In my case it should be simple since I’m using an old fashion chip (PIC16F819).
I’m stuck with quite a few of them in my inventory and I would like to make use of them.
I will include all the configs in the bootloader and I will make sure the new HEX will have none.

Thanks again,

Nick

[pedja089]

Hex isn't problem. You can have configs in hex, but application that parse hex file should ignore configs and send only program and eeprom to bootloader. I post simple bootloader code somewhere on forum.

[HenrikOlsson]

The 16F series isn't even capable of reprogramming their own CONFIG word(s). For example, on the 16F819, the CONFIG word is at address 2007h and the datasheet says

It is important to note that address 2007h is beyond the
user program memory space which can be accessed
only during programming.

It also says

Accessing a location above the
physically implemented address will cause a
wraparound.
So if you TRIED to write to the CONFIG word you'd actually write to another location possibly corrupting the program.

So yeah, you need to be carefull of what you're doing. I'm curious, the 16F819 doesn't have an UART, are you planning to use bitbanged serial for the download or are you going to inject the new firmware image in some other way (SPI, I2C)?

/Henrik.

[NickMu]

Hi Team,

Pedja089 I will search for your post, thank you.
Henrik, I will have a friend of mine, who knows more assembly than I do, helping with this project.
We are trying to make small changes, to fit our needs, to this project I found in my research:

http://pygmy.utoh.org/pikme/

Right now we are collecting as much information as we can to make sure we are taking the right path.
Thank you for your advices and interest.

Nick