MAX32630FTHR and BLE?

Have you heard anything from Maxim why they don’t seem to support their boards ?

No, not a word. Actually they never communicated anything like that even though i communicated with their in-house support about a year ago because of the broken USB-stack. I was a bit amazed as their devs told the support team they solved that problem but when i tried the updated code it was still broken and they just wanted to re-enable the outdated USB-stack into mbed version above 5.14…

Quite the contrary here someone on behalf of Maxim promised they would fix both the USB and BLE-stack in some weeks. That was 7 months ago. The only thing i know they found some kind of bugs and they wanted to address all their boards in one release. Am not sure however if they could fix the features for the MAX32630 at least.

So i can not tell if the Maxim team just abandonned Mbed-os as the ever changing codebase of mbed costs them too much time to maintain or they are just not able to code for newer Mbed versions or they prefer to serve embedded engineers who will program the board on the register level.

Neither did the mbed team communicate anything like they do not support the board anymore, that is why the status is quite unclear to put it that way.

Bummer the board has lost support.

Btw, I was uncertain how to setup the BMI160 in interrupt mode (think interrupt driven step counter) using this BMI160 - Library for Bosch Sensortec BMI160 IMU | Mbed

So I ported the following to mbed instead, seems to work and it does generate interrupts (same code does NOT work in Arduino, attaching interrupts doesn’t seem to do anything ??)

It currently only supports I2C. If there is any interest in the mbed port let me know.

One unresolved problem for me is that I cannot get the Power Management (sleep) or Low Power API to work with the MAX32630FTHR. Similarly RTC. There are some videos on the Maxim website that suggest these are linked. So they must have their own implementation or something. Very little to go on.

@gerriko
I also struggled with that and this sums up my findings best:

/* 
Note for low power modes: lp.h must be included to access all the low power related commands.
In L3:RUN and in LP2:PMU wait command works, in LP1:Standby and in LP0:Stop it will not do anything!
So before entering in LP1 or LP0 the wakeup source(s) must be configured otherwise the chip will remain idle!!!
Put this into the superloop to avoid problems:
    while (SW1 == 0) {
      ThisThread::sleep_for(100);
    }
Possible wakeup sources:
- GPIO
- RTC
- USB connection

        controller          //      consumption                                           //    resume time
LP0     power sequencer             105 nA (no RTC); 505 nA (RTC)                               11 us             
LP1     power sequencer             1,86 uA (Idd12); 120 nA (Idd18); 505 nA (Idd18+RTC)         5 us
LP2     PMU                         173 (Idd12@96MHZ oscill) + (27 uA/MHz)                      0 us
LP3     CPU                         173 (Idd12@96MHZ oscill) + (106 uA/MHz)                     -

*/
#include "lib/max32630fthr/MAX14690/MAX14690.h"
#include "lib/max32630fthr/max32630fthr.h"
#include "lp.h"
#include "mbed.h"
#include "pwrseq_regs.h"
#include "rtc_regs.h"

DigitalOut *rLed = new DigitalOut(LED_RED, LED_OFF);
DigitalOut *gLed = new DigitalOut(LED_GREEN, LED_OFF);
DigitalOut *bLed = new DigitalOut(LED_BLUE, LED_OFF);

void myblink(DigitalOut *izzo, uint8_t cycles, uint16_t msec);
// blinks a led with passed in params
void myblink(DigitalOut *izzo, uint8_t cycles = 1, uint16_t msec = 500) {
  for (int i = 0; i < 2 * cycles; i++) {
    printf("%d\n", i);
    izzo->write(!izzo->read());
    ThisThread::sleep_for(msec);
  }
}

// main() runs in its own thread in the OS
int main() {
  if (LP_IsLP0WakeUp()) {
    myblink(gLed, 3);
  }

  myblink(gLed, 1);

  LP_ClearWakeUpConfig();
  LP_ClearWakeUpFlags();
  LP_EnterLP2();

  ThisThread::sleep_for(15000);
  printf("Hello\n");


  while (true) {
    while (SW1 == 0) {
      ThisThread::sleep_for(100);
    }
  }
  return 0;
}
1 Like

I note that the above are all specific to the MAXIM boards and the use of these header files (api’s or libraries) are not documented anywhere in the mbed platform section for these boards. This is very much a Maxim board specific implementation.

In my opinion, if someone provides development boards for general use and claims it works with Mbed OS 6.x then they need to provide wrappers to ensure that all the Mbed API’s work or they ensure there are precompiler conditions that tell the user that the API’s do not work. Otherwise how the heck is the developer to know when they see error messages in the IDE.

It is absolutely essential to ensure API’s work properly for each and every board, especially when piggybacking off something like Mbed OS. Hopefully someone from Maxim reads and responds to this post.

1 Like

Did you guys measure actual current consumed after LP_EnterLP2(); ?
In my case, power just goes down from say 4.4mA (LED off) in slow blinky program to 4.1mA, so not that much power savings.

Also tried LP_EnterLP0/1, and then power consumption is very low, but then
ThisThread::sleep_for(15000) does not work (well, if nothing is running that is sorta expected).
Have not tried using external interrupt to wake it up yet.

Also: be careful with leaving device after LP_EnterLP0/1, as device is difficult to reprogram… (almost thought I had bricked it yesterday)

Followup: IRQ does not wake device in after LP_EnterLP1, and the power saved by LP_EnterLP2 is not good enough for a truly battery driven device (I was going to use the BMI160 to wake device on movement). I think this was final nail in the coffin for using this device for anything really. Bummer.

@heikkij
My example above is just to show you how to gain access to programming the low-power modes.

In LP0 and LP1 modes only the power sequencer remains turned on, both the MCU and PMU is powered down, that is why the only way to wake up your the board from these states is by interrupts on GPIO or with RTC.

Also the code part while (SW1 == 0) {ThisThread::sleep_for(100);} is important otherwise you are risking to brick the board when going to LP0 or LP1.

Yeah, this board is for sure really capable, but for that you need to program it on the register level without any frameworks like mbed-os.