|
|
View previous topic :: View next topic |
Author |
Message |
kgng97ccs
Joined: 02 Apr 2022 Posts: 97
|
Using bootloaders |
Posted: Sat Jan 28, 2023 4:51 am |
|
|
I am using the PIC18LF46K22 MCU, MPLAB IDE v8.92, and CCS C compiler v5.113.
I am new to bootloaders, and I am trying to understand what a bootloader can do in comparison with what I can do in MPLAB IDE v8.92.
Now, I understand that if wish to be able to program the MCU in a finished product without opening the casing to access the programming connector on the PCBA, I can use a bootloader to do the programming through a serial port (a hardware or software UART).
I have tried the option of generating bootloader code using the project wizard in the CCS IDE.
Questions:
1. With MPLAB IDE (v8.92), I can compile a program, set the EEPROM table, and then load the hex file and EEPROM data (or an MCH file) into the MCU memory.
Question:
As there are normally two files that need to be programmed into the MCU – the hex file and MCH file, does a bootloader work in such a way that we have to load one file after the other, or is it that we have to combine both into one single hex file first and then load the combined file?
2. With MPLAB IDE, I can also read the MCU memory and export the hex file, with or without the EEPROM data embedded, and export (save) the EEPROM data into an MCH file.
Question:
Can a bootloader be set to do the same thing, that is, read back the contents of the MCU memory and then export them?
3. With MPLAB IDE, I can set the programmer (PICKit3, for example) to erase all memory before programming a hex file and an MCH file into the MCU, to replace the existing hex file and EEPROM data on the MCU.
Question:
Can a bootloader be set to do the same thing, that is, erase all memory before starting the programming?
I will appreciate any comment or advice. Thank you. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9229 Location: Greensville,Ontario
|
|
Posted: Sun Jan 29, 2023 6:42 am |
|
|
While I do use the 46k22, I've never used a bootloader with it. I dedicate the ICSP pins for exclusive ICSP use. To access ICSP and RS232, I'd use a DE-9 connector (5 or ICSP, 4 for RS-232).
A bootloader cannot 'erase all memory' then load the application program, otherwise it'd erase itself. That section of memory has to be protected.
Bootloaders have only been 'one way'..send data TO the PIC, not read data out of the PIC and send to the 'host' (PC). You can edit a bootloader to add this function though I suspect it'd be easier to simply edit the main() program to do this 'remote read'.
I don't know what an 'MCH' file is. A PIC with a bootloader has 2 programs. 1) the actual bootloader program, small and protected and then the application program what is normally called 'main()'.
CCS provides working bootloader programs, in the examples and drivers folders. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19520
|
|
Posted: Sun Jan 29, 2023 7:51 am |
|
|
The only file loaded into a PIC, is the hex file (or the same data as a .bin
file). The compiler does not generate a MCH file and one is not needed.
The only time I have met a MCH file is when using a Model Checking
program as a way of testing the code operation. There are a few other
things that use this file extension (there was an audio format that used
this), but none that I can think of that have anything to do with
programming a PIC....
MCH was used for exporting part of an EEPROM on the Old Pickit
software, but is not supported on the current releases. I think it was
a text format giving the location and data. Now standard Intel Hex
is used instead. The current versions of the MicroChip software no
longer support this format.
If you have an MCH file and want to store this, you would have to write
your own code to do this. It is not a format that would be recognised
by any standard PIC program and most definitely not by a bootloader.
Understand that a bootloader only writes code to the processor memory.
In the PIC, the internal EEPROM is mapped into the standard processor
memory map so this can be written by a bootloader.
However, if you want to modify one to write to an external EEPROM, I
would advise against this. It is always worth keeping the bootloader as
small as possible, and adding such an ability would be bulky. Much better
to add this as an ability to the main code in the processor, where it
can be maintained and updated by the bootloader. |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia
|
|
Posted: Thu Feb 09, 2023 3:26 am |
|
|
temtronic wrote: | ...
Bootloaders have only been 'one way'..send data TO the PIC, not read data out of the PIC and send to the 'host' (PC). You can edit a bootloader to add this function though I suspect it'd be easier to simply edit the main() program to do this 'remote read'.
This comment is a bit too general. My original non-encrypted bootloaders, serial, Ethernet, etc, did support the ability to read back the code as well as devices external to the PIC such as external EEPROMs. My encrypted bootloaders do not support any read back capability.
|
_________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia
|
|
Posted: Thu Feb 09, 2023 3:48 am |
|
|
Ttelmah wrote: | ..
Understand that a bootloader only writes code to the processor memory.
In the PIC, the internal EEPROM is mapped into the standard processor
memory map so this can be written by a bootloader.
|
A standard CCS bootloader may only write to program memory however that is an implementation choice. For example, I have bootloaders that will bootload not only the PIC but also devices external to the PIC such as EEPROMs, intelligent peripherals, and downstream processors, PIC or other processor variants.
Ttelmah wrote: | ..
However, if you want to modify one to write to an external EEPROM, I
would advise against this. It is always worth keeping the bootloader as
small as possible, and adding such an ability would be bulky. Much better
to add this as an ability to the main code in the processor, where it
can be maintained and updated by the bootloader. |
This is a matter of choice and resources. As a general rule, if the processor has a lot of free program memory, for example a PIC24/dsPIC or PIC32 with large program memory I would put the ability to modify the external EEPROM into the bootloader. This enables you to use a single image to bootload the system. My bootloaders support the ability to erase all the user allocated program memory space, if that is what the user wants to do, but the standard mode is that of an incremental bootloader which enables the PIC, to program as little as a single byte (even if it is a PIC24/dsPIC). This also means it can bootload an EEPROM if required (as little as a single byte), or not bootload the EEPROM while bootloading the PIC and/or other devices connected to the PIC.
A common of problem I have seen is where a bootloader has some dependency of code in the application program. A example that I have seen a few times is where an SD card bootloader is used and the application image is put on the card via the main applications downloading an image, via an Ethernet interface. If the application image has some problem that prevents the downloading of the image or the writing of the image to SD card then the device cannot be bootloaded. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|