Tuesday, 10 May 2016

Toying with PIC32MX150

For a project I'm toying with, I've needed a microcontroller with three comparators onboard. In this case, I've been playing with 28 pin PIC32 device, specifically the PIC32MX150F128B. Admittedly, this is mostly because I already have a few in the parts box! In a nutshell, you get 128K of FLASH, 32K of RAM, 5 PWM pins, 2 UARTs, 2 SPI/I2S interfaces, 20 GPIO pins, a charge time measurement unit and a 1Msps ADC with a 10 input mux, and no need for a crystal. In this post, I'm going to run through the PIC32-avrdude-bootloader, and MPIDE setup I needed to do to get this part up and running.
I'd decided to port some code from another project that was implemented in chipKit's MPIDE (chipKit's Arduino compatible IDE). In order to support MPIE, I need a bootloader and board configuration for the MX150. Fortunately, chipKit have made their bootloader source available over at github: PIC32-avrdude-bootloader, so all I need to do is add in any changes I needed. For MPIDE, I need to create three files - two that provide initialisation and port mapping, and one for handling the board. I've created another post that these are attached to, which you can find in this blog post.

The features

The PIC32-avrdude-bootloader configures the MX150 to use its internal oscillator and PLL to run at 40MHz, so you don't need any extra components. It also uses two LEDs, a program button, and serial I/O. Entry to the bootloader is done by holding the program pin high while resetting the MX150 device. This helps to prevent unexpected entry into the bootloader. One of the two LEDs is used to indicate the device is in bootloader mode, the other to indicate a code download is happening. Thus, programming the device becomes a matter of holding the program button down and resetting it, either in code or via the reset pin. Once in bootloader mode, avrdude can be used to upload the new code.

The Bootloader

First up is the bootloader. The MX150 has a separate 3K of bootloader FLASH, so you don't lose any of the 128K for your own use. However, making the bootloader fit  means you'll need to use MIPS16 code and the free version of XC32 won't emit MIPS16 code! While it is possible to fit a bootloader in using 32bit code, I wasn't able to shrink it down enough. The solution to this is to download the source to XC32, modify it and build it. There's documentation over at www.jubatian.com on how to do this. Once you've done this, pulling down the code from github gives you an MPLABX project, so you can easily open it in MPLABX IDE. The basics of this process seem to be:

  • Create a new config in the project.
  • Set the preprocessor macros to define your new board type.
  • Create a chip configuration file.
  • Add the configuration file to BoardConfig.h.

The first of these is fairly easy - use "Manage Configurations" (right click on project, select properties) in order to copy an existing config, such as "EXAMPLE_MX1" or "UDB32_MX2_DIP". When you edit the project config, make sure you go into XC32 -> xc32-gcc -> Preprocessing and messages -> Preprocessor macros and set a suitable macro name. This is then used to select the correct board type in the code, so your bootloader works with your setup. In my case, I chose to use "_BOARD_GJM_MX150_".

I also found it helpful to add a logical folder to hold the configuration files, as this wasn't present in the MPLABX project. This is as simple as right click on "Header Files" -> New Logical Folder, and then right click on the new folder -> Add Existing Item. I used the examples.h as a template configuration.

You'll need to change the "#if defined(_BOARD_xxx_)" to match the preprocessor macro you configured earlier, and then put the specifics for your setup in your config header. Typically this is going to be configuring the clock source and PLL settings. For me, I simply ensured the device was using the 8MHz FRC, and the PLL dividers/multipliers were set to provide a 40MHz processor clock. There are also some other features you can configure, such as which pin enters bootloader mode, which pins have the bootloader LED and download LED, and where the UART pins are mapped to. I ended up changing the port/bit for the two LEDs to put them where I wanted them, and shifted the program input pin along. If you want to remap the location of the UART pins, you can change them with the UARTMapRX() and UARTMapTX() macros. This is pretty much all you need to do other than compile the code and burn it on to the chip with whatever your favourite tool is.

Board config files

Having a working bootloader is a great start, but MPIDE (the chipKit Arduino-like IDE/API) needs a bit more information in order to know pin mappings etc. These are stored in the hardware/pic32/variants/<boardname> folder. The three files are:
  • Board_Data.c - customization data, basic pin mapping, any special setup for I/O.
  • Board_Defs.h - customization data, various I/O definitions, PPS mapping, virtual reset button.
  • boards.txt - contains settings for MPIDE to compile/upload code, including board type.
It is easier to modify an existing set of files than create a new one, so I grabbed the DP32 folder and cloned it into another folder. Knowing that the Board_Data.c file contains the analog and digital pin mappings,  I used this to order the pins in the same direction as the pinout of the chip.
I also modified Board_Defs.h in order to increase the number of available I/O pins from 19 to 21, and analog pins to 10. The DP32 file is targetted for an MX250, which has USB connectivity and therefore loses a few pins to this. I also made sure that the virtual program button was configured to match the bootloader, otherwise a sketch can never enter programming mode automatically. Towards the end of Board_Defs.h is the peripheral pin select (PPS) mapping. The MX150 (and MX250) devices have more peripherals than pins, so Microchip provided multiplexers in order to map peripherals to pins. The mappings in Board_Defs.h simply sets the default if you don't change them. A sketch can remap pins using the mapPps() function which connects a pin and a peripheral. If you are used to the PPS implementation on PIC24 devices, the PIC32 version comes with many more limitations.

The last piece of the puzzle is the boards.txt file. This will also need some alteration to suit your use. Firstly, a unique tag name is needed to replace existing "chipkit_DP32" tag. Secondly, the .build.variant tag needs to be altered to match the folder name you created. Lastly, you might want to update the .board tag for any specific code you might want to deal with later.

In theory everything here is fairly simple - it's just a little time consuming setting everything up. Let me know how you get on if you try this!

No comments:

Post a Comment