RoadTest: Ultra-Low Power Arm Cortex-M4 Darwin MCU EVM
Author: Jan Cumps
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?: low power microcontrollers STM32F030, MSP43X
What were the biggest problems encountered?: The SDK release pushed out during the road test had issues with MAX32660
Detailed Review:
I'm road testing the MAXIM32660 Evaluation System.MAXIM32660 Evaluation System. A tiny ARM Cortex microcontroller on a small evaluation board.
|
The MAX62660 Evaluation system is a tiny board. It strictly has the components on it needed to evaluate the microcontroller:
MCU side:
It's a good idea to keep the board to basics. As long as there are enough pins broken out, it gives the most freedom when evaluating.
In particular when you're trying to measure the power profiles, it's helpful that there aren't any peripheral components that blur the image.
The kit doesn't restrict options. There are enough pins that can be used as generic IO. All communication options are routed out.
This is the schematic of the essentials, without the debug side.
The kit comes with a handy card that shows the breakout pin assignments. The controller gives you some freedom to assign peripherals to diferent pins.
The card shows all the options:
Debugger side:
The debugger part takes more board space than the actual MCU side. You can break it off though.
That allows you to use the MCU part stand-alone if you desire to do so.
The debugger (implemented on another MAXIM MCU) allows you to program the device, debug it and let it communicate over the USB port.
It also lets you choose a supply voltage for the MAX32660. You can set either 3V3 or 1V8.
The debugger supports two types of interface:
I prefer the second style because my workflow relies heavily on stepping through code.
You can use the USB as COM port together while debugging.
If you want to test the MAX32660 under a different voltage you can do that by providing an external voltage to pin 2 of the Target VDD jumper JP1.
Microcontroller MAX32660
The MAX32660 is an ARM microcontroller that positions itself as low power and high performance.
Highlights:
The focus is clearly on processing force (floating point!), low power modes and inter-chip protocols.
There isn't a USB or a wireless radio on board.
In the IOT landscape, this would be the workhorse that sleeps most of the time, talks to your sensors and aggregates and calculates the data.
It then has to hand off that data to some other device to do the communication.
It can also be used as a generic controller, but MAXIM definitely promotes it as an IOT component.
For the full review, please see my separate post
MAX32660 Evaluation Kit - part 3: Power Measurement .
The controller has a good balance of power save options.
When you develop your firmware carefully to separate high power functionality, and optimise the time it needs to be in a high power mode,
you can design applications that run on a sniff of a dirty oil rag.
In particular when you have a long wait time during sensor measurements, there's loads of optimisation that can be achieved.
MAXIM provides a good example that shows you how to switch between power modes and how you can wake up from sleep.
The device comes in three package choices.
The one on this evaluation system is a 20 pin TQFN.
MAXIM was so kind to send me two samples. The photo below lets you appreciate how tiny this MCU is.
The footprint, typical for a TQFN, has a big middle pad for thermal management. It needs to be connected to VSS
 |  |
Hand soldering is possible.
It's worth watching some of Louis Rossmann's videos to see what you can get away with when reworking SMD components.
You can make a real tiny circuit including a pressure sensor that fits on a PCB smaller than a Euro coin.
For the full review, please see my separate posts
MAX32660 Evaluation Kit - part 1: IDE install and Build First Example and
MAX32660 Evaluation Kit - side note A: C++ Eclipse Project .
SDK
The SDK that MAXIM provides is a combination of Eclipse IDE, libraries, APIs for the peripherals and example projects.
The kit also works with the MBED online IDE. I have tested this and it works. I will not elaborate on that option and focus on the Eclipse IDE.
Installation and usage instructions for the MAX32660 are not available. But the user guide for the MAX3263X SDK works.
I had an unfortunate mishap with the SDK during the road test. When I installed it originally, everything worked fine.
MAXIM pushed out an update while I was evaluating, and that uninstalled the debug support for the MAX32660.
Reinstalling the IDE from a fresh download did not help, because that uses the same (missing) online repositories during install.
I had confirmation from keithwebb that he had the same issue. He also provided me the missing configuration so I could continue my evaluation.
I raised a support case. MAXIM informed me that the issue is related to a broken link.
The Eclipse integration is good. Most of the functionality confirms to Eclipse's look and feel.
Getting the debugger working is easy. Launch configurations are available when you import examples.
The only time I felt the Eclipse integration was thin, is with the build cycle and when starting new projects.
MAXIM chose to use Make files. This works well and allows you to build the projects without Eclipse.
On the other hand, this requires you to add source files manually and the build does not use the include settings of the project and the build switches you set in the properties.
C++ projects are possible. Please check my C++ post on some specifics you need to do to make this work.
The firmware examples that come with the SDK cover most of the functionality of the controller. The writing style is clear and the functionality mimics real world challenges.
They mostly show everything a peripheral can do, including optimising throughput and using the interrupts.
I'm not sure if the FreeRTOS example works correctly. More on that later.
HAL
MAXIM provides a hardware abstraction layer for the MAX32xxx family. I think it's a well balanced set of APIs.
The HAL covers the core options and the peripherals.The level of abstraction makes using the device reasonable easy, while allowing you to use advanced options.
It does not prevent you from talking to the registers directly and mix and match API vs direct register approaches.
For generic use, the performance and overhead is OK. There are situations where they don't give you the speed you need.
That's when you step away from it and roll your own. See what michaelkellett did to make the GPIOs fast enough for bitbanging SPI.
RTOS
MAXIM has a FreeRTOS port for the MAX32660. A big ++ for that.
A few errors in the FreeRTOS example point that that seems to be adapted from some other board. I could not get that one to recover from sleep mode.
I also could not get it to work in the tickless mode.
I raised a support case at MAXIM to review this. This one I haven't received a confirmation for yet.
So the jury is still out on the FreeRTOS port. I can only keep my initial ++ intact if MAXIM confirms that the wake-up and tickless mechanism work.
For the full review, please see my separate posts
MAX32660 Evaluation Kit - part 2: Mod the PCB for Power Measurement
MAX32660 Evaluation Kit - part 3: Power Measurement
MAX32660 Evaluation Kit - part 4a: Low Power Sensor design - Barometer Hardware
MAX32660 Evaluation Kit - part 4b: Low Power Sensor design - Barometer i2c and Init
MAX32660 Evaluation Kit - part 4c: Low Power Sensor design - Barometer, Not Yet Power Optimised
I tried many of the examples. I spent most time with the power modes and with I2C.
For low power measurements, I adapted the board to allow me to measure the current flowing to the MCU.
I just had to rip the trace meandering from the debug side to the MCU side, and solder breakout wires to both sides of the cut.
When I'm not measuring current, I just short the two wires. When measuring the power consumption I remove the short and put an AMP meter in series.
Here is the log from a switch between 6 power modes:
I used the LP example, in clocked mode.I'm not really sure that the controller goes into BACKUP mode that way because it should not be able to recover from that without bumping power.
Measurements suggest it's in deep sleep instead backup.
Anyways, in the log when the example is running, it claims to be in backup mode.
I may review this in more depth later for another road test I'm doing.
To check if I can design a working application myself, I integrated one of the ROHM sensors I have from Rohm SensorShield-EVK-003 (Arduino Compatible) - Review with the MAX32660.
I started from MAXIM's I2C example and ROHM's barometer example and managed to get a working design (not power optimised) in an evening.
That's when I learned that the HAL API can be used in a real example. I did not have to dig into the registers.
Support
I've used MAXIM support for three cases.
I bricked an MCU. MAXIM came back with sound analysis very fast.
As mentioned above, I raised one for the FreeRTOS example. That's open for four weeks (2 weeks plant closure because new year included). I am not impressed with the analysis going on in that ticket.
(edit added after submitting the review: this case has now been closed by the support analyst without investigation or resolution. I expect better)
Also mentioned above, the issue with the MAX32660 debug support uninstalled via new update of MAX32660 support package. The issue seems to be resolved but the support experience is meek.
The MAX32660 is a serious microcontroller. It has a good mix of computing power and peripherals to run complex designs. The power modes are sufficient to give your design a long autonomy when running from batteries.
The provided SDK and examples are good. I would rate the learning path easy, if you have experience with embedded development.
The size of the controller is attractive. Soldering is challenging but doable by hand. In the comfort zone of most manufacturers and assembly houses.
I'm happy that I got to learn this component and like to thank MAXIM and element14 for organising this road test.
Top Comments
Here's a link to the failing toolchain issue: https://www.element14.com/community/roadTests/2005/l/ultra-low-power-arm-cortex-m4-darwin-mcu-evm#comment-241423
fyi, I just archived the toolchain and did a full fresh download and install. It works now. I can debug.
In summary: toolchain seems to be stable when freshly installed. It broke the both times I allowed…
Thanks Jan Cumps that is really good news
. I am in the process of downloading the toolchain right now. Based on your results, I plan on using this as a basis for Max32650 Roadtest.
Clem