Ultra-Low Power Arm Cortex-M4 Darwin MCU EVM - Review

Table of contents

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.



Evaluation Kit


The MAX62660 Evaluation system is a tiny board. It strictly has the components on it needed to evaluate the microcontroller:

  • the MAX32660 MCU, a 96 MHz ARM Cortex M4 with 256 kB Flash and 96 kB RAM
  • a button
  • an LED
  • many pins broken out, fits on a breadboard
  • an on-board debugger that can be broken off




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:

  • the MBED style DAPLINK.
    When you plug the debugger in a PC, it represents itself as a USB disk.
    You can develop a program in MBED and then drop the compiled binary on the drive. Simple as that.
  • OpenOCD compatible full-fledged debugger.
    The evaluation kit integrates perfectly into Eclipse, where you can use the build - load - debug cycle to step through your code.
    If you download MAXIM's SDK, you get a fully configured Eclipse with it, ready to start.

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.


  • Core: ARM Cortex M4
  • Maximum Clock Frequency: 96 MHz
  • Data Bus Width: 32 bit



  • Program Memory Size: 256 kB FLASH
  • Data RAM Size: 96 kB SRAM, DMA support
  • Operating Supply Voltage: 1.1 V, 1.8 V
  • Floating Point
  • Supply Voltage: Min: 0.855 V,  Max: 3.63 V
  • Watchdog Timer
  • Real Time Clock, 3 Timers
  • Interface Type: I2C, SPI + 12S, UART
  • Various sleep and low power modes



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.




Power Modes


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.



Software / SDK


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 .




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 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.




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 did to make the GPIOs fast enough for bitbanging SPI.




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.



Experience and experiments


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:

  • Running in ACTIVE mode
  • All unused RAMs placed in LIGHT SLEEP mode
  • All unused RAMs shutdown
  • Entering SLEEP mode
  • Entering DEEPSLEEP mode
  • Entering BACKUP mode


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.




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.



Related Blog


part 1: IDE install and Build First Example
part 2: Mod the PCB for Power Measurement
part 3: Power Measurement
part 4a: Low Power Sensor design - Barometer Hardware
part 4b: Low Power Sensor design - Barometer i2c and Init
part 4c: Low Power Sensor design - Barometer, Not Yet Power Optimised
part 5: FreeRTOS Example
side note A: C++ Eclipse Project
side note B: Create a Release Configuration
part 6: Driver LIB for a 16 x 2 LCD