image credit: NASA/JPL-Caltech/SETI Institute
Last article, I briefly covered some of the hardware inside of the PIC32MZ devices, but now the time has come to start putting digital pen to digital paper and start designing a board. I chose to start from the Callisto board since its a working design and has much of the needed external hardware design done. So, its only fitting that the paternal twin sister card to Callisto be dubbed Europa.
Objectives
For this project, the objective is to design a Callisto compatible card incorporating the PIC32MZ, plus add some features that could not be supported directly by Callisto.
Europa will incorporate an integrated Bluetooth module for wireless communications, however, presently we’re going to focus on the top-side electronics. Namely, the PIC32MZ.
the Chip Errata
For some, reading the errata of a device is often an afterthought, for the MZ it’s important that one reads the errata before hardware design. The PIC32MZ’s errata identifies a bunch of issues that will affect software development parts of this project, however there are 2 that could cause some hardware issues.
The external crystal oscillator does not function when using a resonator or crystal
The low-frequency oscillator cannot be used with anything other than a clock oscillator. Crystals do not work.
Both issues can be easily addressed by using an external oscillator.
I selected a 24 MHz primary oscillator as the main clock source to the MZ. This clock multiplies up nicely to 48 MHz for the USB blocks, and is one of the few input frequencies that allow the USB to function.
It’s also the same oscillator that is used on Callisto, so bonus for sharing hardware!
Changes To Callisto
Modifying Callisto to incorporate the PIC32MZ was a bit easier than I initially expected. The two boards are essentially the same except for the MCU, and there are some components that are required for the STM32F413 from Callisto that aren’t required on the for the MZ.
Remove DFU
Starting from the major differences, I removed the DFU jumper. The PIC32MZ supports bootloaders, however, not in quite the same manner as ST does. The STM32 devices contain a ROM bootloader that supports (among other methods) USB device firmware updating. On the PIC32MZ, bootloading is not directly handed to us from the factory. Microchip provides some software frameworks and generators to create the bootloader that is specific for the board on which the PIC is located. The chip hardware supports a 160K memory region where this bootloader is stored.
Remove BOOT1 Pull-Down
On Callisto, there is a 10K pull-down resistor on pin PB2 (the blue LED). This is not needed since it’s associated with the DFU mode of the STM.
Remove C11
C11 is the core voltage LDO bypass capacitor. Inside the STM32, there is a LDO that creates the 1.8V required for the core from the 3.3V IO voltage, the PIC32MZ, however, does not require this additional cap.
Modify Flash Interconnect
The Flash memory on Callisto uses standard SPI. This is great for simple interfacing, but since the PIC32MZ supports QSPI, I wanted to give quad mode a test. Fortunately, the memory used on Callisto supports the quad mode, so all I had to do was identify the PIC32 pins that were used for the QSPI peripheral.
The Quad-SPI peripheral, dubbed SQI in the PIC32, contains 4 data lines, a clock and an chip select. Each data line is bi-directional and bears the pin identification of SQID. These are located at RE[0:3] on my device. The clock is attached to RF1, and labeled SQICLK. On the PIC32MZ that I am using there are 2 chip selects SQICS0 (RD4) and SQICS1 (RD5). Since there is only one flash device on the board, I chose CS0.
Add the Red LED
The return of the red LED is a pleasant feature that I am happy to add back to the card. The LuaBoard contained 4 LEDs, Callisto, however, could only support 3. Since there is more IO available on the PIC32MZ, I was able to squeeze in a red LED. This was routed to a strategically selected pin of the device to prevent blocking out a peripheral feature.
Add the PIC32MZ
The last thing to do was to add the MCU. Dropping in the PIC32MZ and identifying IO pins to use seems like it shouldn’t be an issue, but, since I was taking a little more time optimizing this design, I wanted to assign pins in a more reasonable fashion. Grouping pins that are logically related seems to make some good sense. Analog pins were grouped together for example. This became a bit more complex than I would have liked, not to mention it complicates the layout more that I would have liked.
Since There is a bit of a discussion here, I’m not going to expand the details of how and why I picked the pins. I’ll post a whole discussion on the origins of my pin selections a little later.
The schematics are all done and I’m ready to dive into the layout tools and start routing tracks.