8-bit Bootloader from Microchip

[flotulopex]

Hi All,

I've heard about bootloaders for the last 14 years but never tried myself because I didn't have really the need for it.

Today, still the same, no real need...but I'm curious to now how it works

I found this on Microchip's site:https://www.microchip.com/promo/8-bit-bootloader

Is it something I "can" start with or is it already a "complicated" tool that will give me some more sleepless nights until I give up?

If it is worth a try, can anyone give me the "initial kick" to get a good start? I mean, what do I need (tools, programs, whatsoever...) to make things start the right way?

[flotulopex]

I really need some basics on bootloaders because the more I read about this subject, the more I'm getting lost...

Please correct me and I apologize for the the order of my questions - there is none :

1.- a bootloader is a small piece of HEX code that I flash into the PIC via (i.e.) a PICKit2 or 3 programmer like any other (simple) program I make. Correct?

2.- once the bootloader is in the chip, I must upload my programs in HEX format via serial com (if the bootloader is made for serial com) to the PIC using its hardware UART. Correct?

3.- the bootloader code has to be adapted to each particular chip I'm using - I don't know in details "what" and "how" but it seems to be always about crystal speed, fuses (configs), bps and memory location, etc. Correct?

4.- what is a software like TinyBootloader exactly doing? Is it only there to serially upload a program into the PIC or does it generate the bootloader code or what?

5.- lots of videos show the use of MPLAB to "implement" bootloaders; is it mandatory?

6.- "self programming" has nothing to do with a PIC that can write to its program memory on runtime (i.e. WRITECODE). Correct?

Thanks in advance.... for your patience

[richard]

1.- a bootloader is a small piece of HEX code that I flash into the PIC via (i.e.) a PICKit2 or 3 programmer like any other (simple) program I make. Correct?

yes

2.- once the bootloader is in the chip, I must upload my programs in HEX format via serial com (if the bootloader is made for serial com) to the PIC using its hardware UART. Correct?

not really , your hex code file data is sent by the bootloader program in a serial format to your pic using its hardware UART

3.- the bootloader code has to be adapted to each particular chip I'm using - I don't know in details "what" and "how" but it seems to be always about crystal speed, fuses (configs), bps and memory location, etc. Correct?

yes

4.- what is a software like TinyBootloader exactly doing? Is it only there to serially upload a program into the PIC or does it generate the bootloader code or what?

see q2 , it does not make any code

5.- lots of videos show the use of MPLAB to "implement" bootloaders; is it mandatory?

the pic receiver code for bootloaders is generally asm code and compiled in mplab with mpasm , the umc bootloader is a variation

6.- "self programming" has nothing to do with a PIC that can write to its program memory on runtime (i.e. WRITECODE). Correct?

WRITECODE is small subset of a pic's self programming capability, pics that cant self program cannot bootload

[flotulopex]

Thanks Richard.

I'm getting somehow out of the fog but I still need more info...

2.- once the bootloader is in the chip, I must upload my programs in HEX format via serial com (if the bootloader is made for serial com) to the PIC using its hardware UART. Correct?
not really , your hex code file data is sent by the bootloader program in a serial format to your pic using its hardware UART

2a.- is my program (not the bootloader) going to be in HEX format or does it have to be generated in some other format?

2b.- does it mean that once the bootloader sits inside the chip, I need a particular terminal software to upload the program into the chip or does any terminal software do the trick?

4.- what is a software like TinyBootloader exactly doing? Is it only there to serially upload a program into the PIC or does it generate the bootloader code or what?
see q2 , it does not make any code

4.- what is then so "special" with this software (and all other particular bootloader software) if it is not generating or supplying the "bootloader code"? I thought it was providing THE bootloader code for some specific chip one would need.

5.- lots of videos show the use of MPLAB to "implement" bootloaders; is it mandatory?
The pic receiver code for bootloaders is generally asm code and compiled in mplab with mpasm , the umc bootloader is a variation

5.- I'm using the MCS editor with MPASM compiler. As far as I now, I can (I truly can't since I don't know assembler ) insert ASM code into my PICBasic programs. If this is correct, can I copy/paste à bootloader code in MCS editor an program my chip like I would do for any other program?



7.- would it possible to paste a bootloader code on the top of my program and flash it into the chip (like an image file for further mass programming purpose)?

[richard]

2a.- is my program (not the bootloader) going to be in HEX format or does it have to be generated in some other format?

you do nothing different other than put #define loader 1 [or whatever the syntax is ]

2b.- does it mean that once the bootloader sits inside the chip, I need a particular terminal software to upload the program into the chip or does any terminal software do the trick?

only if you want to use and keep the b-loader , if you use another programmer the b-loader will be erased

4.- what is then so "special" with this software (and all other particular bootloader software) if it is not generating or supplying the "bootloader code"? I thought it was providing THE bootloader code for some specific chip one would need.

the pc part of the bootloader prgm reads the hex file and parses in into blocks to be serially transferred into the chip , the already loaded pic component of the bootloader knows how to read the data and then write it into the pic codespace when the pc component is detected
bootloaders all do the same thing , none of them do it the same way

5.- I'm using the MCS editor with MPASM compiler. As far as I now, I can (I truly can't since I don't know assembler ) insert ASM code into my PICBasic programs. If this is correct, can I copy/paste à bootloader code in MCS editor an program my chip like I would do for any other program?

you only need the assembler to create the pic component , its a separate process only done once, the bootloader cares not who or what makes the hex file to be loaded

7.- would it possible to paste a bootloader code on the top of my program and flash it into the chip (like an image file for further mass programming purpose)?

totally unnecessary


http://tinypicbootload.sourceforge.net/
look at firmwares microchip pic16

[flotulopex]

Thank you Richard.

I'm going to have a look at the link you posted and try before asking more

[flotulopex]

Since I own MCSP (I forgot the included bootloader....), I give it a try.

I'm using a PIC18F2431 and here is my blinky:

DEFINE LOADER_USED 1

#CONFIG
 __CONFIG _CONFIG1H, _OSC_IRCIO_1H & _FCMEN_ON_1H & _IESO_OFF_1H
#ENDCONFIG

OSCCON  = %01100000 ' set INTRC to 4 MHZ

MAIN:
    Toggle PORTA.7  ' LED
    pause 500
    goto MAIN
END

What did I do then?

1.- I flashed my PIC via PICKit3 with le bootloader file from MCS ("18F2431_04.hex") and checked if it was really there; yes, it is in the PIC!

...the rest of the code is way down in the memory - but it is there!


2.- I realised this serial programming circuit:

My FTDI cable is plugged in my PC and is "COM3".


3.- I launched the Loader from within MCSP and loaded my "Blinky_18F2431.hex" file previously compiled:



4.- When I clic on "Program" in the Loader, I get following message:



Since I couldn't make it work, I tried to connect a button between MCLG and GND to make a "manual" reset but it doesn't help either.

There seems to be nothing to configure in the FTDI chip to activate/deactivate the RTS pin so I admit it is working.

Any clue what I'm doing wrong or missing?

[HenrikOlsson]

When using the MCSP bootloader you have to understand that it is the CONFIG of the bootloader .hex file that you initially flashed into into the PIC that's "in play" and not the CONFIG in your source file. The boorloader will completely ignore whatever CONFIG you include in your source file.

IIRC the bootloader(s) are setup for external x-tal. Your schematic indicates that you don't have one connected and your code indicates you're expecting the PIC to run on its internal oscillator - which it won't IF the bootloader dictates otherwise.

Some PICs allows you to change primary osillator at runtime but I don't think the old 2431 is one of them.

/Henrik.

[flotulopex]

Thank you so much Henrik!!!

I adapted my code to free up the OSC pins, put a crystal and 2 capacitors and....it worked instantly!!

May I kindly ask you how I can "create" or "modifiy" the bootloader file to adapt it to my needs please?

[richard]

if you own mcs plus then its in this folder / if not you won't have the build files

C:\Program Files (x86)\Mecanique\MCSPX\MCLoader\umc\documentation

its an adventure not worth the trip in my experience

[flotulopex]

its an adventure not worth the trip in my experience

What do you mean exactly if I may ask? Is customizing such a file overwhelming?

But if one has the need of a system that must be "updateable" without a programmer, what would be the alternative?

[richard]

What do you mean exactly if I may ask? Is customizing such a file overwhelming?

every chip type needs its own loader asm file ,every different config of that chip may need it own version, pll use brings another set of issues
newer chip types aren't supported at all . the included device files are barely populated and need work to add chips.
its not particularly difficult just ugly and untidy

But if one has the need of a system that must be "updateable" without a programmer, what would be the alternative?

use C in mplabx it has a built in bootloader for mcc supported chips if you really want one. i prefer to just add an icsp socket.
for sold to customer products its a return to base for updates.
better still these days do everything on a esp8266 and use ota to update [no wires no problem all via wifi]

[Ioannis]

My advice. Forget all about bootloader. It just not worth it.

With ICSP you have:

1. Better programming speed
2. Safer and works with ALL chips, not only with those that a bootloader exists.
3. No use of UART
4. Free to use any CONFIG you want
5. Free to use any clock speed you want

Once I used bootloader but after using ICSP (with Pickit 2, Pickit 3 and ICD3) never used it again.

Ioannis

[flotulopex]

Thank you Richard and Ioannis, I appreciate your advice.

I've never tried ISCP either so let's discover this one

[Ioannis]

After using it with the Microchip IPE (which is not very good design IMHO), I found this one http://www.pickitplus.co.uk/Typesetter/ for my Pickit2 and Pickit3.

It is a stand alone application that is maintained and updated on a regular basis by Evan Venn, a very helpful person.

Using ICSP is very easy. You connect through 5 pins the MCU (MCLR, +Vdd, GND, CLK and DATA) either permanent while developing or momentarily only for programming and hit WRITE and you are ready.

Only take care not to load too much the CLK and DATA lines (PortB.6 and PortB.7) which leads to programming failure.

And best of all, you can even supply with 3.3 or 5 volts the MCU through the Pickit. I had successfully supplied a circuit with 4x20 backlit LCD.

Ioannis