SlotForum banner

Introduction to bootloaders and loading/updating firmware

9K views 5 replies 3 participants last post by  Chappy 
#1 · (Edited by Moderator)
Microcontrollers operate using embedded software (firmware) which contains all the instructions for the device to deliver its correct function... this firmware is usually in the form of a HEX application file.

Typically a brand new microcontroller has no firmware loaded. First step is often to load a HEX bootloader file. This is special firmware which enables a communications port on the microcontroller in turn to enable a simplified procedure for uploading of HEX application files via USB or BLE.

If the microcontroller has no bootloader then all application firmware (and bootloader firmware if required) need to be loaded using some form of in-system programming interface. This is different for each type of microcontroller.

1/ Microchip PIC microcontrollers
=========================

These Microcontrollers are often used without a bootloader. In this case, HEX application files are uploaded using a Microchip PICKit device which acts as a in-system programmer.

If a bootloader is also installed then the microcontroller firmware can be updated using an on-board serial port. However, many mid/low range microcontrollers do not have any on-board serial port. For those that do, a USB-to-serial interface is needed. Many current circuit designs include a CH340 IC to perform this function.

2/ Atmel AVR microcontrollers
=======================

These microcontrollers include the ATImega series such as ATImega328 which is used in Arduino project boards.

Usually a bootloader is uploaded and the application HEX files are uploaded via a USB-to-serial interface. Application firmware is typically developed in the ATMEL Studio7 design environment or the Arduino design environment.

The easiest method to upload the bootloader at the outset (if it is not already loaded) is to use an additional Arduino board programmed as an in-system programmer.

3/ Nordic Semiconductor microcontrollers
===============================

These include the Nordic Semiconductor nRF51 and nRF52 series of microcontrollers. Examples of each are the nRF51822 and nRF52832 respectively.

Application HEX files and bootloader HEX files can be loaded using a J-LINK interface. These are included in nRF development boards and they can also to used to program external nRF devices.

Application firmware is developed, typically, in SES (SEGGER environment studio). Then, using an appropriately installed bootloader, the application files are uploaded either via USB or over-the-air via BLE. In both cases a special zip file is created to implement the upload.

In general, the J-LINK interface is used during programme development and for initial upload of the bootloader. Then, application files are added/updated via USB or BLE.

With nRF51/52 series devices there is one extra detail... the devices need additional firmware to enable the BLE interface to function. This firmware is called the SoftDevice. So, the SoftDevice must also be in place if application firmware is to be added/updated by BLE.

===

I appreciate this may be if limited interest to many sfi members and visitors... but hopefully of value to anyone who is considering getting started with microcontroller firmware design and/or upload of design HEX files.

Meanwlhile I have tried to cover quite a lot in this brief post... and no doubt I have made some mistakes or perhaps I was unclear in places... If so, as always, please jump in with clarifications or corrections... all welcome...!

C
 
See less See more
#2 · (Edited by Moderator)
Just a couple of details I should have included to the previous post... The usual design environment for developing Microchip PIC firmware code is the Microchip MPLAB X IDE. Also, following the Microchip acquisition of Atmel in 2016, the latest versions of MPLAB can be used for development of AVR firmware code too. Possibly only as beta version at present for AVR.

https://www.microchip.com/pressreleasepage/avr-mcus-now-supported-in-mplab-x-ide

C
 
#3 · (Edited by Moderator)
Following on from Dr_C's introduction, I have written a basic guide or "How To" upload a firmware onto a PIC microcontroller. There are a few different ways to do it. Here is one of them. Hopefully it will be useful for someone.

My example is loading a firmware onto a "Microchip" brand PIC chip. In this example, it is for use in a custom made decoder board for use with Carrera. I did not write the code. The code that I am uploading is from a DIY project by Redlich electronics. (www.redlichelectronics.de) The process is the same or similar for many projects using a compiled program running on a microcontroller whether they are for slot cars, lap counters, washing machines, or any number of other applications.

Back to microcontrollers. There are a few manufacturers of microcontrollers suitable for hobbyists. These days the most popular ones are a package containing ROM, RAM, various registers, Arithmetic Logic Unit, Analog I/O, Digital I/O, and clocking functions to name just a few of the internals. Not many external components are required. Two popular families of microcontroller are Atmel and Microchip. Interestingly, Microchip recently acquired Atmel so the programming tools from Microchip have some added support for Atmel, but I am yet to try them.

The easiest way to program PIC chips is probably to write a program using C, in the manufacturer's IDE and using the programming, simulation and compiling tools though other languages and programming tools can be used. For this article, I will concentrate on uploading a pre-programmed firmware to a PIC chip.

To program the firmware we need a few things.

Physical Microcontroller to program the code into.

1) Cable and programming interface. Most modern ones use a USB port

2) Firmware upload tool (for this example I am using Microchip's MPLAB IPE, which is included with Microchip's downloadable MPLAB IDE. (IDE = Integrated Development Environment) In a previous life I used a program called ICPROG which was free and worked just great to upload compiled programs onto PIC chips.

3) Computer to run the firmware upload tool, with suitable interface (typically Serial port or USB or even Parallel port though this practice is probably uncommon now)

Here is a photo of three different programming interfaces, one self built using about $6 worth of parts, one Microchip Pickit3 clone (genuine worth about $50, clone worth about $20) and the last one is a USB ASP for programming Atmel, costs less than $10 though I haven't tried it yet. For this demonstration I am using the Pickit3 clone. Note that the clones can have mixed results, some examples are better than others, but I got lucky.

1a.jpg

We need to connect the cable from the programmer to the PIC chip. Often a project using a PIC chip will have a socket on board in order to easily connect the programming cable. For larger PIC chips we can plug the chip directly into a socket on a small board that is plugged into by the cable. In some cases this can be on board the programmer itself. But In this demonstration case, due to size constraints, the very small PIC chip is temporarily soldered directly to the cable via the very small board. This example required quite a bit of skill but the respective pins were numbered on the cable to avoid errors, pin one on the Pickit3 through to pin 5 go to these PIC chip pins respectively (need to consult the PIC data sheet in this case and wired directly to each PIC chip pin) If I was to redesign the PCB I would include a very small connector of some sort. The small sockets that take a flexible plastic ribbon cable, similar to those inside laptops and Slot.it decoders come to mind.

1) MCLR (Memory Clear enable line) (PIC pin 4 for this particular chip)
2) 5 5V (PIC pin 1 for this particular chip)
3) GND (PIC pin 14 for this particular chip)
4) DATA (PIC pin 13 for this particular chip)
5) CLK (Clock) (PIC pin 12 for this particular chip)

See image with the flying leads to go to the PCB

2.jpg

Now we open our programming software, in this case, MPLAB IPE. We select the correct PIC device, in this case, PIC16F1824. As well, we need to select the connected programming hardware tool, the Pickit3.

5.png

7.png

When we connect to the programming tool, we find we have some errors. This was due to the incorrect power option chosen. We need to go into a password protected configuration panel in order to change it. By default, the programmer assumes we are using power supplied by the project PCB. Often this is the case for In Circuit Serial Programming. But we want to use power directly from the USB powered programmer, its just easier for this project. So from the advanced menu, we select POWER and tick "Power Target circuit from Tool"

See screenshot:

Settings-Advanced-Power.png

Back in the OPERATE menu (button at top left) we select our pre-compiled hex file…

9.png

In this case, I can't remember if I have already programmed the PIC yet. So I choose "Erase"

11.png

Then I select "Program"

12.png

I get some good indication that all has gone well in the output panel. I decided to go and click on the verify button as well. However, I continue to get failed verify messages. This is unusual. I decide to try the programmed slot car decoder out anyway, and guess what? It works. So whatever is causing the fail verify is not affecting the operation of the decoder. Since I have previously programmed the same hex file into a bare chip without issue (in that case, without any circuitry on the board) I can only assume it is something to do with the circuit being non ICSP compliant. (there are a few requirements that the ICSP compliant circuit must meet, these are listed in the datasheets of each of the PIC chips that support ICSP (In Circuit Serial Programming)

Well that's it. Hope that's reasonably clear.

Slotspeed.
 
#4 · (Edited by Moderator)
I really should have mentioned at the start of my post above that the procedure described is how to load a firmware onto a PIC chip WITHOUT using a bootloader. For convenience, production microcontroller equipped devices often have a bootloader installed. As Dr_C mentions, this opens up some comms (some routines and a driver installed or even a small operating system that allows serial comms using one of the microcontroller pins) so that a firmware or code update can be loaded using more convenient methods for the end user. For example, a synthesiser that uses protocol translation over a midi port to upload firmware updates. Or a onboard slot car digital decoder equipped with wifi capability allowing firmware updates using a mobile phone app, or other domestic goods using a USB port to update the firmware loaded from a laptop. But for hobbyists, writing code for microcontrollers the easiest way is probably using methods similar to what I posted above.

(I have edited this to fix some grammar and sentence flow issues)
 
#5 ·
Slotspeed, thanks for your above posts... much appreciated.

One small question... does the problem you mention with the verify command occur only in cases where you download firmware with the firmware copy protection function enabled...? i.e. in cases when the chip does not allow the firmware code to be read back?

C
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top