CCS:: View topic - Feedback wanted - Multiboot loader development CCS does not monitor this forum on a regular basis. Please do not post bug Reports on this forum. Send them to -:: Author Message asmallri Joined: 12 Aug 2004 Posts: 1536 Location: Perth, Australia Feedback wanted - Multiboot loader development Posted: Sun Apr 12, 2009 8:27 am I am developing a multiboot loader for use with Microchip controllers and am soliciting feedback on the feature set. The basic idea is that PICs with large amounts of program memory can hold more than one image and a mulit-boot loader can be used to select the desired image and to load additional images into program memory. The bootloader has three elements, the base bootloader code, a bootloader parameter block and a boot image selection mechanism. The bootloader parameter block is common to our current range of bootloaders but is extended to support multiple images.

1. Free Boot Loader
2. Pic Serial Bootloader Ccs

Information in the parameter block includes the image ID, image storage location in program memory, image reset vector (not applicable to PIC32) and other information depending on the type of bootloader (serial, Ethernet, SPI etc). Application programs are compiled as per normal but with a lower defined upper Program memory limit via the linker script (e.g. Microchip compilers) or via #defines in the source (e.g. CCS Compilers). Because the bootloader and each application are effectively ships-in-the-night, all PIC resources such as RAM, peripherals, interrupts etc are completely available to the active application.

• This workshop demonstrates how to use the Boot Loaders in the SimpleLink™ MSP432E4 Software Development Kit (SDK). The Boot Loader database provided as part of the SDK can be used to develop custom Boot Loaders over the serial interfaces of UART, I2C, SSI or Ethernet to download application firmware to the MSP432E4 device.
• CC Linux Revision: 1.4.0 Software Guide 2018-11-19 www.crosscontrol.com 2. It is possible to connect to the boot loader through a debug serial port with special equipment attached to the device. The reason for connecting to the boot loader would be for debug purposes.

All applications are compiled to execute in the same memory region. Because the bootloader code and all images are 'ships-in-the-night' they can be any mix of programming languages. The boot image selection can be made via one or more of the following approaches, external PIC pins, External/Internal EEPROM contents, PC programmer application, application modification of an entry in the PIC parameter block. When an new image selection is made, the bootloader overlays the selected image onto the program memory space where the application was originally intended to be executed. Later PIC generations have more Program memory available. For this reason the multiboot loader would most likely be implemented in assembler for PIC18F processors (leaving more PGM Memory for the applcations) and in C for PIC24/dsPIC and PIC32 mcrocontrollers. Some PICs have embedded EEPROMS.

There are a number of ways multiboot EEPROM support could be handled. The EEPROM image associated with an application image could be stored in program memory along with the application image and stored to EEPROM when the bootloader selects the image to execute. The EEPROM could be partitioned, similar to the way program memory is partitioned, such than an application appears to have only a subset of EEPROM space available. The EEPROM could be left unchanged, a separate command could be used to instigate the overlay of the stored EEPROM image onto the EEPROM. Feedback wanted: 1. Do you see demand for a multiboot feature? Would this be a feature you would incorporate into a commercial product?

Would this feature be of benefit to the hobbyist? What EEPROM mechanism would be most useful?

Do you care what programming language the bootloader is written in? What is the priority of bootloader interface type you would use with this class of bootloader (Ethernet, serial, SPI, other) 7.

Join GitHub today. GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.

Which image selection mechanism would you prefer? General comments Thanks for your time. Regards, Andrew Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! Rohit de Sa Joined: 09 Nov 2007 Posts: 282 Location: India Posted: Sun Apr 12, 2009 8:23 pm Hey Andrew, My profile, so that you can put the answers in the correct perspective: I'm a senior undergraduate doing mechanical engineering in India. Electronics is a hobby. Electronics experience - 6 years.

Experience with PICs - 4 years+ (10, 12, 16, 18, 24 series). And my answers in order: (a) I currently don't see the need for a multiboot system. Whenever I use a bootloader, the fresh code is taken off the computer. I don't think multiple images are very necessary. Maybe storage of images on external EEPROMs would be useful. (b) I'm still a student, so the answer is - no, not yet, at least:-).

(c) I suppose it may. Answer (a) (d) I have not yest come to the stage where I regularly require to use large swathes of internal EEPROM. I use the EEPROM only to store some user modifiable flags or configuration settings. So as long as at least 10 bytes of internal EEPROM are available for user application, I think the internal EE approach will work. But I guess if you would like to put multiple images then an external EE would be the way to go. (e) Preferably well documented/commented assembly or C so that modification is possible (that is, if you are planning on making your code open source:-) ) (f) Bootloaders I have worked with, beginning with the most often used one - USB (on supported chips), Serial, SPI, Ethernet, others are just modifications of the physical layer of the serial bootloader (bluetooth, IR) (g) Didn't get the question (h) I don't know how easy this is going to be, but 'relocatable' images may be of use.

Free Boot Loader

On chips with limited resources depending on whether the user requires more program memory, or more EE, you could shift the code to either the PGM, internal EE or external EE. Maybe you could whip together a small batch file or a Python script, in which the user selects the bootloader entry mechanism (USB, Serial, SPI, etc), followed by the first image, and where he would like it located, then the next image and its location, and so on. The batch file would generate a '.hex' file with all the bootloader code, which could simply be burned onto the PIC. A help file would also be generated, telling the user which memory locations he should stay out of.

Rohit Display posts from previous: - All times are GMT - 6 Hours Page 1 of 1 Jump to: 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.

This bootloader was developed from C and assembly code originally distributed by Microchip (see the application note. I have tested the bootloader on the p24FJ64GA002, p24HJGP202, and p24HJ32GP202 targets. The bootloader window application is a.NET application and the supplied executable found in the has been tested with WinXp, Vista, and Vista64. The supplied executable has been reported to be incompatible with WinXP64; but recompiling from the source may work (untested, the source files are supplied in the archive).After unpacking, you will have the following directories:. bootloader/pic24dspic33bootloader.X/ - Source and MPLAB project for the PIC24 and dsPIC33 series bootloader firmware code to be loaded on the target processor. You will probably have to modify this source to map the UART TX/RX pins to your desired target, as well change to your desired starting baudrate and clock configuration. The current code uses RB10 for RX, RB11 for TX, and the internal oscillator @ 40 MHZ FCY (PIC24H).

If you compile to a new target, please be aware that you have to provide a customized linker file for the bootloader so that it starts at location 0xC00, and not the default of 0x200. Some linker files for the bootloader are in this directory. bootloader/winbootldr/ - Source for windows bootloader application (Visual Studio 2005). hex/ - Some bootloader hex firmware files for some targets built from the pic24dspic33bootloader.X/ source.

lkr/ - these are linker files for different processors that are used when building your application to be compatible with the bootloader. Look at the comments inside the linker files as well as the AN1094 application to see the changes from the standard linker files. Be careful when modifying linker files for the PIC24F family; you must change both the code origin and length fields (see the sample PIC24F linker file provided and the comments). bin/ - Contains a winbootldr.exe file that is the Windows bootloader application.

To install copy this.exe and the devices.txt file to some target directory. The devices.txt file must have an entry for your target processor; the comments at the top of this file indicate the format of each record.

If you processor is not currently listed, simply use a text editor to add it. Installation of the Windows bootloader application Copy the bin/winbootldr.exe and bin/devices.txt to a target directory and try executing winbootldr.exe. If it does not run then try installing the latest.NET runtime from Microsoft as this is a.NET application.NET Requirements You need at least.NET 2.0.XXX or above runtime framework installed.

Pic Serial Bootloader Ccs

You can download this by searching for “.NET framework”. If you do not have at the.NET runtime installed, then you may get this error message. Using the bootloader This assumes you have a PIC24 or dsPIC33 target programmed with the bootloader firmware, and connected to your PC via a serial port.

If you have the RTS# line the USB-to-Serial cable connected to MCLR#, then the RTS# checkbox pulls MCLR# low when checked, and MCLR# when unchecked. In the bootloader application:. Choose the appropriate COM part and baud rate (the default baudrate in the bootloader firmware is 57600, the bootloader firmware does not autobaud). Click on the port checkbox to open the port. Use the 'HexFile' button to browse to a hex file for download. The Hex file must be have been compiled using a modified linker file such as those found in lkr/.

Our default test program is the chap8/reset.mcp project. The project assumes a PIC24HJ32GP202 processor and uses the linker file lkr/p24HJ32GP202bootldr.gld file. Downloading a program via Power cycle or MCR#: Cycle power or assert MCLR# to your target PIC24H/F; when power is applied or reset is released, you have about 2 seconds to press the 'Program' button in the Bootloader window.

If the bootloader is able to establish a connection, you will see your hex file downloaded to the target device. Downloading a program via “MCLR# and Prgrm' button: If you have the RTS# or DTR# line of the USB-to-Serial cable connected to MCLR#, then press this button to program. The bootloader will pulse the MCLR# input via RTS# or DTR# (both are pulsed), and then download the program.

The upper part of the bootloader application window shows what is happening on the serial port, you can use the 'Send' button to send data in the type-in field to your application via the serial port (the 'Send& n' sends the data with a new line). If the bootloader does not work. If the bootloader hangs after programming the first block, be sure that you have compiled the bootloader firmware so that it starts at 0x400 and not 0x200 (if it starts at 0x200, it will erase itself). If the bootloader complains that the device is unrecognized, add your target device to the 'devices.txt' file.

If the bootloader does not connect all, this could be a multitude of problems on the target side - your clock is not configured correctly, the baud rate is wrong, the TX/RX pins are configured incorrectly. To test this, just connect a dumb terminal program to the bootloader, and modify the firmware to put out a 'hello' message to see if your serial port is working correctly. The Bootloader Firmware and Persistent Data The bootloader's firmware stack pointer is initialized around 0x0E50 the last time I checked. This means that if your application has persistent data above that point, it may (will) get stepped on.

The bootloader's static data buffer that takes up the space before this is persistent, so any of the application's persistent data in this space will be safe. If the bootloader loads a program, then it sets the POR bit to simulate a power-on reset for the new program; this way if your program checks the POR bit to initialize persistent data you will get correct behavior. The Bootloader and Configuration Bits Configuration bits on PIC24H/PIC24F devices determine things like initial clock source selection, watchdog timer timeout, etc.

The file 24h24ftarget/pic24configbits.c file sets the configuration bits for the bootloader firmware, currently the bootloader uses the internal FRC +PLL as the initial clock source (16MHz FCY for PIC24F, 40 MHz FCY for PIC24H). Feel free to modify these config bits to whatever you need. For PIC24H devices, configuration bits are located in a special area of flash memory. For PIC24F devices, a packed version of the configuration bits are located near the end of the last page of flash memory, and at device reset time, these are unpacked into the configuration registers.

Configuration bits can also be specified in the application hex file that is downloaded by the bootloader. Before version 0.19, the bootloader and associated firmware had the following behavior in terms of configuration bits programming if the configuration bits were present in the hex file. PIC24H devices: configuration bits always programmed if present in the hex file. PIC24F devices: configuration bits were never programmed, the last page of flash memory for PIC24F devices was not programmed (1 page is 64. 8 instructions = 512 instructions). Beginning with Version 0.19, there is now a checkbox that allows control of configuration bit programming if they exist in the application hex file.

This checkbox setting is only used if the Version 2.0 or better of the firmware is loaded (the bootloader now checks the firmware version during programming, and if it lower the Version 2.0, then the old behavior for configuration bit programming is used). WithVersion 0.19 and later, if the configuration bit programming is enabled and configuration bits are present in the application hex file, then the configuration bits are programmed for both PIC24H and PIC24F devices. If configuration bit programming is disabled, then configuration bits are not programmed for either PIC24H or PIC24F devices. For PIC24F devices, this has the nasty side effect of not programming the last page of flash memory (the last 512 instructions of program memory), so make sure that you do not have any program code there.

The reason to disable configuration bit programming is that the bootloader may become inoperable if the application has incorrect configuration bit settings (i.e. Specify an external crystal as a clock source and there is no crystal present). I would recommend for PIC24H devices to set the bootloader configuration bits the way you want them in the bootloader firmware by editing 24h24ftarget/pic24configbits.c, and then disable configuration bit programming when downloading applications. This way, you cannot kill the bootloader via incorrect configuration bits in the application. For PIC24F devices, there is not a good solution.

If you enable configuration bit programming, then you may kill the bootloader if the application has incorrect configuration bits. If you disable configuration bit programming, then the last page of flash memory is not useable as the bootloader aborts programming if it detects program instructions (and not configuration bits) on the last page of flash memory. The choice is up to you. Comments Send comments to Bob Reese (reese@ece.msstate.edu). Version 0.25, Feb 3 2009 Now includes the. Version 0.20, Nov 23 2008 Fixed a problem in the configuration bit programming - configuration bits were still being programmed even if the check box for disabling this was checked. A side effect was that configuration bits could be corrupted in this case.

Also, verification was fixed - it was indicating a match even if the program contents did not match. Version 0.19, October 9 2008 Added support for enabling/disabling configuration bit programming, see the section titled “The Bootloader and Configuration bits”. The changes affected both the GUI and the firmware. Also, the COM port, baud rate, and other settings are now saved on exit in the local applications folder, and restored when restarted. Version 0.18, October 7 2008 Fixed a problem with the configuration bits sometimes getting corrupted by the verification process. Version 0.17, September 3 2008 GUI changes: Added verification of program memory after programming, and a check box for enabling logging (the log file is named bullyBootloaderLog.txt is in the same directory as the bootloader executable).

Version 0.16, Aug 19 2008 Firmware now sets the POR bit if a program is loaded, this way a new program thinks that a POR has occurred and the C runtime initializes persistent variables. Also, added a the RTS#(MCLR#) check box and the 'RTS# and Prgrm' button to the bootloader. Version 0.15, Jul 13 2008 Added firmware support for Explorer16/100pin board (see 24h24ftarget/Explorer16100pbootloader.mcp). Fixed problem with bootloader GUI not detecting location clash between user application and bootloader firmware - bootloader GUI will not load application code if a clash exists).

Version 0.14, Jun 5 2008 If no serial ports exits, handle gracefully. Version 0.13, May 27 2008 Added a 'small RAM' flag to devices.txt to flag devices with less.