chipKIT® Development Platform

Inspired by Arduino™

Programming PIC32MZ2048ECM144

Created Wed, 08 Feb 2017 19:54:22 +0000 by rs2845

rs2845

Wed, 08 Feb 2017 19:54:22 +0000

Hi,

I have seen that there's no "official" board using the PIC32MZ2048ECM144, but what would be the steps to take in order to write programs with UECIDE?

For the MX chips I use, I currently manually flash the hex using a PicKit3, but the parts I use are actually supported. This PIC32MZ2048ECM144 doesn't seem to be.

Would I need to write some special pin map or config file for this chip?

majenko

Wed, 08 Feb 2017 20:21:32 +0000

The chip itself should be supported fine, but there are a few caveats I myself had to work through recently with an MZ board.

First, if you can, use the bootloader. You will have to compile your own custom version of it to suit your board, and you have to have a UART interface to program through. If you to that you can then use the linker script for the WiFire board and it should work.

https://github.com/chipKIT32/PIC32-avrdude-bootloader

If you can't, or really don't want to, use the bootloader then a custom linker script that doesn't use the bootloader will be needed. Now I spent some considerable hours the other day working out how to do this - it's really not a simple task at all. My results (which I think work) are here: https://github.com/UECIDE-Boards/mchp-curiosity-mzef - you are free to take that as a base and build on it. I haven't finished the definitions for the board yet though.

And that's the second part: you need to make a set of board definition files. Use the WIFire as an example to base yours on - and be sure to keep the special ADC files for the chip in there - otherwise it will all break...

You can read about the board definition files here: http://chipkit.net/wp-content/uploads/2013/11/chipKIT-MPIDE-Board-Variant-Mechanism-Rev-A.pdf - ignore the bits about "boards.txt" - that is different in UECIDE. Use the board.txt from my repo above as a template for how to format it.

If you're not using the bootloader you will need the microchip debugger plugin for programming from UECIDE which uses the file mdb.jar from your MPLAB-X installation. Make sure you have the newest version of MPLAB-X so as to get the best support from that program.

rs2845

Thu, 09 Feb 2017 06:05:43 +0000

Thanks for your reply, i’ve cloned your linked repositories and had a look at the MZ code you wrote. I think it’s probably a sensible idea to start off with a smaller part and then come back to this MZ part. Currently feel like I am walking around in a dark room!

For now, I am going to try make my own “custom board” using the PIC32MX270F256B which doesn’t use a boot loader- just ICSP. It seems using the ChipKit Lenny board config doesn't work on the 270F256B so some changes need making somewhere..

I’ve edited the boards.txt file as follows, hoping it’s correct:

variant=chipkit-customLenny
description=chipKIT Custom Lenny (32MX270F256B)
group=chipKIT
platform=pic32
board=_BOARD_CUSTOMLENNY_
board.flags=-D_USB
ccflags=-Map="map.map"
ldscript=chipKIT-application-32MX270F256-nobootloader.ld
upload.protocol=stk500v2
upload.maximum_size=258048
upload.speed=115200
build.mcu=32MX270F256B
build.f_cpu=40000000L
build.core=pic32
build.variant=customLenny
family=pic32
version=1
revision=1
core=chipkit
manual=
name=chipkit-customLenny

options.usb.name=USB Settings
options.usb.default=withSerial
options.usb.purge=true
options.usb.withoutSerial.name=Disable USB Serial
options.usb.withoutSerial.flags=
options.usb.withSerial.name=Enable USB Serial
options.usb.withSerial.flags=-D_USE_USB_FOR_SERIAL_

bootloader.file=${board.root}/bootloader

So the things I "think" I need to do to accomplish this task is:

  • Create a linker script that doesn't require a boot loader (is this the board.txt?)
  • Edit the c and h files appropriately as detailed further down this post)
  • Amend the pin mapping

Few questions though:

  • What crucial things do I need to edit in the board_data.c or Board_Defs.h?
  • Will removing the references to the board LED’s (#define PIN_LEDx) and reset/program buttons break anything? I plan on not using these.
  • I only want to use ICSP, not USB, so is there anything specific that needs removing from the c and h files or just the boot loader references in board.txt?
  • Can’t seem to find any logic to the pin numbering (physical <=> digital) - how would one find out the numbering conventions?

Comparing the MX250F128B and 270F256B I have noticed that the following needs changing Flash (from 128kb to 256kb) and Ram (from 32768 to 65536) needs changing in board.txt The existing .h file only references 1 I2C interface, when there’s 2

Want to get pin 16 blinking an LED. Then I can move onto the other MZ part!

Code I intend on using for this:

void setup() {
	pinMode(22, OUTPUT);
}

void loop() {
	digitalWrite(24, HIGH);
	delay(250);
	digitalWrite(24, LOW);
	delay(250);
}

majenko

Thu, 09 Feb 2017 12:09:56 +0000

ldscript=chipKIT-application-32MX270F256-nobootloader.ld

That line, with the -nobootloader, indicates that it's not using the bootloader. You don't need to craft a new linker script, I already made it for that chip. Note that the config bits are embedded in that file as LONG(...) entries. If you want anything other than the default settings you will have to copy that file and tweak the settings. Not a way I like it working, which is why I changed it for my MZ board in that repo to have a "boot.c" file with proper config settings in it specific to that board. Much nicer...

  • What crucial things do I need to edit in the board_data.c or Board_Defs.h?
  • Will removing the references to the board LED’s (#define PIN_LEDx) and reset/program buttons break anything? I plan on not using these.
  • I only want to use ICSP, not USB, so is there anything specific that needs removing from the c and h files or just the boot loader references in board.txt?
  • Can’t seem to find any logic to the pin numbering (physical <=> digital) - how would one find out the numbering conventions?

LEDs and buttons, no, it won't break anything. Those are just convenience macros for sketches. However things like the PIN_INTx and PIN_OCx are used by the core to map the functions to the pins properly and they have to remain.

By "not use USB" do you just refer to the bootloader, or to USB in its entirety? I.e., not using it even for serial communication with a PC from within your sketch? If you don't want USB at all then you can remove the USB options menu from the board.txt file along with the -D_USB flag.

There is no logical mapping between the chip's pins and the board pins. It's all about which pins are able to be mapped to the functions that we want on the board pins - where we want to be able to have the UARTs, I2C, SPI, PWM, etc. The pins were carefully chosen to give the most flexible options possible as well as the closest mapping to existing Arduino boards.

Comparing the MX250F128B and 270F256B I have noticed that the following needs changing Flash (from 128kb to 256kb) and Ram (from 32768 to 65536) needs changing in board.txt The existing .h file only references 1 I2C interface, when there’s 2

The flash and ram entries in the board.txt file aren't actually used at the moment. One day they will be to provide a warning that you are reaching your limit, but not yet. It's the linker script that defines the memory available.

The Wire.h library only supports 1 I2C interface. For more than that you use the DTWI interface, which uses the DTWI defines in the .h file. You'll see that is set to have 2 DTWI interfaces. The same goes for SPI. The normal SPI library only supports 1 interface, but DSPI supports more, so that is set to 2 interfaces, along with the correct defines for the pins and everything.

rs2845

Fri, 10 Feb 2017 01:55:00 +0000

Hello majenko,

Thanks for your response, makes more sense. I'll just change the chip type and flags in the board.txt. I don't really need USB for this project so i've just pulled the Vusb high for now. When I get onto the MZ chip, i wouldn't mind USB- saves having an FTDI chip on my board.

Have you actually tried out the 270F256B before majenko? I know my breadboard circuit works as it runs a standard MPLab program I wrote perfectly.

I've been trying to understand all of the mappings all evening in the board c file and the h file to figure out what to change, namely the fewer analog pins. Even then the digital outputs should just work? Do I need to change any #pragma settings as I know this caught me out when using MPLAB X (raw PIC programming).

Eventhough the 270F256D has more pins compared to the 270F256B which I am wanting to use, I should still be able to "blink" an LED right by selecting Chipkit-Lenny?

Side suggestion to UECIDE developers: A button to open the hex output folder in Finder!

majenko

Fri, 10 Feb 2017 10:32:29 +0000

[quote When I get onto the MZ chip, i wouldn't mind USB- saves having an FTDI chip on my board. [/quote] USB support for MZ is not very good at the moment. I have experimental stuff based on Harmony but it's not nice - and certainly no bootloader yet.

Yep. I have some here in DIP form. They are quite popular for breadboarding, though I can't recall the last time I actually used a breadboard ;)

The analog side of things is a bit of a convoluted web. I find it's always the hardest part to get right. Digital is a piece of cake by comparison - just the port and pin tables are really all that are needed for that.

There are no #pragma settings. The equivalent is the config entry in the linker script:

SECTIONS
{
  .config_BFC00BF0 : {
    LONG(0xCFFFFFFF)
  } &gt; config3
  .config_BFC00BF4 : {
    LONG(0xFFF979D9)
  } &gt; config2
  .config_BFC00BF8 : {
    LONG(0xFF6A0D7B)
  } &gt; config1
  .config_BFC00BFC : {
    LONG(0x7FFFFFFB)
  } &gt; config0
}

If you need to change those settings then it's best to copy the linker script and make your own version - then crank up MPLAB-X, create a dummy project with the right chip, and use the configuration bits editor to get the right settings - then copy the raw HEX values by hand into the LONG(...) bits. It's far from ideal, which is why I am exploring the better "boot.c" option with #pragma in it for the MZ boards.

Only if you a) compile it with a non-bootloader programmer selected so it gets the right linker script, and b) happen to choose a pin that actually exists on the B chip.

Turn on the "Compile the sketch in the sketch folder" and/or the "Save compiled output to sketch folder" options in the preferences. Then you can switch to the Files tab in the editor, click on anything in there, even the root folder, and go "Open in OS". That will open your sketch folder (or whatever you selected) where all your compiled code now is (if you turned on the first option) as well as the hex file (if you turned on the second option).

rs2845

Sat, 11 Feb 2017 03:25:51 +0000

But surely the linker script with/without boot loader or the MX270F256B will have the correct config bits? That's what's throwing me because I still cannot get an led on hardware pin 16 to flash. I thought the culprit was the program pin as I'd left it floating so I've pulled it low and high but with no difference.

Looking at my hex file too, it seems a whole lot smaller inside than the raw (yet functional) program I wrote in mplab X.

I don't suppose you'll have any test scripts or anything you can confirm have worked on this chip in the past? It'll serve as a good control to validate my hardware setup is correct.

I am sure this will end up being something very small and annoying! Raring to go with my projects

majenko

Sat, 11 Feb 2017 11:57:39 +0000

What exactly is your setup? The config bits define things like your oscillator, and that may not be the same in that file as your oscillator setup. I am not sure what it is set up as in there, but if I did it to match the Lenny then it will be set to use an external clock (EC) rather than a crystal.

rs2845

Thu, 16 Feb 2017 05:22:27 +0000

Hi,

So after a few days of trying, I have been defeated. Still got no result. I've attached all my files (linker script, custom board etc) =>[attachment=0]forum.zip[/attachment]

My hardware setup is to use the internal oscillator, no USB (or boot loader). The circuit I have copied is this one, just with the 270F256B chip. I just want to flash LED's on physical pins 2 and 3.

I have tried changing the config bits in my custom linker script, with the settings that work on my proper MPLAB X test project (which does actually flash an LED) => No result

I have tried changing the memory locations for my chip (page 42 of the chip datasheet => No result

At this rate, I think it's a sign to just learn how to use Harmony once and for all

majenko

Thu, 16 Feb 2017 10:11:18 +0000

Your config bits look kind of wrong to me. Try with this instead:

SECTIONS
{
  .config_BFC00BF0 : {
    LONG(0x0FFFFFFF)
  } &gt; config3
  .config_BFC00BF4 : {
    LONG(0xFFFFF9D9)
  } &gt; config2
  .config_BFC00BF8 : {
    LONG(0xFF7FFF59)
  } &gt; config1
  .config_BFC00BFC : {
    LONG(0x7FFFFFF3)
  } &gt; config0
}

rs2845

Fri, 17 Feb 2017 01:51:06 +0000

Still not getting any flashes sadly, even with your suggested config bits.

I am thinking it's now something to do with the pin mapping. I'm just looking at the Microchip data sheet for my chip and can't seem to see the physical/logical mapping. It's also been a long day so I will look again!

majenko

Fri, 17 Feb 2017 10:32:37 +0000

You could just use the TRIS/LAT registers to directly control the pin... That would confirm if the chip is running or not.

rs2845

Sat, 18 Feb 2017 05:48:53 +0000

Some good news. I have a blinking LED

Evidently working late at night doesn't always yield good results. The issue seemed to have been due to the physical package and pin mapping.

I deleted the custom "Lenny" board and used the DP32 board which uses an SPDIP chip. Changed the config variables and the linker/chip in the board.txt and it's running

Just a couple of small issues with the chip timing. delay(100) seems to be acting as 1 second. I am sure this is something to do with the PLL stuff so will see if I can fix this. If not, hopefully an external oscillator will do the trick when they finally arrive.

Then to try and get some WS2812B's running which is going to be a challenge, given the lack of library support.

Only then will I attempt to get the MZ2048ECM144 going!!

majenko

Sat, 18 Feb 2017 12:18:06 +0000

Sounds like the chip is running at 4MHz and the board definition is expecting 40MHz.

Either change the PLL settings (maybe the PLL is not turned on?) so it goes at 40MHz, or set the board.txt to expect 4MHz and run the chip slowly.