RoadTest: Apply to test a Microchip Curiosity Nano Development Board
Author: misaz
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: AVR Curiosity Nano boards, STM32 Discovery and Nucleos, PSoC 62 Kit and few other
What were the biggest problems encountered?: Unstable software (new version of CLB designer fails to synthetize previously working design, early VS code integration bugs, Java Exceptions in debugger)
Detailed Review:
I welcome you to my detailed review of PIC16F13145 MCU and its evaluation board called Curiosity Nano. In stores you can find that board under EV06M52A product code. In this review, I will briefly describe board, it's features, capabilities and some mine options. Most of these apply to any Curiosity Board in the family. Then I will move to explain and review MCU specific for this particular board including reviewing overall development ecosystem.
This board is part of Curiosity Nano evaluation board family which Microchip makes for evaluating their MCUs. They started producing these boards many years ago and since that they make one new board every time they introduce new MCU family to the market. While originally intended for evaluating new MegaAVR generation of MCU, later they start making same boards for 32-bit ARM Cortex-M SAM, 8-bit and 16-bit PICs, dsPICs, and recently PIC32 family also become covered by Curiosity Nano board.
My current “collection” contains 5 of these:
In this review I will focus the smallest bottom one.
All Curiosity Nano boards have some common properties. All of them have on board programmer with USB port on left side, so you do not need to own any external one. But they differ for allowing evaluating unique features of evaluated MCUs. For example, AVR DU one has MCU with USB controller, so it has USB port on right side for evaluating this feature. AVR DB support multiple voltages, so there is one more pinhead for providing different voltage to part of pins. Some very interesting features are common. I will highlight few of my favourites:
One feature which I really like on these boards is digitally adjustable voltage regulator. Nowadays MCUs are quite flexible. PIC on board covered by this review support power voltage in range 1.8 - 5.5V which spawns several commonly used voltages: 5V, 3.3V and for even more modern electronics: 1.8V. But you do not need to limit yourself to these common voltages, if you want to run your design on 2.36V, you can set it. Basically, any voltage with approx. 5 - 10 mV resolution is supported. Accuracy is quite good. Let's see how to set it.
For AVR boards used with Atmel Studio (or Microchip Studio if you like up to date terminology, but I know it as Atmel Studio), you can do it in Device Programming Tool (chip with yellow flashlight icon on menu):
But this does not work with PICs because Atmel Studio do not support PICs. For long time I thought that MPLAB X do not support it because I never find such similar tool in GUI, but later I found video on Microchip website showing that it is actually doable in project settings and programmer will apply it on next program loading (or reading).
There is one more alternative which works only for common voltages 0V, 3.3V and 5V. You can write file with specific text to mass storage which pop up when you connect to your PC. Then board change voltage accordingly. See board manual for exact details.
While you likely do not want to run MCU at 2.36V in production, it can be useful in development time. For example, for testing how circuit behaves when battery discharges.
Another cool feature is onboard debugger. You do not need own any external one. When I was child, starting MCU development basically meant not only buying MCU (in DIP package typically) and accessories (breadboard, wires), but also buying very expensive (for children at least) programmer. And it was also tiered by capabilities. My first programmer which I paid approx. 30 USD back in time, did not support breakpoints. Just loading and possibly reading MCUs. With curiosity boards and similar situation is nowadays much better. Competition on the market caused that even lowest cost development kit typically contains debugger on board and its pretty capable one.
As I mentioned, you can place breakpoints in IDE, you can use stepping, it seems that even data breakpoints are supported (did not try it, but see it in GUI). Limitation differs per MCU. Likely AVR has different limitations compared to the PICs. For PIC 16F13145 covered in this review, 3 program breakpoints, 3 data breakpoints and 3 data capture breakpoints are supported.
While it may look confusing at the first look, board fits breadboard. Every other pin is shifted a little, but shift is very small so pin header fits it. When pushing pin header into it, this shift makes it harder to push into. You need to use force. But after that pins do not fell of and contact is good. It is another nice feature very limiting entry level cost. You do not need to solder anything to use the board on breadboard. Despite that I always solder them. I feel better when pulling it out from breadboard then.
The one thing which I do not like is that some Curiosity Nano boards do not populate crystal oscillator. It is case of PIC 16F13145 board. There is space for it, but you need to solder it yourself and rework some jumpers which are quite tiny. By default, pins are exposed to pin header, so maybe THT one connected there will also work.
Since MCU is small, board is also small. Compared to other Curiosity Nano button is less convenient to press, because it is very tiny there as well.
Now let's go to microcontroller itself
PIC 16F13145 is the most comprehensive unit from 16F13 family. It is typical that Microchip uses the most advanced unit on Curiosity Nano boards. It is typically easy to scale down if you need to save some money for production device afterwards. You can scale down in two dimensions: pin count and memories. RoadTested unit has 14KB of program flash and 1KB of SRAM. Scaling down in term of memories remains all the peripherals exactly same, just program memory and RAM go down to half (16F13144) or quarter (16F13143). Scaling down in terms of pin count means feature cuts, but it is not that strong. You can scale down to 14 or even 8 pin options. Pin scaled down options contains some peripheral constraints. Obviously, 8-pin can't offer more than 8 ADC channels. But generally offered peripheral are the same except pin count constraints. Curiosity board comes with most comprehensive unit in 20-Pin VQFN package.
Unique peripheral which you will likely select this family for is Configurable Logic Block (CLB). It is mini-FPGA containing 32 cells. Microchip call cells BLE - Basic Logic Element. I will call it cell to do not interfere with Bluetooth, which is not offered by this 8-bit MCU. Each cell contains input multiplexers, 4-to-1 LUT, and D flop. Each part of cell can be optionally eliminated if needed. But synthetiser tool does all these configurations for you, so you do not need to worry about it much.
I developed WS2812 bus driver using it. Normally you need to bit bang it which has some timing and interrupt usage constraints, or you can use SPI preferable with DMA to generate timing sensitive signal. All of these bring some constraints to firmware and resource utilization. I tried to offload all these into CLB and I managed to do that successfully.
Microchip offers tool which can synthetise some Verilog or graphical design. It is available in MPLAB X, or you can access the same tool online at https://logic.microchip.com/clbsynthesizer/ even without having board in hands. It is good idea to test if your design idea fit it in advance. Here is how graphical designer look like:
Internally CLB structure is constrained. Not every cell output can be connected to all cell inputs. Similarly, some external outputs are available only on subset of elements. Synthetiser tool handles it for you but it brings some surprises. For example, I had design which utilized 28 / 32 cells, so I was happy about it. But it did not work, so I tried to expose one internal signal to GPIO to see what’s going on. And unluckily after adding that debug signal overflown design. This signal likely was not easily routable to particular GPIO pin I selected, so synthetiser likely needed to duplicate lot of logic or waste some cells just from one part of mini-FPGA to another. And this simply overflown capacity of 32 cells. Design tool is big black box. When design overflow, it does not tell you much. It even does not tell you if synthetises failed because of exhausting resources or because it contains some real error. Another caveat from similar group is that it seems that tool evolve over time and for example my design which synthetised well few months ago, now with new version of synthetiser fails to synthetize for some reason. That is disadvantage if you run synthetiser tool as on online app.
Structure of CLB interconnection is documented, so with some engineering feeling you can try and guess changes needed to do to fit design. For example, in case when I had 28/32 utilization which later failed just by exposing one signal to GPIO, I tried just changing it to other GPIO without any other change of internal circuit structure. It magically successfully synthetized with utilization 31/32.
There are no RAMs or other dedicated helper block around cells known from standard FPGAs. Only dedicated hardcoded part is 3-bit counter. You can bring "counter stop" and "counter reset" signals and you have 8 outputs indicating one of 3-bit counter state. You can use any or multiple of these in your design. Can be good for some sequencing in design. You can use this counter for anything you want. In my WS2812 driver, I used it for integer division of clock.
Bitstream to this FPGA is loaded externally and you can't change it at runtime from PIC CPU core. Despite structure of mini-FPGA is mostly publicly described in datasheet, format of bitstream or interface used for programming it is not described at all. But there is guy on the internet who reverse engineered it, so you can read about it on https://mcp-clb.markomo.me/. He also has python library which can generate bitstream. So, if you want to have 32 cells under absolute control and do not want surprises, this is the way.
For interoperation with software on CPU core, there are 4x 8-bit registers which maps to 32 signals inside FPGA parts. One caveat (or actually feature if you know about it) is that registers are synchronized and writes only when last (clbswinL) is written. If you write only clbswinH, it never gets updated on FPGA side. Benefit is that you can write all four and their update on FPGA side atomically. It is not explicitly written in register description, so I wasted some time investigating why my register value propagation do not work. It is explained in functional description section in datasheet.
For communication in other direction (FPGA to CPU) you can use interrupts. There are 4 signals which can trigger interrupts in CPU. Except direct "communication" with CPU, you can also trigger ADC measurement and various operations with timers. On input sides, you can process outputs from many peripherals (UART, SPI, PWM, clocks, timers...). You can see them all online in synthetiser tool by adding pin to graphical design.
Finally, despite bitstream is not settable from firmware, CLB can be at least enabled and disabled from software.
This is most unique peripheral of this MCU so I was bit verbose. Not let's briefly look at others peripherals.
10-bit ADC is offered. 8-bit DAC is offered. Analog comparator is offered. And finally, voltage reference with 1.024V, 2.048V and 4.096V options is offered. Peripherals are quite modern. Nothing impressive but for general purpose apps should be enough or at least it is at the same level where competitors are with similar MCUs.
SPI and I2C are covered by shared peripheral. Sadly, there is only one instance so you can use only one of it at time. But pin mapping is extremely flexible on PIC, you can route any peripheral signal to any pin you want and you can change it in runtime. If you screw up and swap SDA and SCL on I2C, you can just update firmware in this PIC case. Additionally, as a benefit, with this MCU you always have very nice PCB layout.
You can also utilize this flexibility for actually using both I2C and SPI in design despite there is only single peripheral. You can work in a way that you use SPI, then reconfigure peripheral and remap it to different pins and use it for I2C, then swap again, etc. I made demo project with I2C sensor and SPI display (connected to different wires). Firmware simply did transaction on I2C bus to sensor, then changed pin mapping, reconfigured peripheral to SPI mode and transferred rendered screen to display. It is doable, just can't transfer both at the same time.
The biggest issue I see is that firmware is far more complex and MCC code generator (MCC code generator is explained later in this review) tool absolutely do not take such use case in mind. It allows you to always generate driver only for one of them. I hacked it by copying generated output folder with I2C driver under different name, then reconfigured to SPI and generated source. Need to clean code to remove some duplications and still need to make my own logic for Deinitialization/Initialization when swapping buses and of course need to manually reconfigure pin mapping. It worked at the end, just was not convenient.
UART has dedicated communication block. It is easier to use since compared to hybrid peripheral above. There is only one instance though. But you can do the trick with remapping pins as well and use it multiple time as well.
And if you run out of available peripherals, you can always make some using CLB.
MPLAB X IDE is classic IDE for PIC. It is NetBeans based which bring some technological historical limitations. For example, on my monitor it is blurry because it does not support high DPI. It follows proprietary project system which may be inconvenient for nowadays developers using "open folder" feature instead of complex project configurations. However, it works pretty reliably and XC8 compiler and other is pretty well integrated. Debugger mostly works. HW resource utilization is nicely visualized for both build time properties (for example, flash memory utilization) as well as runtime resources when debugging (for example, maximum allowed breakpoint count).
There is code generator tool which is bound to all projects by default which I do not like. I think it is not necessary for 8-bit MCUs which are not that comprehensive compare to nowadays blazingly complex ARM MCUs where are these generators handy. Drivers it generates does not seem very useful to me. To me it seems that it more or less wraps registry write/reads with minimal logic around. XC8 compiler often then complains that there is function compiled, but unused.
I personally more like Atmel Studio which works faster, despite based on old Visual Studio, still do not suffer some legacy issues like high DPI issue, work faster on nowadays hardware, do not force using any code generator, and many things seem simpler and more straightforward to me.
Except MPLAB X IDE there is pretty new integration to VS code. It is pack of extensions. Since it is new, there are quite a lot of bugs. But it gets better over time. For example, when I started with it, it shown every few seconds popup that some communication with AI service failed because of credentials issue. This got fixed in some update since then. Code generator tool integration is worse. It is hard to find how to create project and how to do operations on top of it. After I somehow integrated it manually, it still generates sources to wrong folder then I expected and did not find way where to set it. Because it is more modern there are no longer issue with legacy base. High DPI works fine there. Some operations feels faster and overall responsiveness of VS Code is better than MPLAB X.
One problem I see is that many vendors try to integrate into VS code nowadays and everybody do it slightly differently and there are collisions between extensions. I had to uninstall Modus Toolbox extensions which I used for Cypress/Infineon PSoC development because I had hitting infinite stream of notifications that something is misconfigured. Configuring it broken something else. it was not clear if IntelliSense errors come from Microsoft C++ extension, Clang extensions which some other extension bring as dependency or if it comes from error parsed from XC8 output. I recommend using VS code instance with only one MCU ecosystem. As far as I know nowadays VS code do not support environments like original VS supported via "instances".
XC8 compiler is integrated much worse compared to MPLAB X IDE. Code completion has no idea how compilation works. It reports error like wrong includes, missing functions, etc despite compilation succeed. I suspect it is partially because my project was misconfigured because I had some tweaks to structure after creating it, but still did not manage to fix completion in reasonable time. Completion also has no idea about any Microchip proprietary thing like pragmas.
Very similar issues are around debugger. Microchip somehow integrated their debugger into VS code, but there are lot of situations when it does not work, things get out of sync, breakpoints often get missed, sometime code steps on wrong lines even with disabled optimization. Stopping debugger sometimes fails and VS code thinks it still runs. Many times, I clicked continue, in VS code it looked like still stuck on breakpoint, but code actually run and miss several breakpoints afterwards. It is very frustrating when these things do not work and failures are heavily random. In MPLAB X they worked mostly fine except some Java exceptions which happens in both. I think there is even ton of bugs inside VS code core which are not caused by Microchip because I have similar experience with other MCU ecosystems integrated to VS code. But since everybody implement VS integration slightly differently, bugs in debuggers in every ecosystem are slightly different as well.
To sum SW section up, MPLAB VS code integration is likely future, but nowadays I recommend stick with MPLAB IDE. However, it may change soon, because they update VS Code extensions pretty often.
Documentation is very good. Very few things are missing, datasheet is clear, Curiosity Board had manual and schematics. There were few minor points like mentioned lack of explanation of synchronized write when transferring data to CLB, but generally, I consider Microchip’s documentation very good. Compared to many competitors, it is also very easy to find documents on their webpage.
My personal TLDR verdict: It is great board and MCU but unless you need CLB, it is higher pleasure to work with AVRs.
