NU32v2: The NU32v2 Serial Bootloader and PC Application

From Mech
Revision as of 05:50, 16 January 2016 by Lynch (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

THIS PAGE REFERS TO A PRE-RELEASE VERSION OF THE NU32 PIC32 DEVELOPMENT BOARD. FOR INFORMATION, SAMPLE CODE, AND VIDEOS RELATED TO THE PRODUCTION VERSION (2016 AND LATER), AND TO THE CORRESPONDING BOOK "EMBEDDED COMPUTING AND MECHATRONICS WITH THE PIC32 MICROCONTROLLER," VISIT THE NU32 PAGE.


Now that you have completed NU32v2: Starting a New Project and Putting it on the NU32v2, we can take a look at the process used to program the NU32v2 in more detail.

THIS PAGE IS OBSOLETE. PLEASE SEE THE UPDATED PAGE.

What is a bootloader?

No code is installed on the PIC32 when it arrives from the factory. To put a program on the microcontroller, a programmer is used. There are a variety of programmers available, including many from Microchip, the manufacturer of the PIC32, listed here. These programmers have many functions, including programming and debugging, with more functionality built into the more expensive programmers.

The NU32v2 can easily be programmed with any of these programmers, but has been designed to work with the PICkit 3, available for around $45. To avoid the expense of providing a PICkit with every NU32v2 kit, we have opted to install a bootloading program on the NU32v2. A bootloader is code that communicates with an application on a computer (in our case NU32v2_serial_bootloader), which takes the code that you have compiled and writes it to the memory on the PIC32.

By not including the PICkit with your NU32v2, we have lost the ability to do "in-circuit debugging", such as adding breakpoints and watches to your code as was done in the simulator. We will discuss alternative ways of debugging your code as the course progresses.

Understanding the bootloading process will increase your understanding of how the PIC32 functions. How the NU32v2 bootloader works is described in the following sections.

How the NU32v2 Bootloading Process is Structured

There are two important parts to the bootloader process. The first is what happens when you write code, and what the PC bootloader application does to prepare the code for the PIC32. The second part is how the PIC32 programs itself.

When you compile code in MPLAB, your C and H files go through several steps to turn them into instructions at specific memory addresses. The PIC32 starts at a specific memory address, and follows the instructions it finds. You can view the instructions the PIC32 will undergo in your code by going to View->Disassembly Listing in MPLAB. When compiled, this list of memory addresses and instructions is put into a file with a .hex extension. The hex file has a format that needs to be further interpreted before it can be put onto the PIC32.

After connecting to the NU32v2 in the NU32v2_serial_bootlader app, the hex file is converted to a binary file. In this process, a block of memory on the PC is set aside that is the maximum size of program memory on the PIC32. As each line of the hex file is read, the instructions are placed into memory addresses, which are not necessarily in order. After each line of the hex file is interpreted, the entire block of memory is sent over to the PIC32, in 512 byte packets. After sending all of the packets, the app closes.

On the NU32v2 side of things, the bootloader has already been programmed onto the PIC32 with a PICkit 3. The bootloader code is the first thing that runs on the NU32v2 when power is applied. The code sets up the configuration of the PIC32, to run at 80MHz, then it checks to see if the G6 pin is being pulled low. If it is not, it skips to another portion of memory, effectively leaving the bootloader code to run the last code that was put on the PIC32 with the bootloader. If G6 is being pulled low, it knows to remain in bootloader mode and get ready to receive a series of 512 byte packets, which it will write to memory.

The memory position that the bootloader jumps to is hard coded into the bootloader. When you code in MPLAB, the code does not necessarily start at that memory location. We use a procdefs.ld file to tell the compiler where to place our code so that it works properly with the bootloader. Using an incorrect procdefs, not putting procdefs in the correct file location, or not using it at all will prevent your code from running. Fortunately the bootloader is not capable of overwriting itself, so you should not be able to disable your bootloader by incorrectly using the procdefs file.

More specific details and source code are provided below.

NU32v2 bootloader source code

The NU32v2 bootloader project, written in MPLAB Assembly, with a "hello_world" type blinking LED example tacked on, is provided here: PIC32 code

This code sets up the configuration bits of the PIC32 note: the .s file does not show this, the bits are hidden in the project file. This should be changed so that the bits are set in the code. The code sets pin G6 as an input and enables an internal pullup resistor, which is why the NU32v2 board set in a breadboard does not require a resistor, as a normal switch circuit would.

In bootloader mode, the PIC32 sends 'v1.1' to signal that it is in bootloader mode, and it waits to receive characters from the serial port. An 'E' commands the bootloader to erase the program memory. This must be performed before every program is loaded. A 'B' command checks to see if the program memory is blank. If it is, an 'S' is returned, otherwise an 'F' is returned. A 'P' command lets the bootloader know that packets of 512 bytes are about to be sent to the PIC32. After the arrival of every packet, the PIC32 writes the bytes, in the order that they were received, to program memory. After not receiving a packet for ~1 second, the PIC32 considers the programming process complete and returns an 'S'. A 'V' character lets the bootloader know that the user would like to see if a hex file matches the current content of the PIC32. This process is standard in most bootloaders, but is not implemented on the NU32v2. An 'R' command resets the NU32v2 without needing to reset power. This effectively gets the NU32v2 out of bootloader mode.

NU32v2_serial_bootloader.exe source code

The NU32v2_serial_bootloader app source code, written in Processing, is provided here: PIC32 code.

The Mac OSX executable version is here: NU32v2 serial bootloader for OSX.

The NU32v2_serial_bootloader app allows the user to navigate to and select a .hex file. No other file type selection is allowed. The app also creates a button for each available serial COM port when the app loads, so the NU32v2 board must be powered up and the USB cable must be plugged in before the app is run.

After a hex file and COM port are selected, the app waits for 'v1.1' from the NU32v2. This signals that the NU32v2 is in bootloader mode and is ready to receive commands. The 'Program' button becomes active. When the 'Program' button is pressed, the app sends an 'E' to the board, to erase the current program on the PIC32. Then the hex file is converted to a block of memory, a 'P' is sent, followed by the block of memory. After sending the memory over, it waits for an 'S' from the NU32v2, signalling that the programming was successful. Then an 'R' is sent to reset the PIC32, the serial port is closed, and the app closes.

Other Information

The NU32v2 board has an FT232RL built on to allow for easy communication over USB with your computer using an RS232 connection on the PIC32 end. The communication is viewable as a "virtual com port" on you computer using the driver provided by FTDI. This chip provides an easy way for the PC and the NU32v2 to communicate, for bootloading, debugging, and general communication.