Forum - Recent Threads

Part 2 Tracking Sentry: Components and Design Plan

adam_k — Sat, 09 May 2026 04:21:03 GMT

Bit late to get started, I know, but unavoidable given exams and travel commitments. Thankfully I’ve found myself with some free time and all the components I ordered have arrived so should be smooth sailing from now on (sarcasm).

This is my second post so I’ll start with a reminder of what my project is, walk through the components I’ve chosen for it, get into some specifics, then explain my action plan and potential challenges ahead.

The Project

My project is essentially a two-node autonomous security system. Node A includes a camera and stepper motor to pick up movement and follow a target. It also uses the board’s in-built IMU to detect when it is being tampered with. This data is then sent via Bluetooth to Node B – the ‘command station’. This receives the alert (movement or tampering), and outputs the relevant signal on the LED board. It should also log the incident to the main computer using a simple Python server.

The Components

I was lucky enough to win the nomination and receive many components for free. My proposal was based around this and I try to incorporate as many elements of these as possible within my design. Others were ordered specifically for the project and I also take advantage of my existing inventory.

The motor

This is essential for my camera to pan and track targets. Otherwise it is just a stationary camera which is not very useful nor creative. I decided a NEMA 17 motor would be most useful for my project and ordered one along with a steel mounting bracket for stability. At least that was the intention and have since come to find the bracket may act more as dead weight than anything useful. Well at least it looks nice. I also ordered a 5mm coupling for the motor shaft, allowing me to directly mount components on top of the motor. Probably avoided in industry but works fine for this.

The stepper motor is driven with the included ADA2927 driver. Two are included but only one is needed. This is powered from a wall AC – 12V 1 A adapter, split into two terminals with a DC barrel jack – 2 pin connector. Slightly concerned by the 12W output but may be acceptable for a single NEMA 17 motor not needing much torque.

The camara (and rest of Node A)

I am using the Arducam Mini 2MP Plus OV2640. Should be able to suitably take power from our setup and send data to the Node A MAX32630FTHR#. The camera should provide suitable on-board compression to allow the board to process frame differences to detect movement and drive the motor. The IMU should also work to detect tampering (IMU triggering disabled during motor movement to eliminate false detections). Given unfortunate time constraints there won’t be SD storage. State information and times are sent to Node B via Bluetooth. States being “connection”, “movement” and “tampering”. No connection could display static or something on the LED matrix. This just makes it look more engaging than just having a single LED light up to imply a state. Data should be sent to the computer to log state and timing information. The board on A will be powered directly with a 3.7V lithium battery.

Node B

This is pretty straightforward. Just another board connected to an LED matrix display. Either the CharliePlex FeatherWing 7x15 or the Würth Elektronnik ICLED Featherwing. If feasible within time constraints the Ethernet adapter will also be included. Since this is intended as the ‘command station’ we can just power it using USB from the computer.

Other stuff

There are some other components included such as the FTHR-PMD-INTZ Adapter which is likely necessary. I also have a couple 9V batteries, breadboards, wires, jumper wires, wire strippers, and a Leatherman Wave (very useful) which will all be incorporated.

The Plan

Time is very limited for me but there’s no point jumping in trying to get to the final design immediately. I plan to build this up in stages and test parts individually before putting it all together.

I’ll first start by getting one of the boards to display patterns on the LED matrix. This shows I can get the board powered up properly and code running. Then I’ll try triggering this by a Bluetooth signal from the other board. Then I’ll set up Node A to control the motor to angle the camera. Perhaps the trickiest I’ll attempt to get the camera module feeding data to the board, have the board analyse the frames, and use the analysis to direct the camera towards movement. If by miracle this all works well then I should be able to integrate this all together in addition with the IMU detection.

Final Thoughts

I have a clear plan ahead now and am excited for the days to come. To be honest I am a little nervous about this not working out perfectly within the time constraints but I hope to have something running to demonstrate, even if it means some deviation from the original plan. I’ve worked on more complex stuff before though not in the same time constraints. Regardless, it will be a learning experience and I will be documenting the whole process. The free socks are also appreciated!

Guardian Sentinel — The Slave

meera_hussien — Sat, 09 May 2026 00:29:33 GMT

Guardian Sentinel - The Slave

<Part 4>

For the slave, i decided to use the similar setup, hence i decide to use the FeatherWing Tripler Mini Kit.

The following image shows the header pins being soldered

Once finish soldering, I place the MAX32630FTHR in the middle.

Followed by the FTHR-PMD-INTZ Feather-to-PMOD

Which is place to the right of the MAX32630FTHR

For further info on the FTHR-PMD-INTZ Feather-to-PMOD click here. Following that, i place the DC Motor + Stepper FeatherWing Addon.

Which is place to left of the MAX32630FTHR

To ensure all the three boards are connected, i did the i2C scanner and below are the result

#include <Wire.h>

void setup() {
  Serial.begin(115200);
  while (!Serial);

  Serial.println("MAX32630FTHR I2C Scanner");
  Wire.begin();
}

void loop() {
  byte error, address;
  int devices = 0;

  Serial.println("Scanning I2C bus...");

  for (address = 1; address < 127; address++) {
    Wire.beginTransmission(address);
    error = Wire.endTransmission();

    if (error == 0) {
      Serial.print("I2C device found at address 0x");
      if (address < 16) Serial.print("0");
      Serial.println(address, HEX);
      devices++;
    }
  }

  if (devices == 0) {
    Serial.println("No I2C devices found.");
  } else {
    Serial.print("Total devices found: ");
    Serial.println(devices);
  }

  Serial.println();
  delay(3000);
}

and the result from the serial monitor is shown below

In the next post we shall see on interfacing with sensor and motor.

Guardian Sentinel — Ethernet & BLE

meera_hussien — Fri, 08 May 2026 09:37:37 GMT

Guardian Sentinel — Ethernet & BLE

<Part 3>

In the previous post we have seen about how to program the MAX32630FTHR and the OLED. In this post we shall see how to configure the ethernet and the BLE.

Ethernet

Since we are using the ethernet FeatherWing, there is onboard RJ45 connector with controller. The image below shows the details of the device.

The board is based one the WIZnet5500 and take the form factor of the Adafruit FeatherWing Tripler. It can support

10BaseT/100BaseTX Ethernet
Support Auto Negotiation (Full and half duplex, for both 10BaseT and 100BaseTX)

In order to test the ethernet connectivity i have use the following code. And the serial output shows the output. I have also configure the OLED to show the output as well.

#include <SPI.h>
#include <Ethernet.h>

#define STATUS_LED LED_BUILTIN

#define ETH_CS    44
#define ETH_RESET 46

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0x32, 0x30 };

void resetEthernet() {
  pinMode(ETH_RESET, OUTPUT);

  digitalWrite(ETH_RESET, HIGH);
  delay(100);

  digitalWrite(ETH_RESET, LOW);
  delay(300);

  digitalWrite(ETH_RESET, HIGH);
  delay(1000);
}

void setup() {
  pinMode(STATUS_LED, OUTPUT);

  Serial.begin(9600);
  delay(3000);

  Serial.println();
  Serial.println("==============================");
  Serial.println("MAX32630FTHR + Particle Ethernet");
  Serial.println("==============================");

  SPI.begin();

  resetEthernet();

  Ethernet.init(ETH_CS);

  Serial.println("Starting DHCP...");

  if (Ethernet.begin(mac) == 0) {
    Serial.println("DHCP failed.");
    while (true) {
      digitalWrite(STATUS_LED, HIGH);
      delay(300);
      digitalWrite(STATUS_LED, LOW);
      delay(300);
    }
  }

  Serial.println("DHCP successful!");
  Serial.print("Local IP: ");
  Serial.println(Ethernet.localIP());

  Serial.print("Subnet: ");
  Serial.println(Ethernet.subnetMask());

  Serial.print("Gateway: ");
  Serial.println(Ethernet.gatewayIP());

  Serial.print("DNS: ");
  Serial.println(Ethernet.dnsServerIP());
}

void loop() {
  Ethernet.maintain();

  Serial.print("Running. IP: ");
  Serial.println(Ethernet.localIP());

  digitalWrite(STATUS_LED, !digitalRead(STATUS_LED));
  delay(3000);
}

The library used is the Ethernet.h. And below is the serial output.

And i have tried to show the status update of the ethernet on the OLED as well

Next lets configure the BLE

BLE

Initially i found that, most of the resources are using the Mbed OS to setup the BLE. After researching and also the sharing from other participant, below is the code that i am using to check the BLE.

#include <pwrseq_regs.h>
#include <pwrman_regs.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

// -------------------- Bluetooth Settings --------------------
#define BT_SERIAL Serial0
#define BT_RST    P1_6

// -------------------- OLED Settings --------------------
#define SCREEN_WIDTH 128
#define SCREEN_HEIGHT 32
#define OLED_RESET -1
#define OLED_ADDR 0x3C

Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);
bool oledOK = false;

// -------------------- HCI Commands --------------------
const byte HCI_RESET_CMD[] = {
  0x01, 0x03, 0x0C, 0x00
};

const byte HCI_READ_BD_ADDR[] = {
  0x01, 0x09, 0x10, 0x00
};

const byte HCI_LE_READ_LOCAL_SUPPORTED_FEATURES[] = {
  0x01, 0x03, 0x20, 0x00
};

// -------------------- Helper Functions --------------------
void showOLED(String line1, String line2, String line3 = "", String line4 = "") {
  if (!oledOK) return;

  display.clearDisplay();
  display.setTextSize(1);
  display.setTextColor(SSD1306_WHITE);

  display.setCursor(0, 0);
  display.println(line1);

  display.setCursor(0, 8);
  display.println(line2);

  display.setCursor(0, 16);
  display.println(line3);

  display.setCursor(0, 24);
  display.println(line4);

  display.display();
}

void setupOLED() {
  Wire.begin();

  if (!display.begin(SSD1306_SWITCHCAPVCC, OLED_ADDR)) {
    Serial.println("OLED not detected.");
    oledOK = false;
    return;
  }

  oledOK = true;
  showOLED("MAX32630FTHR", "OLED Started", "BLE Detect Test");
  delay(1500);
}

void printHexByte(byte b) {
  if (b < 0x10) Serial.print("0");
  Serial.print(b, HEX);
  Serial.print(" ");
}

void clearBTBuffer() {
  while (BT_SERIAL.available()) {
    BT_SERIAL.read();
  }
}

void configureBluetoothUART() {
  // Enable 32.768 kHz oscillator output on P1.7
  MXC_PWRSEQ->reg4 |= MXC_F_PWRSEQ_REG4_PWR_PSEQ_32K_EN;

  // Start HCI UART
  BT_SERIAL.begin(115200);

  // Swap RX/TX lines and enable CTS/RTS
  MXC_IOMAN->uart0_req |= MXC_F_IOMAN_UART0_REQ_CTS_IO_REQ |
                          MXC_F_IOMAN_UART0_REQ_RTS_IO_REQ |
                          MXC_F_IOMAN_UART0_REQ_IO_MAP;
}

void hardwareResetBT() {
  pinMode(BT_RST, OUTPUT);

  digitalWrite(BT_RST, LOW);
  delay(1000);

  digitalWrite(BT_RST, HIGH);
  delay(3000);

  clearBTBuffer();
}

bool readHCIResponse(byte *buffer, int &length, unsigned long timeoutMs) {
  length = 0;
  unsigned long startTime = millis();

  while (millis() - startTime < timeoutMs) {
    while (BT_SERIAL.available()) {
      byte data = BT_SERIAL.read();

      if (length < 64) {
        buffer[length++] = data;
      }
    }
  }

  return length > 0;
}

bool sendHCICommand(const byte *cmd, int cmdLen, const char *label, byte *response, int &responseLen) {
  Serial.println();
  Serial.print("Sending: ");
  Serial.println(label);

  clearBTBuffer();

  BT_SERIAL.write(cmd, cmdLen);

  bool gotResponse = readHCIResponse(response, responseLen, 2500);

  Serial.print("Response: ");

  if (!gotResponse) {
    Serial.println("No response");
    return false;
  }

  for (int i = 0; i < responseLen; i++) {
    printHexByte(response[i]);
  }

  Serial.println();

  return true;
}

bool checkStatusOK(byte *response, int responseLen) {
  // HCI Command Complete format:
  // 04 0E XX 01 OP_LSB OP_MSB STATUS ...
  if (responseLen >= 7 && response[0] == 0x04 && response[1] == 0x0E) {
    return response[6] == 0x00;
  }

  return false;
}

String extractBDADDR(byte *response, int responseLen) {
  // Read BD_ADDR response:
  // 04 0E 0A 01 09 10 00 XX XX XX XX XX XX
  // Address is returned LSB first
  if (responseLen >= 13 && response[6] == 0x00) {
    String addr = "";

    for (int i = 12; i >= 7; i--) {
      if (response[i] < 0x10) addr += "0";
      addr += String(response[i], HEX);

      if (i > 7) addr += ":";
    }

    addr.toUpperCase();
    return addr;
  }

  return "Unknown";
}

void setup() {
  Serial.begin(115200);
  delay(3000);

  Serial.println();
  Serial.println("MAX32630FTHR BLE Module Detection Test");
  Serial.println("--------------------------------------");

  setupOLED();
  showOLED("BLE Test", "Starting...");

  configureBluetoothUART();

  bool detected = false;
  String btAddress = "Unknown";

  for (int attempt = 1; attempt <= 5; attempt++) {
    Serial.println();
    Serial.print("BLE detection attempt ");
    Serial.println(attempt);

    showOLED("BLE Detect", "Attempt " + String(attempt), "Resetting module");

    hardwareResetBT();

    byte response[64];
    int responseLen = 0;

    bool resetOK = sendHCICommand(
      HCI_RESET_CMD,
      sizeof(HCI_RESET_CMD),
      "HCI Reset",
      response,
      responseLen
    );

    if (resetOK && checkStatusOK(response, responseLen)) {
      Serial.println("HCI Reset: OK");
      showOLED("BLE Module", "HCI Reset OK", "Reading address");

      bool addrOK = sendHCICommand(
        HCI_READ_BD_ADDR,
        sizeof(HCI_READ_BD_ADDR),
        "Read BD_ADDR",
        response,
        responseLen
      );

      if (addrOK && checkStatusOK(response, responseLen)) {
        btAddress = extractBDADDR(response, responseLen);
        Serial.print("Bluetooth Address: ");
        Serial.println(btAddress);

        bool leOK = sendHCICommand(
          HCI_LE_READ_LOCAL_SUPPORTED_FEATURES,
          sizeof(HCI_LE_READ_LOCAL_SUPPORTED_FEATURES),
          "LE Read Local Supported Features",
          response,
          responseLen
        );

        if (leOK && checkStatusOK(response, responseLen)) {
          Serial.println("LE Feature Check: OK");
          detected = true;
          break;
        }
      }
    }

    Serial.println("BLE module not ready. Retrying...");
    delay(1000);
  }

  Serial.println();

  if (detected) {
    Serial.println("BLE MODULE DETECTED SUCCESSFULLY");
    Serial.print("BD_ADDR: ");
    Serial.println(btAddress);

    showOLED(
      "BLE: Detected",
      "HCI: OK",
      btAddress,
      "LE Feature: OK"
    );
  } else {
    Serial.println("BLE MODULE NOT DETECTED");

    showOLED(
      "BLE: Not Found",
      "Check reset/UART",
      "Try board reset"
    );
  }
}

void loop() {
  // Nothing needed. The result remains on OLED.
}

And we can monitor the status on oled. The image below shows the status of the BLE on the OLED.

Now the MASTER is ready. We can now prepare the SLAVE.

Identity Protocol - Part 10 - W5500 Ethernet

arvindsa — Tue, 05 May 2026 05:09:14 GMT

Argh, Writing a good post is definitely the hard part. :D i completed interfacing all the necessary modules almost a week ago, I am also working on other projects in parallel, but this weekend, i managed to sit down and write this post. The final piece of the jigsaw in my project is to get W5500 to interface with the MAX32630.

Recap:

The idea is simple enough: stop making people swipe a card and type a PIN at every single door. Instead, the ID card (a MAX32630FTHR + ATECC508A in your pocket) unlocks once via PIN, then silently does challenge-response crypto over Bluetooth every time you walk up to a door. If the card gets yanked off you, the IMU detects the tug and it locks itself. No PIN, no entry. For more details check the Part 1 of the series

The SPI Protocol: Reads, Writes, and Verifying Connectivity

The SPI transaction requires three bytes of command header (address + block + direction) followed by one or more data bytes. The direction is in the control byte:

Read:  [ADDR_H][ADDR_L][BSB|READ |OM][DATA_IN_FROM_W5500...]
Write: [ADDR_H][ADDR_L][BSB|WRITE|OM][DATA_OUT_TO_W5500...]

RWB bit: 0 = read, 1 = write. OM (Operation Mode) is almost always 0 for variable-length reads/writes. BSB is the block selection bits to say which memory i want to access.

The first test is always the same: read VERSIONR (register 0x39 in the common block, BSB 0x00). The W5500 should respond as 0x04.

static int w5500_read(uint16_t addr, uint8_t *rx, int len)
{
    uint8_t tx[3] = {
        (uint8_t)(addr >> 8),                   /* ADDR_H */
        (uint8_t)(addr & 0xFF),                 /* ADDR_L */
        (W5500_BSB_COMMON << 3) | W5500_READ    /* control: BSB 0x00, READ */
    };
    return spi_read_write(tx, 3, rx, len);
}

uint8_t version = 0;
w5500_read(W5500_REG_VERSIONR, &version, 1);
if (version != 0x04) {
    printf("W5500 not responding. VERSIONR = 0x%02x\n", version);
    return -1;
}
printf("W5500 alive. VERSIONR = 0x%02x\n", version);

BSB = 0x00  Common registers // (VERSIONR, IP config etc.)
BSB = 1, 5, 9, 13... → Socket 0, 1, 2, 3... register space (status, control, RX/TX pointers)
BSB = 2, 6, 10, 14... → Socket 0, 1, 2, 3... transmit buffer
BSB = 3, 7, 11, 15... → Socket 0, 1, 2, 3... receive buffer


The formula for socket n:
Registers: BSB = (n * 4) + 1
TX buffer: BSB = (n * 4) + 2
RX buffer: BSB = (n * 4) + 3

Never on the same boat, I mean Voltage

But my code was being heard on deaf ears, No response. I tried going though the documentation, it's clear as day. It should work, But it did not. So, I hooked up my logic analyzer. No signals on the clock lines. Then spend an hour trying to see why the SPI peripherals is not being initiated. I even compiled the official examples, yet no avail. But then I "Accidentally" Clicked the Analog reading of the signal lines and then i saw something like an ECG. The SPI's clock line. But the logic levels was around 1.7V. And then it hit me. The chip is communicating at 1.8V levels. But W5500 Does not respond back to such levels. So first instinct, I used TXB108 Level shifter, I checked the output lines, and it was working but W5500 Never responded. I was greeted with 0xFF

Now, what i noticed is that when i reset, the MOSI was not very consistent. Ideally it was supposed to sent 0x00 0x39 0x00 0x00 (the image above has the ideal sequence) but many times i noticed, there would be extra 0xFF in between the right sequence. I felt the level shifter had to do something to with the ghost bits, In my past, the level shifter had created issues for me. Without a reliable level shifting, I was stuck, But then i remembered the MAX32630 was working fine with the I2C lines which was pulled up to 3.3V which means it is 3.3V tolerant, so i dug into the documentation to find, i can change the Logic level of the Pins on an individual level. Whoa is what i said,

By changing the IOMAN has select bits to move a pins output buffer to another voltage level (use_vddioh_0/1/2). By calling SYS_IOMAN_UseVDDIOH(&cfg) after SPIM_Init, I get a 3.3V SPI Signals

const spim_cfg_t spim_cfg = { .mode=0, .ssel_pol=SPIM_SSEL0_LOW, .baud=1000000 };
SPIM_Init(MXC_SPIM2, &spim_cfg, &sys_cfg);

const gpio_cfg_t spim2_vddioh = {
    PORT_5, (PIN_0 | PIN_1 | PIN_2 | PIN_3),
    GPIO_FUNC_GPIO, GPIO_PAD_NORMAL
};
SYS_IOMAN_UseVDDIOH(&spim2_vddioh);

Careful enough to change only the SPI lines i tried again and It is alive. W5500 was talking back 0x40.

Back to SPI Protocol

To write a register, i use

static int w5500_write(uint16_t addr, const uint8_t *tx, int len)
{
    uint8_t cmd[3] = {
        (uint8_t)(addr >> 8),
        (uint8_t)(addr & 0xFF),
        (W5500_BSB_COMMON << 3) | W5500_WRITE   /* BSB 0x00, WRITE */
    };
    return spi_write(cmd, 3, tx, len);
}

uint8_t mac[6] = {0x00, 0x08, 0xDC, 0xAB, 0xCD, 0xEF};
w5500_write(W5500_REG_SHAR, mac, 6);            /* set source hardware address */

To read a socket register, i use the the code below with the BSB calulated as per the code above

int sreg_read(int socket, uint16_t offset, uint8_t *rx, int len)
{
    uint16_t addr = offset;
    uint8_t bsb = W5500_BSB_SREG(socket);   /* computes (socket*4)+1 */
    uint8_t tx[3] = {
        (uint8_t)(addr >> 8),
        (uint8_t)(addr & 0xFF),
        (bsb << 3) | W5500_READ
    };
    return spi_read_write(tx, 3, rx, len);
}

uint8_t sr;
sreg_read(0, Sn_SR, &sr, 1);   /* read socket 0 status register */
if (sr == SOCK_ESTABLISHED) {
    /* socket is connected */
}

TCP: Open, Connect, Send, Receive, Close

The W5500 has a simple socket abstraction. Each operation sets a CR (Command Register) value and polls the SR (Status Register) for the result/

Step	Write CR	Poll SR until	Timeout
Open	`CR_OPEN`	`SOCK_INIT`	100 ms
Connect	`CR_CONNECT`	`SOCK_ESTABLISHED`	5 s
Send	`CR_SEND`	`Sn_IR.SEND_OK`	1 s
Recv	(no cmd)	`Sn_RX_RSR > 0`	per attempt
Close	`CR_DISCON` then `CR_CLOSE`	`SOCK_CLOSED`	200 ms

The So i code tcp_recv, which reads in a loop until either the buffer fills or the remote closes the connection and yes, i used HTTP1 which i copied from the regular arduino library.

static int tcp_recv(int sn, uint8_t *buf, int max_len)
{
    int total = 0;
    for (int idle = 0; idle < 100 && total < max_len; idle++) {
        uint16_t avail = sreg_r16(sn, Sn_RX_RSR);
        if (avail == 0) {
            uint8_t sr = sreg_r8(sn, Sn_SR);
            if (sr == SOCK_CLOSE_WAIT || sr == SOCK_CLOSED) break;
            TMR_Delay(MXC_TMR0, MSEC(50));
            continue;
        }
        int n = avail;
        if (total + n > max_len) n = max_len - total;
        uint16_t rd = sreg_r16(sn, Sn_RX_RD);
        srx_read(sn, rd, buf + total, n);
        sreg_w16(sn, Sn_RX_RD, rd + (uint16_t)n);
        sreg_w8(sn, Sn_CR, CR_RECV);
        total += n;
        idle = 0;
    }
    return total;
}

I did use static ip configuration for my LAN, and copied more and more working from the arduino library to interface the actual requests. Explaining that will be far too gruesome and more sleep inducing than Propofol So i will end it here. Now for the 3D printing and integration

Final Notes

When you are used to Arduino Libraries for quick prototyping, you forget to appreciate the work done by the developers to get these things working. Even porting an existing code to a diferent platform to make it work the SDK is a huge task. So respects to the Developers. Now, truth be told, My code is bit flaky and does not work 20% of the time, I am not going to solve this considering the timeline. But i will take it as a good enough work for the final integration and solve it there if needed.

Sentinel Box - Part II - back to C

saramic — Thu, 30 Apr 2026 12:42:46 GMT

I had fun with my Rust 🦀 experiment but it was time to get back to C and LPSDK (Low Power ARM Micro SDK) if I was going to get anything complete for this challenge.

Recap

The idea is to build a smart lock box for digital devices to help control digital addiction, more on the idea can be found in part I

Sentinel Box - Part I - the plan

Rust for Hermetic builds

As I was not super happy in having to depend on EOL (End-of-life) software stacks like Mbed or LPSDK, I thought, how hard can it be writing a HAL (Hardware Abstraction Layer) from scratch in Rust. I had some initial wins getting the LED flashing, so I continued. In Part I I even started implementing some commands against the MAX14690 PMIC (Power Management Integrated Circuit) - I was actually going above and beyond and looking at the schematic of the dev board to see how it hangs together. This should have turned me OFF the idea of rust, but it gave me some false hope and I continued.

The BMi160 accelerometer chip highlighted on the block diagram of the MAX32630FTHR

Next on the diagram there was an Accelerometer and Gyroscope using the BMi160 6-Axis Inertial Motion Sensor. With a bit of AI I soon enough had a driver to get X, Y, Z accelerations and using the MAX7219 I built a simple “attitude meter” which would show you which way to move the board to correct it being right way round. At this point I started to notice that some of the timing was out, my LED refresh rate was out by anywhere from 4x to 20x - that should have turned me OFF the idea of rust but with false hopes I continued.

community.element14.com/.../20260423_5F00_01_5F00_attitude_5F00_meter.mp4
The video above shows the attitude meter 🛩️ that displays on the LED matrix the direction to turn the device to flatten the chip.

These were all distractions from the core of the Smart Security Challenge, so it was time to use a finger print reader. This would need UART (Universal Asynchronous Receiver-Transmitter) surely that cannot be hard? Well this is where the speed changes of 4X – 20X really started to bite. You see if you don’t know how fast your clock speed is going, you are not going to be able to transmit or receive at a given Baud. I tried a bunch of things. As I don’t have a logic analyzer nor oscilloscope on hand, I ended up hooking up an ESP32 to measure the duration of pulses. I didn’t know there was a function to measure pulse length pulseIn

unsigned long width = pulseIn(RX2_PIN, LOW, 5000000UL); // 5 s timeout
if (width == 0) {
  Serial.println("timeout — no signal on RX pin");
  return;
}
// Filter noise: allow 1200–115200 baud = 8–833 µs.
if (width < 8 || width > 833) {
  Serial.printf("noise/glitch: %lu µs (ignored)\n", width);
  return;
}
unsigned long estimated_baud = 1000000UL / width;
  // Square-wave formula: CPU MHz = N / width_µs, where N is the delay_cycles count.
  // Firmware step 1 uses N=4800. Steps double: 4800, 9600, 19200, 38400, 76800.
  // Read the first group of pulses (smallest width) and use N=4800.
Serial.printf(
  "LOW pulse: %lu µs | sq-wave asm::delay(4800)~9600 cycles: CPU ~%lu MHz\n",
  width,
  9600UL / width); // asm::delay(N) ≈ 2N cycles → CPU MHz = 9600 / width_µs

The above code also made me realise that \n does not cut it and my serial monitor only displayed the output when I had \r\n - need that Carriage return.

And all my Rust results were conclusive on 1 part, I was never getting 96 MHz. After some digging around I found the C file in LPSDK that seems to do the setup of the frequency

Maxim/Firmware/MAX3263X/Libraries/CMSIS/Device/Maxim/MAX3263X/Source/system_max3263x.c

Enable the 32 kHz RTC oscillator — this serves as the stable reference clock for calibration, then wait for it to warm up and settle.
Enable the RO calibration complete interrupt — so the system can signal when calibration is done.
Clear the calibration complete interrupt flag — removing any stale state from a previous run.
Write an initial trim value into the frequency calibration initial condition register — giving the hardware a starting point rather than hunting from scratch.
Load that initial trim into the active frequency trim register — making it live.
Enable the frequency control loop — the hardware mechanism that will drive the RO trim toward the target frequency.
Start calibration in atomic mode — the hardware runs the measurement and adjustment cycle uninterrupted.
Wait for the ro_cal_done flag — polling until the hardware signals completion.
Stop the calibration engine.
Disable the calibration complete interrupt.
Read back the final trim value — the digital code the loop converged on.
Write the final trim to the RO flash trim shadow register — persisting the result across resets.
Restore the RTC to its previous state — since it may have been off before the routine borrowed it.
Disable the frequency control loop.

no can do - I tried and tried again but could not get a consistent 96 MHz set which meant the UART was not going to work and the rust experiment was over for the time being

❌🦀

Back to LPSDK

I couldn’t get myself to go to Mbed, a platform that is slated for EOL in July 2026, so it was back to C and the legacy LPSDK stack.

Hitting up my ESP32 setup, proved I had the right frequency set on UART and in no time I was connected to the fingerprint reader. The problem was that now my system would need to be multi modal. I pulled in a rotary encoder and got some runs on the board. First just to read turns to the left and right as well as a button press and display it on the LED MAX7219 matrix display. Then I added in the finger print reader.

community.element14.com/.../20260430_5F00_03_5F00_fingerprint_5F00_demo.mp4

Getting the fingerprint, LED Matrix and rotary encoder was the easy bit, but having a state diagram that can save a bunch of fingerprints and identify them was starting to get a bit complicated, as is the setup on my workbench.

Now that I have a basic fingerprint reader and a build system that I am confident in, I think I need to get the required piece for a minimal complete build, some kind of actuator working: stepper motor, servo motor or just a motor with a worm drive. This will allow me to create a lock box with multi finger print triggering. If I get time, I may be able to expand on that. Time will tell.

Source

https://github.com/saramic/sentinel-box

Guardian Sentinel — Getting Started

meera_hussien — Thu, 30 Apr 2026 08:39:01 GMT

Guardian Sentinel — Getting Started

<Part 2>

The figure below shows the basic block diagram and idea of how the project will be implemented. The system will consist of two parts: a master and a slave. The master will use the MAX32630FTHR and will be connected to the LAN through an Ethernet FeatherWing. It will also include a OLED FeatherWing to display status or other useful information. The slave will use another MAX32630FTHR together with the DC Motor + Stepper FeatherWing and a gas sensor. This is the basic idea of the project architecture. Along the process of building of this project i will make the necessary changes in order to accomplish the objective of this project.

As i have mentioned previously, in this second post we would like to see in details and initial setup for all the devices used in this project. First lets take a look at the core of this project which is the MAX32630FTHR.

MAX32630FTHR

From my initial research i found that the MAX32630FTHR can be programmed using MBED OS, but unfortunately it will become obsolete or end of life this coming July. Hence while looking for other alternative, i saw the post from Alistair , mentioning about using Arduino to program the MAX32630FTHR. Here is my initial setup and the step to program the MAX32630FTHR using Arduino IDE. Below is the step to program the MAX32630FTHR with Arduino IDE. Please note that, it can be only used with Arduino IDE 1.8.x. I tried using Arduino 2.3.8, but it does not work.

Once the board is installed. I tried to program the board. The setup for programming the board is as shown in figure below

Programming the MAX32630FTHR setup.

Both the usb need to be connected. The usb on the MAX32630FTHR is for power up the device. And the usb connecting the pico is for programming purpose.

Once the this is done. I try to upload a simple Blink example, to verify. First choose the board as shown in the image below

Next choose the programmer as shown in image below

Once done, i tested the simple blink program and it works. Below is the demo video

community.element14.com/.../video_5F00_2026_2D00_04_2D00_30_5F00_00_2D00_55_2D00_04.mp4

The next thing that i would like to test is the Oled FeatherWing which i am using to display the data. For connection between the MAX32630FTHR and the oled i am using the Ethernet FeatherWing. The setup for this is shown in the figure below

Once the sample code is uploaded, the oled works.

The code for the oled is as shown below.

#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

#define SCREEN_WIDTH 128
#define SCREEN_HEIGHT 32
#define OLED_ADDR 0x3C

Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire);

void setup() {
  Serial.begin(9600);
  delay(1000);

  Serial.println("MAX32630FTHR OLED Test");

  Wire.begin();

  if (!display.begin(SSD1306_SWITCHCAPVCC, OLED_ADDR)) {
    Serial.println("OLED not found at 0x3C");
    while (1);
  }

  display.clearDisplay();
  display.setTextSize(1);
  display.setTextColor(SSD1306_WHITE);
  display.setCursor(0, 0);

  display.println("Guardian Sentinel");
  display.println("MAX32630FTHR");
  display.println("OLED OK");

  display.display();

  Serial.println("OLED initialized");
}

void loop() {
}

In the next post, i will share on the Ethernet FeatherWing and also the setting up of the dashboard.

Forum #5: Proposed Design — Adaptive Sentinel: Security & Surveillance Intelligence Hub

skruglewicz — Thu, 30 Apr 2026 04:37:36 GMT

This Forum post outlines the architecture and the strategic logic driving the system’s coordination.

Design Lineage

The foundation of this design is rooted in the Adaptive Environmental Monitoring project. By leveraging that established architecture, the Adaptive Sentinel expands from purely environmental tracking into a proactive security framework, maintaining the core principles of modularity and edge-based intelligence.

Basic Design: The Architectural Framework

The system is structured around a robust hub-to-node topology, designed for high reliability and low-latency response:

Centralized Coordination: At the heart of the ecosystem is the Arduino UNO Q. It serves as the primary hub, orchestrating the network, aggregating telemetry, and managing high-level logic. The use of containerized Bricks will be helpful in carrying out these tasks without compromising the core system's stability.
Deployment of Edge Nodes: To provide a direct interface for localized relays and sensors, I intend to position edge nodes based on FeatherWing in designated building zones, acting as the primary frontline for data collection.
System Layout & Logic: The operational flow is decentralized yet unified. Edge nodes monitor local environments and transmit critical telemetry to the Arduino UNO Q hub for centralized aggregation and automated response.
Connectivity Strategy: I intend to establish a robust UART infrastructure to guarantee stability during the primary rollout. This wired setup will serve as a performance benchmark, providing a structured path for transitioning to wireless protocols after the integration has been thoroughly confirmed.
Sensor Integration:Sensor Strategic Integration: I intend to strategically select and integrate kit-supplied sensors to maximize the hardware’s efficacy in detecting security breaches and maintaining environmental awareness.

Visualizing the Hub-to-Node Topology

The following Basic Design Diagram details the mapping of FeatherWing edge nodes across various zones. By utilizing the Arduino UNO Q as the central coordinator, the architecture remains scalable.

Hub-to-Node Connectivity Design: This system utilizes a robust hub-to-node topology centered on an Arduino UNO Q coordinator, managing modular FeatherWing edge nodes for localized intelligence. The initial rollout employs a stable UART connectivity strategy. The edge nodes are deployed in two primary functional configurations: Edge Node 1 for Biometrics & Sentiment Analysis, and Edge Node 2 for Active Response & Environmental Control.

HUB Node Architecture: Built on the Arduino UNO Q, the central hub functions as the primary network coordinator, aggregating telemetry from FeatherWing edge nodes. This architecture leverages a dual-processor system where the MPU handles high-level orchestration, intensive data logging, and serving the Web UI, while the MCU manages deterministic low-level communication protocols. Furthermore, the system utilizes a specialized Database BRICK to ensure the reliable storage of all telemetry data streamed from the distributed edge nodes.

Edge Node Architecture: Edge nodes are implemented as modular expansion subsystems. The current deployment strategy utilizes the following functional configurations for localized intelligence.

Edge Node 1 (Biometrics & Sentiment Analysis): This node focuses on human-centric data, monitoring biometric signatures and localized sentiment to assess security states based on occupant presence and behavior.

Edge Node 2 (Active Response & Environmental Control): Serving as the primary execution layer, this node manages physical relays and automated control systems to mitigate identified threats or adjust climate variables in real-time.

The "Request for Help"

Before I finalize the Project Blog and lock in the implementation, I am reaching out to the community. Prior to finalizing the Project Blog and committing to this implementation, I am seeking community insights. I invite you to "identify any loopholes" or logical flaws in my current approach.

Specifically, I am interested in your thoughts on whether the transition from UART to wireless is technically sound and if there are hidden bottlenecks in the hub-to-node telemetry aggregation. My goal is to uncover any technical gaps in the orchestration of this security intelligence system before moving to final deployment.

I value your expertise and look forward to the feedback.

BLE scanning and CC256X firmware uploading

Alistair — Tue, 28 Apr 2026 12:02:18 GMT

After thinking I had everything in place I have just got wound to the BLE scanning, and it turns out that it it not working. Basic Bluetooth functionality appraiser fine, but the BLE functionality is not there. Doh!

Following a hint from online I trued the command 01 01 FE 01 00 (HCI_VS_Write_BD_Addr) and that returned 0x01 (Unknown HCI Command), and that shown new firmware needs uploading. Has anyone done this?Any other suggestions for that matter?

Identity Protocol - Part 9 - BLE GATT Challenge/Response with BTstack

arvindsa — Tue, 28 Apr 2026 06:01:28 GMT

It has been long time since i used Bluetooth SPP. Infact I do not think I ever used Bluetooth SPP via firmware. I think i used an RN42 module to get UART converted to Bluetooth SPP. But I have used BLE GATT so, I will be using that to exchange data between the Door and ID device.

Recap:

GATT Service Definition

BTstack generates an ATT database at plaintext .gatt file. Refer: https://github.com/bluekitchen/btstack/blob/master/tool/compile_gatt.py For our purpose, I need to detect the door and ID card to be nearby, one service to write the nonce and another for the response. I did take help of ChatGPT to generate the file. If you are new to GATT - I recommend to watch this video - www.youtube.com/watch

PRIMARY_SERVICE, GAP_SERVICE
CHARACTERISTIC, GAP_DEVICE_NAME, READ, "Auth-Door"

PRIMARY_SERVICE, GATT_SERVICE
CHARACTERISTIC, GATT_DATABASE_HASH, READ,

// Identity Protocol Auth Service
PRIMARY_SERVICE, AAAAAAAA-0000-0000-0000-000000000001

// CHALLENGE: 32-byte nonce sent by the door, read by the card
CHARACTERISTIC, AAAAAAAA-0000-0000-0000-000000000002, READ | DYNAMIC,

// RESPONSE: 4-byte device_id followed by 64-byte signature written by the card
CHARACTERISTIC, AAAAAAAA-0000-0000-0000-000000000003, WRITE | DYNAMIC,

For Testing two Roles, One Source File

Both the door and the card run on identical hardware (MAX32630FTHR + PAN1326B), so the test is a single C file compiled twice. A ROLE make variable drives the split:

make ROLE=server    # door firmware
make ROLE=client    # card firmware

-DROLE_SERVER / -DROLE_CLIENT select which half of gatt_auth.c is compiled. The server advertises, serves CHALLENGE when ID card nearby, and verifies writes to RESPONSE. The client scans, connects, reads CHALLENGE, signs, and writes RESPONSE.

The Server Side (Door)

The server's packet handler wakes up three places: stack ready, client connected, and every ATT write. When client connected, we serve the once, when ATT writes to the signature service, we verify it.

Even though i have only one feather to function as a ID device, i made the firmware such that it can store multiple ID Cards device name and their public key to be synced from the Django server.

if (att_handle != RESPONSE_VALUE_HANDLE) return 0;

if (buffer_size != 68) {
    printf("VERIFY FAIL, expected 68 bytes, got %u\n", buffer_size);
    return 0;
}

uint32_t device_id = (buffer[0] << 24) | (buffer[1] << 16)
                   | (buffer[2] << 8)  |  buffer[3];
const uint8_t *sig = buffer + 4;

// Serch for the public key from the flash. 
const uint8_t *pubkey = lookup_pubkey(device_id);
if (!pubkey) { 
    /* unknown device (not in django server, reject */ 
    return 0; 
}

// Generate the digest via the crypto chip
uint8_t digest[32];
atcac_sw_sha2_256(nonce, 32, digest);


// Verify using micro-ecc
int ok = uECC_verify(pubkey, digest, sig);
printf(ok ? "*** VERIFY PASS ***\n" : "*** VERIFY FAIL ***\n");

The Client Side (Card)

The client we make a state machine:

typedef enum {
    STATE_IDLE,
    STATE_SCANNING,
    STATE_CONNECTING,
    STATE_DISCOVER_SERVICE,
    STATE_DISCOVER_CHARS,
    STATE_READ_CHALLENGE,
    STATE_WRITE_RESPONSE,
    STATE_DONE,
} client_state_t;

On HCI state HCI_STATE_WORKING the client calls gap_start_scan() and watches for advertisements under name "Auth-Door". When it sees one, we execute gap_connect. once the state advances to STATE_DISCOVER_SERVICE and a gatt_client_discover_primary_services_by_uuid128 call goes out with the auth service UUID.

During the STATE_READ_CHALLENGE phase , the 32 byte nonce has arrived from the server, the client hashes it, packs its own device ID into the first four bytes of the response buffer, and calls atcab_sign:

uint8_t digest[32];
atcac_sw_sha2_256(challenge, 32, digest);

response_buf[0] = (CLIENT_DEVICE_ID >> 24) & 0xFF;
response_buf[1] = (CLIENT_DEVICE_ID >> 16) & 0xFF;
response_buf[2] = (CLIENT_DEVICE_ID >>  8) & 0xFF;
response_buf[3] =  CLIENT_DEVICE_ID        & 0xFF;

atcab_sign(0, digest, response_buf + 4);

gatt_client_write_value_of_characteristic(
    handler, conn_handle, response_handle, 68, response_buf);

The device_id is the lower four bytes of the ATECC508A serial number which we saved during provisioning and locking of the chip along with it's public key. This is the same four bytes the server will look up in its static keystore to find the public key.

The ID Card's LED lights up green when connecting to the door device and the door device's LED turns green when the signing of nonce by ATEC508A is successfully verified by micro-ecc

Result

With both bugs sorted, the UART log across two boards looks like this on a clean run.

community.element14.com/.../blegatt.mp4

Again, i am using a PCB which i designed for a client to work like an breakout board for the ATTEC508A. Hence the blur. After a successful verification, the door devices starts readvertising and i do have to reset the ID card to re-auth again.

Final Notes

Again, thanks to BTStacks awesome documentation, this was an easy three hour work after setting up ATECC508A. There was some hold up due to typo in the micro-ecc bundled by BTStack, which i thought was my problem but later I realized it was a bug. I did write the public key manually in the lookup table for this unit test, in the final unit test, I will interface W5500 to sync the public keys to the feather board.

Using the Particle Ethernet FeatherWing with the MAX32630FTHR (Don't Forget to Set)

Alistair — Mon, 27 Apr 2026 20:29:29 GMT

For my project I am using the Particle Ethernet FeatherWing to allow the MAX32630FTHR to communicate with the local network and enable my alarm.

The Particle Ethernet FeatherWing is based around the WIZnet W5500 and under normal circumstances will work with the standard Arduino Ethernet library version 2.0.0+. This is however not compatible with the older Maxim core. It took a while but I worked round the problem, and here is my solution just in case it is helpful to someone else.

Before we get into the software, we need to add some header pins to the MAX32630FTHR. My advice is to loosely place the pins in the FeatherWing and quickly solder on the corner pins. After that the header pins are held in place and the rest of the pins will be so much easier to solder.

My work around with the Arduino IDE 1.8 it to this is to use the older Ethernet2 library, that is a drop in replacement to the version 1 Ethernet library but supports the W5500. This addresses most of the issues, but we still need to copy across a few files to get this to work. Here are the setup instructions...

First install the Ethernet2 library from the Arduino library manager (Sketch->Include Library->Manage Libraries…).

Once installed we need to copy the following files from the Arduino AVR core "%homepath%\Documents\ArduinoData\packages\arduino\hardware\avr\1.8.6\cores\arduino" to the Ethernet2 library directory "%homepath%\Documents\Arduino\libraries\Ethernet2\src".

Client.h
Server.h
IPAddress.h
IPAddress.cpp
Udp.h

I will note that although it would make more sense to copy the missing files to the Mamim core ("%homepath%\Documents\ArduinoData\packages\Maxim\hardware\arm\1.1.5\cores\arduino") and not the Ethernet2 library, but doing this uncovers yet more issues that need to be addressed, so lets take the easy road on this occasion.

So after this modification, and including Ethernet2.h instead of Ethernet.h our standard Ethernet applications will compile but not run. We still need to tell the library what pin to use in our setup code. From the schematic we can see the chip select is on pin 22 if the featherwing connector (traditionally GPIO10) and that is mapped to pin 7 on CON12 (P5.4 /SDIO 2) according to the MAX32630FTHR schematic.

So, in English, just add “Ethernet.init(P5_4);” to setup() before calling “Ethernet.begin”.

And that is it. Here is a cut down version of the WebClient example to set with…

#include <SPI.h>
#include <Ethernet2.h>

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
char server[] = "www.google.com";

EthernetClient client;

void setup() {

Serial.begin(115200);
Serial.println("Starting...");

Ethernet.init(P5_4);
Ethernet.begin(mac);

delay(1000);
Serial.println("connecting...");

if (client.connect(server, 80)) {
Serial.println("connected");

client.println("GET /search?q=arduino HTTP/1.1");
client.println("Host: www.google.com");
client.println("Connection: close");
client.println();
}
else {
Serial.println("connection failed");
}
}

void loop()
{
if (client.available()) {
char c = client.read();
Serial.print(c);
}

if (!client.connected()) {
Serial.println();
Serial.println("disconnecting.");
client.stop();
while (true);
}
}

Identity Protocol - Part 8 - Cryptographically Sign with ATECC508 and Verify with Micro-ECC

arvindsa — Mon, 27 Apr 2026 18:35:36 GMT

Fair warning, this one is gonna be a hard read. I have used ATECC508A Crypto chip in my work extensively, so I've grown quite comfortable with it. I had couple of chips left over from that work and was delighted to use this challenge to use the Crypto chips again and more importantly document the process in the public. Now, The full datasheet is protected in NDA and you get a very restricted Datasheet online.

Recap:

Why a Secure Element?

People who were frustrated that their Windows 10 couldnt be upgraded to Windows 11 due to TPM not being available in their device will ask. Why? Because TPM is a secure element, keeps things safe. Similarly this one keeps secrets safe. If you need a refresher into cryptographic encryption should watch the videos below

With the knowledge of the Public and Private key, the question is how can you make a private key secure in an electronics? You can't save in MCU flash, you can dump the firmware and extract it. There are basic protections against it, but it can be countered as well, the private key extracted and the device duplicated. Enter Secure Elements like ATECC508A. This contains specially designed silicon die that you cannot extract the keys, in fact, the keys are generated on the chip and the private key never leaves the chip. You cant even save a private key on the chip for storage, it beats the trust factor. Once the private key is generated, it secure. We can ask the chip to sign a nonce and return the signed value. The keys are stored in slots; access policy for each slot is baked into a "config zone" that you write once and then permanently lock. After the lock there is no going back -- the chip's behaviour is frozen for life.

ATECC508A Primer

The chip's I2C address is 0x60 .It has four power states:

Sleep - default on power-up;
Idle - after the wake pulse, between commands; Note that "TempKey" (a 32-byte scratch buffer used by Sign and other commands) is preserved in idle but lost in sleep.
Active - executing a command
Wake transition - triggered by holding SDA low for at least 60 us.

Every transaction follows the same protocol - wake pulse, send a packet composed of [word_addr | count | opcode | param1 | param2 | data | crc16], wait the per-command execution time (Sign takes 58 ms, GenKey 115 ms, Write 26 ms, etc refer the datasheet for the timing.), read the response, then send a 1-byte "idle" or "sleep" word.

The Wake Trick

The datasheet says "hold SDA low for at least 60 us." There is no I2C primitive that does this directly -- I2C masters drive START, address, data, STOP, never a flat 60 us LOW. So either i have to run it as a GPIO and then start I2C. But

Microchip's cryptoauthlib's reference HALs recommend you to to fire an I2C write transaction at slave address 0x00. No real device responds to 0x00, so the master sends START + the 8-bit address byte, gets no ACK, and gives up. But during those 8-9 bit times at 100 kHz, SDA spends most of its time LOW -- about 80 us LOW total.

case ATCA_HAL_CONTROL_WAKE: {
    uint8_t zero = 0x00;
    /* Write to addr 0x00 -- NACK is expected, we use this to flatten SDA */
    I2CM_Write(ATCA_I2C_BUS, 0x00, NULL, 0, &zero, 1);
    hal_delay_ms(WAKE_DELAY_MS);   /* tWHI = 1.5 ms */

    uint8_t wake_resp[4] = {0};
    int ret = I2CM_Read(ATCA_I2C_BUS, addr, NULL, 0, wake_resp, 4);
    if (ret != 4) return ATCA_WAKE_FAILED;
    const uint8_t expected[4] = {0x04, 0x11, 0x33, 0x43};
    if (memcmp(wake_resp, expected, 4) != 0) return ATCA_WAKE_FAILED;
    return ATCA_SUCCESS;
}

CryptoAuthLib HAL: One File

CryptoAuthLib is Microchip's reference C library for the ATECC family. It has all the device-side logic (packet construction, CRC, retry policy, all the opcodes) but expects you to provide a small HAL. This is mentioned in their documentation https://github.com/MicrochipTech/cryptoauthlib/blob/main/lib/hal/README.md . The relevant 4 Functions written in hal_maxim_i2c.c

HAL function	What it does
`hal_i2c_init`	Bring up I2CM1 MAP_A (P3_4=SDA, P3_5=SCL) at 100 kHz
`hal_i2c_send`	Prepend word-address byte to payload, write via `I2CM_Write`
`hal_i2c_receive`	Read N bytes via `I2CM_Read`
`hal_i2c_control`	Implement WAKE (SDA-low trick), IDLE (write 0x02), SLEEP (write 0x01)
`hal_delay_ms/us`	Wrap LPSDK `TMR_Delay`

Now, when i started writing the HAL, I inadvertently chose to use an dedicated I2C, used a PCB board from my past work to interface it, so gonna be pixelating the board, It's a simple PCB but it is my policy, I did have to enable the PMIC to enable 3.3V on L3OUT. Now, had i used the I2CM2 which is shared with PMIC and IMU, i would not have seen the crypto chip working and would have had an meltdown. This is because I2CM2 uses I2C pull-ups to 1.8V but ATECC508 requires 3.3V. I think the minimum is some 2v.

Provisioning the Chip

The ATECC508A ships with its config zone unlocked and writable. Provisioning is a four-step rite of passage:

Write the config zone - 128 bytes that describe what every slot can do.
Lock the config zone - after this, the slot policies are frozen.
GenKey in slot 0 - the chip generates a fresh P-256 key pair internally.
Lock the data zone - after this, no further keys can be written or generated.

Steps 2 and 4 are irreversible. If the config bytes for slot 0 are wrong, you cannot fix them after the lock. So I wanted this to run from a Python script on my laptop where I could see exactly what was being written, dry-run it, and read back to verify, rather than baking the policy into firmware. Unfortunately, I cannot share the Python script because it's sort of paid by my client. Sparkfun who does sell these chips advice you to buy many extra chips in case we mess up.

The Config Zone Template

The 128-byte config zone is a packed bag of bit fields: SlotConfig (16 entries, 2 bytes each), KeyConfig (16 entries, 2 bytes each), Counter[0:1], LastKeyUse, LockValue, LockConfig, ChipOptions, X.509 hints, etc. For this PoC I only care about slot 0:

Field	Value	Meaning
Slot 0 SlotConfig	`0x8720`	IsSecret=1, ReadKey=7, WriteConfig=2 (GenKey allowed)
Slot 0 KeyConfig	`0x0033`	KeyType=4 (P-256), Private=1, PubInfo=1, Lockable=1

IsSecret=1 is the line that matters most -- it means the slot's contents (the private key) are never returned by Read. WriteConfig=2 allows GenKey to populate the slot but blocks raw writes. PubInfo=1 makes the public key derivable via GenKey(slot, mode=read), which is how the script reads it back after locking.

The other 15 slots get permissive policies (0x8F0F / 0x3C00) so they could be used later, but for the this project they remain empty.

Signing on the ATECC

Once the chip is provisioned, signing a 32-byte digest is a two-command sequence:

Nonce pass through (opcode 0x16, param1=0x03) -- loads a 32-byte value into TempKey directly, bypassing the chip's internal nonce generation.
Sign external (opcode 0x41, param1=0x80, param2=slot index) -- signs the contents of TempKey with the P-256 private key in the given slot. Returns a 64-byte signature, with no ASN.1 wrapping. I used ASN,1 a lot, but never understood it.

The reason this is two commands instead of one is that the chip's "internal" Sign mode is designed for signing data the chip itself generated (like its own random number plus a counter). For our use case -- signing an external challenge -- we have to load the digest manually, which is what the Nonce passthrough does.

Verifying on the Door

The door device does not have an ATECC508A. Actually In the original proposal i wrote it, but to load all public key from django server is an impossible task, Then i thought, It only needs to verify signatures, not generate them. ECDSA verification is purely arithmetic with public values. there is no key to hide, so no need of secure element, so a software library is enough. I picked Kenneth MacKay's micro-ecc,

It is dropped in as a git submodule under third_party/micro-ecc/. The verify call is one line:

int ok = uECC_verify(pubkey64, digest, 32, signature64, uECC_secp256r1());

Where pubkey64 is the X || Y coordinates (no SEC1 0x04 prefix), digest is the 32-byte SHA-256 of the challenge, and signature64 is the raw singature rteturned in returned by atcab_sign. (Step 2 above).

The End-to-End Bench Test

The same provision-verify firmware full crypto chain on a single board. After provisioning, two extra commands via serial will test the generation of nonce, signing via ATEC508A and veriofication via micro-ecc

Command	Action
`k`	Read public key from slot 0 via `atcab_get_pubkey` and print 128 hex chars
`d`	ADC-noise nonce -> SHA-256 -> sign(slot 0) -> read pubkey -> `uECC_verify`; print PASS/FAIL

The Nonce Generation Confusion

For sake of my own sanity, i will tell you i tried using the MAX32630 "PRNG' which stands for Pseudo Random Number Generator which surprisingly gave me a constant number always i think It stands for "Persistent, Reluctant Number Guy" with so many work arounds nothing worked. So i went to the age old method of using the ADC. Sample 32 times across 4 channels (128 samples), mix into a 32-bit accumulator with rotate-left-3 + XOR, then expand to 32 bytes via xorshift32: I took this code from somewhere in my past work, It is not really my work, But I've used it successfully.

uint32_t seed = 0;
for (int round = 0; round < 32; round++) {
    for (int i = 0; i < 4; i++) {
        uint16_t val = 0;
        ADC_StartConvert(ch[i], 0, 0);
        ADC_GetData(&val);
        seed = ((seed << 3) | (seed >> 29)) ^ (uint32_t)val;
    }
}
if (seed == 0) seed = 0xA5A5A5A5u;   /* edge case: all channels read 0 */

This produces a different nonce on every reset, verified by capturing NONCE : lines across many reset cycles and checking for repeats (none, ever).

Code for this particular post is available at https://github.com/arvindsa/identity-protocol-e14-challenge/tree/main/firmware/tests/provision-verify
Code for entire project is available at https://github.com/arvindsa/identity-protocol-e14-challenge

Final Notes

We used a decade old crypto algorithm using both an Hardware chip and an software library. My head is boiling trying to ascertain if my post is understandable, if not let me know i will try to rewrite this. Next is using GATT to enable exchange of NONCE and signed digest. The work is done, I just have to write the post

Forum#4 - Communication Framework - Adaptive Sentinel: Security & Surveillance Hub

skruglewicz — Mon, 27 Apr 2026 06:23:46 GMT

Building the UART Communication Framework

Welcome back to the Adaptive Sentinel project! In this fourth installment of our design challenge journey, we are moving beyond individual sensor nodes and focusing on the "nervous system" of our ecosystem: the Communication Framework.

The goal here is simple yet critical: establishing a rock-solid, end-to-end communication link between our two MAX32630FTHR edge nodes and the Arduino UNO Q central hub.

The Architecture: A Wired Backbone

While wireless is often the go-to for IoT, we’ve opted for a robust UART Backbone for this phase. By utilizing direct pin headers and USB interfaces, we bypass the latency and reliability issues often found in crowded wireless environments. This ensures that our telemetry data arrives exactly when we need it.

The "Dual-Brain" Advantage

The heart of our system, the Arduino UNO Q, is doing some heavy lifting here. We are leveraging its unique Dual-Brain architecture to maintain system stability:

STM32 MCU: Handles the "deterministic" side of things—managing the low-level inter-node communication protocols with precision.
Qualcomm Dragonwing MPU: Takes charge of high-level orchestration, including intensive data logging and serving the Web UI.

Implementation & Logic

To keep the system modular and maintainable, we've developed a core validation suite centered around two primary functions: SEND() and RECEIVE().

Edge Node Logic (MAX32630FTHR)

Each edge node is responsible for packetizing its own status. To keep the hub organized, every transmission includes a unique NODEID. Whether it’s raw sensor telemetry or a simple status string, the hub always knows exactly who is talking.

Hub Aggregation

On the hub side, the Arduino UNO Q acts as the ultimate aggregator. Because it can process high-bandwidth streams from multiple nodes simultaneously, we achieve a level of responsiveness that keeps our security intelligence "live" and actionable.

Pseudocode Snapshot:

SEND(): Facilitates outbound message transmission with packet headers.
RECEIVE(): Captures incoming strings and outputs data to the terminal for real-time monitoring.

We Need Your Help!

As we move toward the final showcase of the Adaptive Sentinel, we want to ensure this framework is bulletproof.

Community Challenge: We’re looking for "stress testers." Can you spot any potential bottlenecks or "loopholes" in our UART flow? How would you push this wired architecture to its limits?

Leave your thoughts in the comments below!

Next Up: Stay tuned for Forum #5, where I bring it all together with my design and implementation path for the Final Project

Identity Protocol - Part 7 - Colouring on the ICLED FeatherWing

arvindsa — Thu, 23 Apr 2026 14:12:29 GMT

LEDs has been a major part of my projects and I love working with it. My son also loves to see the things i do with my LEDs. In this part i make colors appear on the ICLED Featherwing

Recap:

The ICLED FeatherWing is on the door device. It displays status icons: a blue key (waiting), yellow lock (authenticating), green tick (granted), red cross (denied), and magenta sync arrows (server update). 105 LEDs arranged in a 7x15 column-major matrix, single data wire in, GRB colour order. Full source is in `firmware/tests/icled-timer/` (TMR4 hardware PWM) in the project repo.

The WS2812B Protocol

The IC LED FeatherWing contains 1312020030000 LED which i loved working with in my previous challenge AuraAlert - Lighting up Every Sound. Seriously bright with awesome colors. It uses the popular WS2812B Protocol. In the Previous challenge, i never bothered with the protocol as i was using Arduino library to take care of it. This time I have been challenged to make the protocol code from scratch.

The Protocol is quite simple

For starting a frame, send a 50uS low
Each LED grabs the first 24 bits of incoming data (8 bits each for green, red, blue) and forwards everything else downstream.
There is no separate clock line, and so '0' and a '1' are distinguished only by how long the wire stays HIGH within a fixed 1.25 us window.
'0' is when there is 0.35uS high (T0H) followed by 0.9us of low (T0L)
'1' is when there is 0.9us of high (T1H) followed by 0.35us of low (T1L)
In this fashion, i have to provide 8 bit values of LED for Green, Red and blue (in this order)

Credits: https://mcuoneclipse.com/2016/05/22/nxp-flexio-generator-for-the-ws2812b-led-stripe-protocol/

I miss my STM32s

Even though most of time I use Arduino Core for STM32 for developing a project fast, there are times when for serious production work, I had to use STM32Hal. There the approach is well established: configure a timer in PWM mode, hook a DMA channel to the timer's CCR register (Capture/Compare Register), fill a buffer with duty-cycle values for every bit, and fire it off. The CPU is completely free during the transfer. One call to `HAL_TIM_PWM_Start_DMA()` and you are done. The DMA engine pushes each duty value into the compare register on every timer period, producing a continuous PWM waveform with the right T0H/T1H timing. No CPU involvement, no interrupt-disable window.

The MAX32630 does not have this functionality, or it probably does and I can't find it. For now, there is no equivalent of the STM32's TIMx_CCR DMA burst mode. So I have two options:

Bit-bang with NOPs: toggle GPIO directly, pad timing with NOP instructions
Hardware PWM with polled duty update - use the timer in PWM mode but update the duty register manually each bit period

Approach 1: NOP Bit-Bang

Easy to code, very unreliable. Drive a GPIO pin HIGH, wait the right number of NOPs for either a '0' bit or a '1' bit, then drive it LOW, wait again, and repeat. A NOP is "no operation" is a CPU instruction that does literally nothing for one clock cycle. Essentially it like delay() but at a more assembly level. Join many NOPs to get a precise, calibrated delay.

The Feather is clocking at 96 MHz, one CPU cycle is ~10.4 ns. But NOPs do not take exactly one cycle due to APB bus write latency when toggling GPIO. I measured the effective NOP rate at 10.85 ns/NOP by capturing waveforms on a scope.

I tried a lot, but I never got the LED working at all. So I decided to let it rest. At 7x15=105 Led's it will take around 3.2ms for sending data to the LEDs, that will not play well with my 50hz IMU data reading.

Approach 2: Hardware PWM with Polled Duty (icled-timer)

Let the timer peripheral generate the precise waveform timing, and the CPU only needs to update the duty register between bit periods.

Pin-to-Timer Mapping

The MAX32630 maps GPIO pins to timers with the formula (see SYS_TMR_Init in the LPSDK's mxc_sys.c):

timer_index = (port * 8 + pin) % num_timers

For P5_6: (5*8 + 6) % 6 = 4, so P5_6 maps to TMR4. This is the integration target pin for the ICLED DIN on the door device (D13 header position on the FeatherWing).

Timer Configuration

At 96 MHz with prescale TMR_PRESCALE_DIV_2_0 (which is divide-by-1, not divide-by-2; the name refers to 2^0), one tick = 10.42 ns.

Parameter	Ticks	Time
Period (1.25 us)	120	1250 ns
T0H duty	38	396 ns
T1H duty	77	802 ns

The timer runs in 32-bit PWM mode. On each period rollover, the counter resets to 0 and the output goes HIGH. When the counter reaches the duty value, the output goes LOW. So by writing 38 ticks as duty we get a ~400 ns HIGH pulse (a '0' bit), and 77 ticks gives a ~800 ns HIGH pulse (a '1' bit).

The Pre-Frame Buffer

Before starting the transfer, the entire frame is pre-computed into a duties[] array, one entry per bit, 105 LEDs x 24 bits = 2520 entries. Each entry is either DUTY_T0 (38) or DUTY_T1 (77).

static uint8_t duties[NLEDS * 24];

/* Build duty array from bitmap */
int idx = 0;
for (int led = 0; led < NLEDS; led++) {
    int col = led / ROWS;
    int row = led % ROWS;
    uint8_t bytes[3] = { pg, pr, pb };   /* WS2812B order: G, R, B */
    for (int i = 0; i < 3; i++)
        for (int bit = 7; bit >= 0; bit--)
            duties[idx++] = ((bytes[i] >> bit) & 1) ? DUTY_T1 : DUTY_T0;
}

The inner loop is simple: poll for the timer's rollover flag, clear it, write the next duty value. The timer hardware handles the precise HIGH/LOW timing. The CPU just needs to update the duty register within the 38-tick window (T0H) of the current bit, plenty of time for a poll+clear+write that takes ~10 cycles.

for (int i = 1; i < NLEDS * 24; i++) {
    while (!TMR32_GetFlag(MXC_TMR4));
    TMR32_ClearFlag(MXC_TMR4);
    TMR32_SetDuty(MXC_TMR4, duties[i]);
}

The Bug That Corrupted Every First Pixel

This is where i spent most of the debugging time. The first pixel was always wrong: LED 0 had a persistent green tinge regardless of what colour i sent. Every other LED was perfect. It turned out by looking at my Logic analyzer that When the PWM timer is stopped, its output pin idles HIGH. Calling GPIO_Config(&din_tmr) to switch the pin from GPIO mode to timer mode immediately connects it to the HIGH timer output. So bit 7 of the first byte (G channel) was always read as a '1' by the strip, regardless of the actual data.

The Fix: Warmup Period + Direct Register Write

The fix is to start the timer while the pin is still in GPIO output-LOW mode. This was experimental, but it worked, I guess the strip sees the LOW as an extension of the reset period. We wait for the first period rollover. Then we switch the pin to timer mode via a single func_sel register write instead of the full GPIO_Config call: Thanks to ChatGPT in helping me solve this.

/* Start timer, pin stays GPIO LOW, strip sees reset */
TMR32_SetCount(MXC_TMR4, 0);
TMR32_SetDuty(MXC_TMR4, duties[0]);
TMR32_ClearFlag(MXC_TMR4);
TMR32_Start(MXC_TMR4);

while (!TMR32_GetFlag(MXC_TMR4));   /* warmup */
TMR32_ClearFlag(MXC_TMR4);

/* count=0, output=HIGH: connect pin now, bit 0 starts cleanly */
MXC_GPIO->func_sel[5] = (MXC_GPIO->func_sel[5] & ~MXC_F_GPIO_FUNC_SEL_PIN6)
                       | (MXC_V_GPIO_FUNC_SEL_MODE_TMR << MXC_F_GPIO_FUNC_SEL_PIN6_POS);

This is the waveform of full brightness of one single LED. This was taken when i used one single WS2812B 5050 with adafruit adapter to test out if the green led bug was not repeated on a known led. Fixed the problem while it was attached on it. Forgot to capture waveform on the ICLED. I promise to take better waveform capture in the future.

LED Matrix Layout

The ICLED FeatherWing is wired such that LED0 is top-left (row 0, col 0), LED 6 is bottom-left (row 6, col 0), LED 7 is top of column 1 (row 0, col 1), and so on. This is considerably different from the Serpentine wiring in the projects i've done at Connect 4 Game or even a recent Custom LED Matrix screen which I had built for a client

LED index = col * ROWS + row

This means when sending pixel data, we iterate through columns left to right, and within each column top to bottom. The bitmap arrays in the code are stored as [row][col], so the send loop does the transpose:

The Five Auth-State Icon

I designed five 7x15 pixel bitmaps for the door device status display. Two examples in ASCII art below; all five are in

. X X X . . . . . . . . . . .
X . . . X . . . . . . . . . .
X . . . X X X X X X X X X . .
X . . . X X X X X X X X X . .
X . . . X . X . X . X . . . .
X . . . X . . . . . . . . . .
. X X X . . . . . . . . . . .


. . . . . . . . . . . . . X X
. . . . . . . . . . . X X X .
. . . . . . . . . X X X . . .
. X X . . . . . X X . . . . .
. . X X . . . X X . . . . . .
. . . X X . X X . . . . . . .
. . . . X X X . . . . . . . .

Results

All five icons cycle correctly at matched brightness on the 7x15 matrix, with no LED 0 corruption after the warmup fix. The icons are distinct and readable from about 2 meters away even at these low brightness levels. The values i am sending are like (10,0,0), (5,0,5) etc out the max possible (255,255,255). I remember bitluni talking about how bright these get. Take a look here - https://youtu.be/oz9Ys7CR7cw?si=4rfxHv0VRZoPAYYE&t=736 (t=2:18 onwards)

Code for this particular post is available at https://github.com/arvindsa/identity-protocol-e14-challenge/tree/main/firmware/tests/icled-timer
Code for entire project is available at https://github.com/arvindsa/identity-protocol-e14-challenge

Final Notes

Coming from STM32 where WS2812B driving is a solved problem (timer + DMA, done), doing it on the MAX32630 was an interesting exercise in working within hardware constraints. The polled PWM approach works well, I do not know if there is a better way to implement this, but since this works i am gonna be happy about it.

Also, I received my Proto PCB order today. This time I am not going to make a custom PCB's. I do Custom PCBs only when i intend to use the project at-least occasionally. This is a very niche project which i am targeting only as a actual challenge to question my embedded skills and more importantly something out of my comfort zone. Plus i have my PCB budget on something else which i will reveal soon.

Anyone using the Particle Ethernet Feather with the MAX32630FTHR

Alistair — Thu, 23 Apr 2026 10:52:09 GMT

I had a few moments free last night and decided it was time to get the networking working on my project. I have used WIZnet based Ethernet modules many times with great success and was not anticipating any issues, but I am getting compilation errors in the Arduino IDE when targeting the MAX32630FTHR. The summary version of this is the standard Ethernet library that should work, expects some files are in the [more recent] Arduino cores and not in the Maxim one.

Has anyone had the same issues? Anyone got a simple solution?

My plan is to dig in to the cores some more, but my suspicion is that around Arduino 1.8 some of the Ethernet library was moved in to the core, so any other hardware cores that did not support this no longer work with the stock library. If so I guess I have two options. One being to copy the missing files from the Arduino core to the Maxim core. The other to use an older Ethernet library that still have the moved files in it.

Any thoughts?

Sentinel Box - Part I - the plan

saramic — Tue, 21 Apr 2026 14:42:49 GMT

The Idea

My house has a problem every parent recognises: devices. Tablets, phones, controllers, earbuds as well as the odd jar of nutella, lollies and chocolate — the endless negotiation about screen time, bedtime, weekend limits and self control. As a family we have tried various self control mechanism, device only zones, apps and even a time locking container. All have been defeated. The closest was the time locking container, except that once set, there is no override - you lock your phone in for 2 days, that's it. Also it had poor battery life and not big enough to fit a laptop or block of chocolate.

The Smart Sentinel Box is a Perspex vault that physically locks devices inside, and can only be opened by a "complex" and orchestrated process of more than one party. The key is that it can be opened, just that more than one person needs to make that decision, someone with opening rights. The orchestrated part just means I can add more elaborate mechanisms as I learn to work with the MAX32630FTHR. Simple ones first — a button, finger print reader, a tap pattern — escalating to genuinely absurd ones: an audio quiz streamed from a cloud lambda, a TOTP NFC card that expires every 30 seconds, requiring both parents' fingerprints simultaneously, or a GPS geofence that locks the box if it gets carried to a different room. Maybe through in a wake word as well.

There's also a honeypot button — clearly labelled "EASY UNLOCK". It plays a fake unlocking sound, does nothing, and silently texts both parents. Kids will be furious.

The plan is to make the MAX32630FTHR the brain orchestrating everything around it.

Order placed and MAX32630 arrived

I was not lucky enough to get selected for a sponsored pack, but as I am new to the Element14 Design Challenge community, I didn’t want to give up that easy. I placed an order and the MAX32630 arrived. As I was waiting I was intrigued by all the not so trivial posts on the setup required to program the MAX32630. It seems that the platform is already EOL (End of life). I thought:

1 ⚠️ no USB-C port
2 ⚠️ platform is EOL
- Analog Devices MAX32630
- NOT RECOMMENDED FOR NEW DESIGNS
- created almost 10 years ago - 2018 Maxim Integrated Products, Inc.

Too late now, dive in …

I was lucky that others had documented their setups, which seemed more complicated than I would like, like this one by skruglewicz

Forum#2 - MAX32630FTHR Dev Environments - skruglewicz
3 ⚠️ works well with Mbed - EOL July 2026
- https://os.mbed.com/blog/entry/Important-Update-on-Mbed/

It seems some people had luck with the Arduino IDE but I thought that maybe a last resort - I want my version control, plugins and AI that I have already connected to VSCode.

Programming the MAX32630FTHR with the Arduino IDE Alistair

As the MAX32630 arrived, I had to get down to program it. I started with PlatformIO in VSCode as that has been my goto for Arduino and ESP32 projects. After a bit of pain, I could build it but I had no idea how to upload? there was a separate board for that? Going back to the Element14 community saved me having to read any manuals 👍.

Forum Thread 2 EchoGuard – MAX32630FTHR Blink Nidhee

OpenOCD

OpenOCD seems is what I needed, at this stage, I probably should have read the fine print of where this needs to come from. Again, I went for my preference to use Homebrew as a package manager and sure enough there was a brew install open-ocd package. After working out I need to power “both” boards and connect it to the programmer, I still got errors. Turns out I needed an AnalogDevices fork of the OpenOCD package. After some time, I installed it and it seemed to work - a flashing LED - that was a good 3 hours of pain, just to flash a red LED.

4 ⚠️ requires special fork of OpenOCD to work
- NOT This one https://github.com/openocd-org/openocd/
- THIS fork from Analog Devices Inc. https://github.com/analogdevicesinc/openocd

for those interested, here are my steps to get the AnalogDevices fork compiled and installed on a Mac OS (similar for linux 🐧 maybe even WSL, Windows Subsystem Linux 🐧).

# get the code
git clone https://github.com/analogdevicesinc/openocd --depth 1
rm -rf openocd/.git
cd openocd

# install some libraries requierd for building the package
brew install autoconf automake libtool pkg-config libusb hidapi jimtcl

  # UNTESTED
  # "likely" equivalent if using linux
  sudo apt-get install -y \
    autoconf automake libtool pkg-config \
    libusb-1.0-0-dev libhidapi-dev libjim-dev

./bootstrap

# some configurations to deal with some harmless warning
./configure \
  --enable-cmsis-dap \
  --disable-xds110 \
  CFLAGS="-g -O2 -Wno-error=gnu-folding-constant"

make -j$(sysctl -n hw.ncpu)

# install like a boss into /usr/local/bin/openocd
sudo make install

Mbed

My first attempt was using the soon to be EOL Mbed system. It worked, but given it’s EOL status I wasn’t satisfied.

Maxim SDK

So next I was onto MSDK (Maxim which I worked out has dropped support for the MAX32630.

5 ⚠️ current MSDK does not support MAX32630
- https://developer.analog.com/solutions/msdk support starts at the MAX32650 and it seems like MAX78000FTHR would be the way to go for some of the things I wanted to do like Multi-Keyword Recognition 🤦
6 ⚠️ not a modern platform - see MAX78000FTHR (circa 2020)

So it was back to the legacy LPSDK - (Low Power ARM Micro SDK). This took me on a number of mis adventures of massive installs and the like, that I thought there has to be another way, why not use Rust.

Rust

With the help of AI, I managed to get a build going. My custom built OpenOCD succeeded in pushing it onto the board and another flashing LED. Looking at the code was a bit tough, with snippets like

// raw register poke
(0x4000_A000 + 0x0080 + port * 4) as *mut u32).write_volatile(...)

Sounds like there is no HAL (Hardware Abstraction Layer) so if I want to use any GPIO, SPI, I2C, UART, Timers, ADC, I would need to write my own. The good thing is that for plain old GPIO there is not that much, just an offset of the address - so that part would just need a clean up. The bad thing is that AI said it would take 2-3 weeks to get that solid for full hardware support.

LPSDK (Low Power ARM Micro SDK)

Revisiting LPSDK, I worked out the install didn’t initially work. Now post install I have a blinking LED courtesy of the article.

Identity Protocol - Part 3 arvindsa

Oh and this comes with, you guessed it, the correct OpenOCD in the toolchain - maybe I should have RTFM 📚.

Why the MAX32630?

That is 6 warnings why not to build on this platform. I really wonder why this was chosen as the central piece of the design challenge - it’s not even cheaper to buy the hardware over newer revisions.

⚠️ no USB-C port
⚠️ platform is EOL
⚠️ Mbed is EOL July 2026
⚠️ requires fork of OpenOCD to work
⚠️ not supported by current MSDK
⚠️ there are comparable more modern platforms like MAX78000FTHR

Did I miss a memo? Still, I bought it now, and I need to build something ¯\_(ツ)_/¯ I need to get some credit on Element14 community!

My hardware list

So I have my MAX32630FTHR, on top of Tiny ML book to dream big with some wake word recognition. On the left some potential inputs like fingerprint reader, RFID, mmWave detector and on the right a motor, stepper motor and servo

time will tell what will come of this.

Hermetic Builds — Going Full Unix Purist

I’m a Unix philosophy purist at heart — small, composable tools that each do one thing well. So naturally I wanted to push the Rust experiment further and pursue a fully hermetic, reproducible build pipeline with zero click-ops.

The goal: infrastructure as code, end to end. git clone && mise run build on a fresh machine — no proprietary SDK downloads, no vendor portals requiring account creation, no DMG files opened with a mouse. Every dependency declared, every tool pinned, every flash command scripted.

Vendor-agnostic. SDK-free. GitOps-driven. Bare-metal Rust.

Where the LPSDK path requires a manual download from Analog Devices behind a login wall, and Mbed is hurtling toward EOL, the Rust path gives us a fully open, bootstrappable toolchain: rustup, cargo, arm-none-eabi via the Rust target system, and OpenOCD from source. No mouse required. No account required. No 6 GB installer required.

NOTE: arm-none-eabi is the GNU cross-compiler toolchain designed for building “bare-metal” applications on 32-bit and 64-bit Arm Cortex-M, Cortex-R and other embedded processors.

NOTE: arm-none-eabi supports C and C++ but Rust 🦀 is “cool” 😎

https://developer.arm.com/downloads/-/gnu-rm

The results for a hermetic build with LED blink were optimistic

Platform	build	from scratch
Mbed	~ 95 sec	? ~ 30 min (Via PlatfromIO install)
LPSDK	~ 6 sec	? ~ 60 min (LPSDK signup download and install)
Rust 🦀	~ 5 sec	~ 15 sec with clear cache `rm -rf ~/.cargo/registry ~/.cargo/git`

In pursuit of this zero click-ops embedded development dream — I decided to continue a little bit more with the Rust build.

Some output

All projects need some input and some output. Not having a Würth Elektronik Featherwing ICLED Display I got the closest thing I had, an old MAX7219 serial LED dot matrix display to the MAX32630FTHR. This was a brilliant moment, I pulled out my soldering iron and soldered on the header pins - It’s been a while since I have melted some solder and it felt good.

But before I could code something, I needed to find a bug in my Rust code. It didn’t run after a cold start, only after the Mbed code had run. This took me down a rabbit hole of looking at MAX14690 PMIC (Power Management IC). It seems that my code in either the LPSDK nor the Rust was configuring that so I needed to write some bits and bytes in there just for it to work post power up.

A bunch of vibe ٭ coding and a pmic_init function later and it worked. At this point I didn’t care too much what was in there, some I2CM and LDO registers being set - off I go. Now I vibe some code, connect and nothing - no smoke 💨 which is good but finally pulling out the multimeter and checking the pins shows me that 3V3 ain’t 3V3 🤔 I mean I never even thought that these things are configurable. Well sounds like they are.

as the brochure says

The board also includes the MAX14690 wearable PMIC to provide optimal power conversion and battery management.

Well it seems like that is configurable and following my code I realised that my first pmic_init implementation even had a comment

// (mbed only writes LDO2; LDO3 omitted here to match the reference exactly.)

Guess what LDO3 (Low Dropout Regulator) is - it’s the 3V3 pin

So to get an output voltage of 3.3V on the the MAX14690 PMIC’s LDO (Low Dropout Regulator) you need to:

Register_value = (V_desired - V_min) / step_size
Example: (3300 - 800) / 100 = 25

25 in HEX is 0x19

and set it in code where

0x16 (LDO3_CFG): Register to enable/configure LDO3.
0x17 (LDO3_VSET): Register to set the output voltage for LDO3.

// LDO2_VSET: (3300 - 800) / 100 = 25 = 0x19
const LDO2_3300MV: u8 = 0x19;

  ...

  // LDO3 powers the expansion header 3V3 rail — needed for external
  // peripherals.
  pmic_write(0x17, LDO_3300MV);  // LDO3_VSET
  pmic_write(0x16, LDO_ENABLED); // LDO3_CFG

Success, I have my Unix purist, hermetic build in Rust with an external peripheral and a whole bunch of half knowledge on PMIC and bit pushing logic I am pretty sure I don’t need, time will tell.

community.element14.com/.../20260421_5F00_03_5F00_matrix_5F00_test.mp4

It may be time to give up the Rust experiment, once I set the 3V3 pin to 3.3V, it no longer starts my program from a cold start, oh well.

Otherwise, I am pretty sure that with basic GPIO control, I can drive a stepper motor and similar but to get any sort of security element into this project, I really need to connect to something like the finger print reader I have.

Source

https://github.com/saramic/sentinel-box

Forum #3 - Hardware Integration - Adaptive Sentinel: Security Intelligence & Surveillance Hub

skruglewicz — Tue, 21 Apr 2026 10:09:24 GMT

As I dive into the hardware integration for the Adaptive Sentinel, I’ve hit a significant fork in the road. Integrating the Analog Devices FTHR-PMD-INTZ, the Würth Elektronik ICLED Display, and the Particle Ethernet FeatherWing is the goal, but the physical "how-to" is proving to be a challenge.

I’m looking to the community for some collaborative wisdom on how to best bridge these components without turning my workbench into a disaster zone. Here is the breakdown of my current dilemma:

The Stacking Roadblock

Initially, I envisioned a neat vertical stack. However, I’ve realized that the kit components come with pre-soldered male headers (FTHR-PMD-INTZ, ICLED Display, and the Ethernet Wing), not the pass-through stackable variety. Similarly, the MAX32630FTHR, CharliePlex LED, and Motor Wing include standard headers in the box, but again, they aren't stackable.

Without desoldering or adding stackable headers—a task I’m admittedly not very confident in yet—a pure vertical stack is off the table.

Breadboarding: A Secure Connection?

Breadboarding seems like the most logical path forward. I’m curious if any of you have experience using the headers provided in the packaging for the MAX32630FTHR or DC Motor Wing by simply seating the boards onto them in a breadboard without soldering.

My concern: Will this establish a secure enough electrical connection for reliable data transmission, or am I asking for "ghost" bugs and intermittent power failures? I’d love to hear if anyone has successfully prototyped this way before I commit.

The Particle Ethernet Wing Mystery

The third option I’m exploring involves the Particle FWNG-ETH Ethernet FeatherWing Adapter. It seems to have a unique rail-style layout, but the documentation is a bit sparse regarding its use as a "base" for other wings.

The Connection Logic: How do the signals actually route from Header 1 to Header 2?
Integration: If I use this as my main interconnect, how do I ensure the SPI pins for the Ethernet controller aren't conflicting with the ICLED matrix or the PMOD adapter?

I’ve been digging through the Particle Wiki, but it doesn't quite explain the "inter-header" connectivity for non-Particle hosts.

Next Steps & Experimentation

Over the next few days, I’ll be experimenting with these three specific topics:

Mechanical Stability: Testing the "friction-fit" of un-soldered headers on the breadboard.
Signal Mapping: Continuity testing the Particle Wing to see how the headers are internally tied together.
Hybrid Layouts: Possibly using the FTHR on the breadboard while jumpering out to the pre-soldered wings.

I'm here to learn, so if you’ve faced these stacking "geometry" problems before, please weigh in! How are you all physically organizing your Sentinel builds?

Current Status: In-Progress / Experimenting

Tools in use: Multimeter, Breadboard, Jumper Wire Spaghetti.

What do you think about the friction-fit header idea—is it a recipe for a short circuit, or a valid prototyping shortcut?

Identity Protocol - Part 6 - Snatch Detection with the BMI160 IMU

arvindsa — Sun, 19 Apr 2026 07:38:47 GMT

With the summer kicking in India, it is too hot to be outside, Plus it's holiday season for the Institute i work with and so I got more free time. My Work-cation at Goa has me fully charged and motivated. Today I will explain though how i Implemented Tug/Snatch detection.

Recap:

Tug detection is one of the important function to the project, as it prevents the card being stolen while in an unlocked state. Full source is in firmware/tests/imu-bmi160/ and firmware/tests/tug-detection/ in the project repo.

BMI160 Hardware

This nice little sensor from Bosch sits on the FTHR board's shared I2C bus alongside the MAX14690N PMIC. The pin mapping for I2CM2 MAP_A on the MAX32630 is:

SDA - P5_7
SCL - P6_0

The sensor has an address of 0x68.

Credits: mbed.com

Learning about the BMI160 Communication

Before writing a single line of LPSDK code I read through hanyazou's BMI160-Arduino library available at https://github.com/hanyazou/bmi160-arduino. It is derived from Intel's CurieIMU driver and covers the register map in. From this I surmised

1. The power-up command sequence

After power-on the BMI160 holds both accelerometer and gyroscope in suspend mode. They must be woken explicitly, in order, with startup delays that the datasheet specifies:

Step	Register	Value	Purpose	Delay after
1	0x7E (CMD)	0xB6	Soft reset	10 ms
2	0x7E (CMD)	0x11	Accel -> normal mode	5 ms
3	0x7E (CMD)	0x15	Gyro -> normal mode	80 ms

2. Verifying the chip with CHIP_ID

The Step that tells me things are communicating. Register 0x00 returns a fixed value of 0xD1 for the BMI160. Reading it is the simplest sanity check that I2C wiring and addressing are correct before doing anything else. The Arduino library checks this in getDeviceID().

3. Data layout: gyro first, then accelerometer

Reading 12 consecutive bytes starting at 0x0C gives you all six axes:

Offset	Register	Content
0	0x0C	Gyro X low byte
1	0x0D	Gyro X high byte
2	0x0E	Gyro Y low byte
3	0x0F	Gyro Y high byte
4	0x10	Gyro Z low byte
5	0x11	Gyro Z high byte
6	0x12	Accel X low byte
7	0x13	Accel X high byte
8	0x14	Accel Y low byte
9	0x15	Accel Y high byte
10	0x16	Accel Z low byte
11	0x17	Accel Z high byte

Each pair is a little-endian signed 16-bit integer:

ax = (int16_t)(buf[6] | (buf[7] << 8));

At the default range of +/-2 g, the scale is 16384 LSB per g.

4. The PMU (Power Management Unit) status register for debugging

Register 0x03 holds the current power-mode bits for each sensor: Polling this after wakeup commands confirms the device is actually ready, not just ACKing the write.

Bits	Field	Normal value
[1:0]	Accel PMU	0x01
[3:2]	Gyro PMU	0x01 (bit-pair 01 = 0x04 when shifted to [3:2])

Driver Development on LPSDK

MAX32630 Keeps surprising me. The LPSDK I2C API (i2cm.h) I2CM_Write cmd parameter sends a separate transaction before the data transaction. Works well for single byte reads but not for Burst reads. so a helper function needs to be written to prepend the register address into the data buffer and pass cmd=NULL in the I2CM_Write call:

/* Write one byte to a BMI160 register */
static int bmi160_write_reg(uint8_t reg, uint8_t val)
{
    uint8_t buf[2] = { reg, val };
    int ret = I2CM_Write(I2C_BUS, BMI160_ADDR, NULL, 0, buf, 2);
    return (ret == 2) ? E_NO_ERROR : E_COMM_ERR;
}

For reading, it's straight forward, but to maintain a good coding structure i will use a helper for reads which does nothng but keep the function similar to read

/* Read len bytes starting at reg */
static int bmi160_read_regs(uint8_t reg, uint8_t *data, int len)
{
    int ret = I2CM_Read(I2C_BUS, BMI160_ADDR, &reg, 1, data, len);
    return (ret == len) ? E_NO_ERROR : E_COMM_ERR;
}

Initializing the I2C

const sys_cfg_i2cm_t cfg = {
    .clk_scale = CLKMAN_SCALE_DIV_1,
    .io_cfg    = IOMAN_I2CM2(IOMAN_MAP_A, 1),   /* P5_7=SDA, P6_0=SCL */
};
I2CM_Init(MXC_I2CM2, &cfg, I2CM_SPEED_100KHZ);

So here is the final flow

and the code equivalent to that

static int bmi160_init(void)
{
    uint8_t chip_id = 0;

    /* 1. Verify chip identity */
    if (bmi160_read_regs(BMI160_REG_CHIP_ID, &chip_id, 1) != E_NO_ERROR)
        return E_COMM_ERR;
    if (chip_id != 0xD1)
        return E_BAD_PARAM;

    /* 2. Wake accelerometer */
    bmi160_write_reg(BMI160_REG_CMD, 0x11);   /* ACC_NORMAL */
    TMR_Delay(MXC_TMR0, MSEC(5));

    /* 3. Wake gyroscope */
    bmi160_write_reg(BMI160_REG_CMD, 0x15);   /* GYR_NORMAL */
    TMR_Delay(MXC_TMR0, MSEC(80));

    return E_NO_ERROR;
}

This will help make the IMU ready to stream the data.

The Physics behind the Algorithm

3D Printing Enthusiasts who use Klipper will find this familiar - Jerk. No I am not insulting you (I hope e14's sensitive spam detection does not flag this). Jerk is the time derivative of Acceleration. It is felt when an object collides or is pulled suddenly. Just the initial bit of it. For people who ask - Why not acceleration? My answer is Acceleration happen on a daily basis during regular activity - Walking, Running etc. We want the IMU to detect when there is a sudden change in activity, when a person bumps into another (that's when the ID cards are stolen in most movies) or when it is pulled.

So to detect a jerk we calculate the acceleration change divided by the time period. The net acceleration is calculated by square root of sum of square of each component. Trying Running this at 50Hz did not work out well, it started lagging, so i resorted to next best thing approximation (I forgot the name of this approximation)

magnitude (appx) = max(|x|, |y|, |z|) + 0.5 * mid(|x|, |y|, |z|)

static int32_t accel_magnitude(int16_t ax, int16_t ay, int16_t az)
{
    int32_t x = ax < 0 ? -ax : ax;
    int32_t y = ay < 0 ? -ay : ay;
    int32_t z = az < 0 ? -az : az;
    /* Sort descending */
    if (y > x) { int32_t t = x; x = y; y = t; }
    if (z > x) { int32_t t = x; x = z; z = t; }
    if (z > y) { int32_t t = y; y = z; z = t; }
    return x + (y >> 1);   /* max + 0.5 * mid */
}

Threshold tuning

I just kept decreasing the threshold until i was satisfactory

Here is the link to full video if you are interested. - https://youtu.be/xhUsJPgzvA0 I choose 21,000 as a good balance better detecting a sharp tug and ignoring basic tugs.

Polling Loop

device_state_t state = STATE_LOCKED;
int16_t ax, ay, az;
bmi160_read_accel(&ax, &ay, &az);
int32_t prev_mag = accel_magnitude(ax, ay, az);

while (1) {
    TMR_Delay(MXC_TMR0, MSEC(20));   /* 50 Hz */

    bmi160_read_accel(&ax, &ay, &az);
    int32_t mag   = accel_magnitude(ax, ay, az);
    int32_t delta = mag - prev_mag;
    if (delta < 0) delta = -delta;
    prev_mag = mag;

    if (state == STATE_UNLOCKED && delta > JERK_THRESHOLD) {
        state = STATE_LOCKED;
        led_red();
        printf("TUG DETECTED (delta=%ld) -- LOCKED\n", (long)delta);
    }
}

I couldn't get the jerk threshold calculated on the Sensor itself and so, i just left the interrupt pin alone and decided on polling and calculating on MCU.

Code for this particular post is available at https://github.com/arvindsa/identity-protocol-e14-challenge/tree/main/firmware/tests/tug-detection
Code for entire project is available at https://github.com/arvindsa/identity-protocol-e14-challenge

Results

Results can be seen in the full video of the tug threshold test - https://youtu.be/xhUsJPgzvA0.

Final Notes

One of the important decision I have to take was to choose between an option of Calculating correct acceleration using the square root method at the cost of lower sampling rate or Having a higher sampling rate at the cost of an approximated acceleration. I went with approximation because i can appropriately change the threshold value experimentally. This will prove to be a better choice when i start integrating all the function and they take up cpu cycles. If it was actual acceleration calculation the other functionality will drag the sampling rate even lower.

The Start of the project is the Cryptographic signing by ATECC508A. Since I've worked with it before, all i have to do is port the code to match the LPSDK's function call which is almost done. I am making a small change to my project, previously in my plan it was the door device will use another ATECC508A for verification. But I realized it was not needed and so we will use software library micro-ecc for verification of the cryptographic signature. I will explain it in detail over a post. It's the write-up which is the hard part. 😃

Guardian Sentinel — Active Environment Monitoring for Smart Safety & Security

meera_hussien — Fri, 17 Apr 2026 18:24:26 GMT

Guardian Sentinel — Active Environment Monitoring for Smart Safety & Security

<Part 1>

Image 1. AI Generated Image

Introduction

For this design challenge, I have decided to build an active environment monitoring system for smart safety and security. The system will not only monitor the environment, but will also respond accordingly. I originally planned to develop this system for use inside a workshop, but unfortunately I do not have access to one. Therefore, I will be using my working room and simulating a similar workshop environment. In addition to the hardware provided, I will also be using several extra sensors to achieve the project objectives, which I will explain in the next post. As shown in Image 1, it provides an overview of the main concept of this project. The system will monitor environmental conditions such as temperature, humidity, air quality, and CO2, and based on these readings, it will take the necessary action. In addition, a sensor will be included to detect the presence of people. All of this will be monitored through a dedicated dashboard, and the data will be logged for future use.

Unboxing

Below is the pic and video of the unboxing. I have also include the related document for each of the device.

Let's watch the unboxing video below.

community.element14.com/.../Unboxin.mp4

This is the image and the link for each of the component which i have received.

1. Analog Devices MAX32630FTHR# Application Platform X 2

{gallery}Analog Devices MAX32630FTHR# Application Platform

2. Analog Devices FTHR-PMD-INTZ Adapter Board

3. Würth Elektronik 150015 Featherwing ICLED Display

4. Particle FWNG-ETH Ethernet Featherwing Adapter

5. Adafruit ADA2927 DC Motor + Stepper FeatherWing

And last but not least, it comes with the element14 cool stickers

In the next post we shall see in detail on each of these product and also get started using it.

Identity Protocol - Part 5 - Interfacing a Keypad

arvindsa — Fri, 17 Apr 2026 05:16:53 GMT

In Part 5, I'll interface an 4x4 Tactile Keypad without using an external library

Recap:

For my ID Card device i need a way to enter the pin in order to unlock it, I initially thought of a membrane keyboard, but in my box of electronics treasure, I found an tactile keyboard which i had bought before from Robu: https://robu.in/product/4x4-matrix-16-keyboard-keypad/ and an datasheet attached to it.

But when i tried with the code, it was not working well, the letter orientation came such that it seemed the rows and columns were transposed. Swapping the pins for Rows and Columns worked. Confusion set it, is my simple enough code wrong? Revelation set in when Adafruit's learning page showed the correct pin out here: https://learn.adafruit.com/matrix-keypad/pinouts . My Code is right, the datasheet was wrong. Here is the correct one

Photo Credits: Adafruit (Do note my code uses C0~C3 instead of C1~C4) and similarly for the Rows

Working of Keypad

The working of keypad is an age old and proven mechanism. Each key is a switch, one side of the switch is wired along the column and the other side is wired along the row. When switch is pressed, it connects the respective column to the row. To detect the key pressed, we wire the 4 Row and 4 Columns pins to GPIO

Photo Credits: Adafruit

All the Rows are made input without any pull-ups / pull downs (HiZ - High impedance). The Columns are made input with pull ups
One Row (lets saw R1) is driven low and the 4 columns are read to see which one is low. The column corresponding to the key pressed will be low.
If no Column is found to be low, the next Row is made low after restoring the previous row to HiZ
If all rows are scanned and no columns are found low, then it means no key is pressed

When One key is found to be pressed, It is saved in key and last key. During the next round of scan if the same key is found to be still pressed, it is ignored. This way i have implemented a simple hold detection. This happens until the the scan finds no key pressed, but last key is set, this signals a key release event, and last_key is set as none. a 10ms interval between scans should be sufficient for the de-bouncing delay. If you don't know what de-bouncing is check out https://www.picotech.com/library/articles/blog/what-is-switch-bounce-how-to-implement-debounce

In my implementation of this as a function - keypad_scan() it returns an integer such that the number starts from 0 and increases as keys go from top to bottom and left to right. This way i can quickly compare the pressed key to the last one in one statement, plus also is easier to debug in case a key / row / column is not working

1=0   2=1   3=2   A=3
4=4   5=5   6=6   B=7
7=8   8=9   9=10  C=11
*=12  0=13  #=14  D=15

Flow Chart of working

Keypad Wiring

Signal	Pin
KPD_ROW0	P5_0
KPD_ROW1	P5_1
KPD_ROW2	P5_2
KPD_ROW3	P5_3
KPD_COL0	P5_4
KPD_COL1	P5_6
KPD_COL2	P3_2
KPD_COL3	P3_3

The Results

This one is in a gif format. Below is the full video (there might be a video sync issue between the screen capture and the video of me pressing the button)

community.element14.com/.../p5_2D00_01.mp4

Source Code

#include <stdio.h>
#include "mxc_errors.h"
#include "gpio.h"
#include "tmr_utils.h"
#include "uart.h"

/* ---- Board_Init override ------------------------------------------------- */
int Board_Init(void) { return E_NO_ERROR; }

/* ---- Keypad configuration ------------------------------------------------ */
#define KEYPAD_ROWS  4
#define KEYPAD_COLS  4

/* Row pins: P5_0, P5_1, P5_2, P5_3 (SPI header pins, no SPI peripheral on ID device) */
static const gpio_cfg_t row_cfg[KEYPAD_ROWS] = {
    { PORT_5, PIN_0, GPIO_FUNC_GPIO, GPIO_PAD_NORMAL },
    { PORT_5, PIN_1, GPIO_FUNC_GPIO, GPIO_PAD_NORMAL },
    { PORT_5, PIN_2, GPIO_FUNC_GPIO, GPIO_PAD_NORMAL },
    { PORT_5, PIN_3, GPIO_FUNC_GPIO, GPIO_PAD_NORMAL },
};

/* Column pins: P5_4, P5_6, P3_2, P3_3 -- input with internal pull-up */
static const gpio_cfg_t col_cfg[KEYPAD_COLS] = {
    { PORT_5, PIN_4, GPIO_FUNC_GPIO, GPIO_PAD_INPUT_PULLUP },
    { PORT_5, PIN_6, GPIO_FUNC_GPIO, GPIO_PAD_INPUT_PULLUP },
    { PORT_3, PIN_2, GPIO_FUNC_GPIO, GPIO_PAD_INPUT_PULLUP },
    { PORT_3, PIN_3, GPIO_FUNC_GPIO, GPIO_PAD_INPUT_PULLUP },
};

#define KEY_NONE  -1   /* no key detected this scan, cant use 0 */

/* Key label lookup: row-major, matches physical layout
 *   Row 0: 1 2 3 A
 *   Row 1: 4 5 6 B
 *   Row 2: 7 8 9 C
 *   Row 3: * 0 # D
 */
static const char key_map[KEYPAD_ROWS][KEYPAD_COLS] = {
    { '1', '2', '3', 'A' },
    { '4', '5', '6', 'B' },
    { '7', '8', '9', 'C' },
    { '*', '0', '#', 'D' },
};

/*
 * keypad_init -- configure all row pins as outputs (high), all col pins as
 * inputs with pull-ups.
 */
static void keypad_init(void)
{
    for (int r = 0; r < KEYPAD_ROWS; r++) {
        GPIO_Config(&row_cfg[r]);
        GPIO_OutSet(&row_cfg[r]);   /* idle high */
    }
    for (int c = 0; c < KEYPAD_COLS; c++) {
        GPIO_Config(&col_cfg[c]);
    }
}

/*
 * keypad_scan -- drive each row low in turn, read columns, restore row.
 * Returns encoded key index (row*4+col) or KEY_NONE.
 *
 * Rows not being scanned are set to input (high-Z) to avoid bus contention
 * when multiple keys are wired to the same column.
 */
static int keypad_scan(void)
{
    for (int r = 0; r < KEYPAD_ROWS; r++) {
        /* Set all rows to input (high-Z) */
        for (int i = 0; i < KEYPAD_ROWS; i++) {
            gpio_cfg_t hi_z = row_cfg[i];
            hi_z.func = GPIO_FUNC_GPIO;
            hi_z.pad  = GPIO_PAD_INPUT;
            GPIO_Config(&hi_z);
        }

        /* Drive the target row low (output) */
        gpio_cfg_t out = row_cfg[r];
        out.func = GPIO_FUNC_GPIO;
        out.pad  = GPIO_PAD_NORMAL;
        GPIO_Config(&out);
        GPIO_OutClr(&out);

        /* Small settling time */
        TMR_Delay(MXC_TMR0, USEC(10));

        /* Read columns */
        for (int c = 0; c < KEYPAD_COLS; c++) {
            if (GPIO_InGet(&col_cfg[c]) == 0) {
                GPIO_OutSet(&out);
                GPIO_Config(&row_cfg[r]);
                GPIO_OutSet(&row_cfg[r]);
                return r * KEYPAD_COLS + c;
            }
        }

        /* Restore row */
        GPIO_OutSet(&out);
        GPIO_Config(&row_cfg[r]);
        GPIO_OutSet(&row_cfg[r]);
    }

    return KEY_NONE;
}

/* ---- Debounce ------------------------------------------------------------ */
/*
 * Two consecutive identical scan results 10 ms apart constitute a confirmed
 * state.  Transitions are only reported on confirmation.
 */
#define DEBOUNCE_MS  10

static int debounce(void)
{
    int first = keypad_scan();
    TMR_Delay(MXC_TMR0, MSEC(DEBOUNCE_MS));
    int second = keypad_scan();
    return (first == second) ? first : KEY_NONE - 1;  /* -2 = unstable */
}

/* ---- Main ---------------------------------------------------------------- */
int main(void)
{
    /* Init UART1 MAP_A for printf (DAPLink serial, P2_0/P2_1, 115200 baud).
     * CONSOLE_UART=1 in Makefile routes _write() here. */
    {
        const uart_cfg_t uart_cfg = {
            .parity     = UART_PARITY_DISABLE,
            .size       = UART_DATA_SIZE_8_BITS,
            .extra_stop = 0,
            .cts        = 0,
            .rts        = 0,
            .baud       = 115200,
        };
        const sys_cfg_uart_t uart_sys_cfg = {
            .clk_scale = CLKMAN_SCALE_AUTO,
            .io_cfg    = IOMAN_UART(1, IOMAN_MAP_A, IOMAN_MAP_UNUSED, IOMAN_MAP_UNUSED, 1, 0, 0),
        };
        UART_Init(MXC_UART1, &uart_cfg, &uart_sys_cfg);
    }

    keypad_init();

    printf("INIT\r\n");

    int last_key = KEY_NONE;

    while (1) {
        int key = debounce();

        if (key >= 0 && key != last_key) {
            /* New confirmed press */
            int row = key / KEYPAD_COLS;
            int col = key % KEYPAD_COLS;
            printf("KEY %c (%d,%d)\r\n", key_map[row][col], row, col);
            last_key = key;

        } else if (key == KEY_NONE && last_key != KEY_NONE) {
            /* Key released (confirmed idle) */
            printf("UP\r\n");
            last_key = KEY_NONE;
        }
        /* key == -2 (unstable): ignore, loop again immediately */
    }
}

Code for this particular post is available at https://github.com/arvindsa/identity-protocol-e14-challenge/tree/main/firmware/tests/keypad-scan
Code for entire project is available at https://github.com/arvindsa/identity-protocol-e14-challenge

Final Notes

The code worked brilliantly and now i can get on the next peripherals. I was supposed to do the Crypto signing work next, but i decided to do it on a weekend when i have a longer block of free time. Also i decided to move away from inkscape to draw.io website at https://app.diagrams.net/ for my flow chart creation. Gets work done faster. and I stick to copy-pasting from Typora for the github style tables.

Identity Protocol - Part 4 - BLE using PAN1326B and BTstack

arvindsa — Thu, 16 Apr 2026 11:01:04 GMT

In Part 4, I'll walk through getting Bluetooth Low Energy up and running on the MAX32630FTHR

Recap:

I was initially happy when i saw an folder exactLE in the LPSDK's file thinking it might be an easy fit, but the rabbit hole just got started. Let's start by telling about the module itself

The Bluetooth Hardware

PAN1326B module a compact module from Panasonic built around the TI CC2564B chip. This gives you Bluetooth Classic + BLE 4.1. The CC2564B talks to the MAX32630 over UART. It is not a standalone BLE SoC unlike nrf52 and it is a radio that needs a host controller library on the MCU side to drive it.

A basic google search took me to BTStack - https://github.com/bluekitchen/btstack and their supported boards here: https://bluekitchen-gmbh.com/btstack/ports/existing_ports.html listed our MAX32630FTHR. I was happy.

Imported their git repo as a submodule to mine and

git submodule add github.com/.../btstack.git third_party/btstack

funnily enough i had to run the `make` command inside the btstack\port\max32630-fthr folder to generate the examples. The nice part is they also have shipped a copy of the LPSDK source files with BTStack, It brings its own board support file (board.c) written specifically for the FTHR, with UART1 on MAP_A (P2_0/P2_1) as the debug console and UART0 on MAP_B as the CC2564B interface. so nice of them. No toolchain though. That's alright. Its the best way. They even gave a template for the makefile to make a fresh project with BTStack, It was a bit complicated to i asked chatGPT to help me mix my makefile and BTStack to make a makefile which will use the toolchain i already have with the LPSDK and BT Stack they have, which turned out to be like -

PROJECT   ?= ble_beacon
PORT_NAME ?= max32630-fthr

TARGET    = MAX3263x
TARGET_UC := MAX3263X
TARGET_LC := max3263x
COMPILER  = GCC

# ---- User-configurable roots ------------------------------------------------

# Root of this project (auto-detected)
PROJECT_ROOT := $(abspath $(dir $(lastword $(MAKEFILE_LIST))))

# BTstack root (override if needed)
BTSTACK_ROOT ?= $(PROJECT_ROOT)/../../../third_party/btstack
BTSTACK_ROOT := $(abspath $(BTSTACK_ROOT))

# Optional: override from environment instead of sdk.local.mk
LPSDK_ROOT ?=

# Load local overrides if present
-include $(PROJECT_ROOT)/../../sdk.local.mk

ifeq ($(LPSDK_ROOT),)
$(warning LPSDK_ROOT not set — flash target will not work)
endif

# ---- Derived paths ----------------------------------------------------------

PORT_DIR   := $(BTSTACK_ROOT)/port/$(PORT_NAME)
MAXIM_PATH := $(PORT_DIR)/maxim
LIBS_DIR   := $(MAXIM_PATH)/Firmware/$(TARGET_UC)/Libraries
CMSIS_ROOT := $(LIBS_DIR)/CMSIS

# ---- Build flags ------------------------------------------------------------

PROJ_CFLAGS  += -DRO_FREQ=96000000
PROJ_CFLAGS  += -DMXC_ASSERT_ENABLE
PROJ_CFLAGS  += -DENABLE_HCI_INIT
PROJ_CFLAGS  += --specs=nano.specs
PROJ_LDFLAGS += --specs=nano.specs

# ---- Source paths -----------------------------------------------------------

VPATH = . src
IPATH = . src

# BTstack core
VPATH += \
    $(BTSTACK_ROOT)/src \
    $(BTSTACK_ROOT)/src/ble \
    $(BTSTACK_ROOT)/src/classic \
    $(BTSTACK_ROOT)/platform/embedded \
    $(BTSTACK_ROOT)/chipset/cc256x \
    $(BTSTACK_ROOT)/3rd-party/micro-ecc \
    $(BTSTACK_ROOT)/3rd-party/md5 \
    $(BTSTACK_ROOT)/src/ble/gatt-service

IPATH += \
    $(BTSTACK_ROOT)/src \
    $(BTSTACK_ROOT)/src/ble \
    $(BTSTACK_ROOT)/src/classic \
    $(BTSTACK_ROOT)/platform/embedded \
    $(BTSTACK_ROOT)/chipset/cc256x \
    $(BTSTACK_ROOT)/3rd-party/micro-ecc \
    $(BTSTACK_ROOT)/3rd-party/md5 \
    $(BTSTACK_ROOT)/src/ble/gatt-service \
    $(BTSTACK_ROOT)/3rd-party/hxcmod-player

# Port sources
VPATH += $(PORT_DIR)/src
IPATH += $(PORT_DIR)/src

# ---- Board support ----------------------------------------------------------

ADAPT_BOARD_DIR := $(PORT_DIR)/board/$(PORT_NAME)
BOARD_DIR       := $(LIBS_DIR)/Boards/EvKit_V1

VPATH += $(LIBS_DIR)/Boards/Source
IPATH += $(LIBS_DIR)/Boards/Include

include $(ADAPT_BOARD_DIR)/board.mk

# ---- BTstack sources --------------------------------------------------------

SRCS += \
    btstack_audio.c \
	...<LOTS MORE>

# Third-party
SRCS += uECC.c md5.c

# Port + app
SRCS += \
    btstack_port.c \
    hal_tick.c \
    hal_flash_bank_mxc.c \
    main.c \
    ble_beacon.c \
    btstack_link_key_db_stub.c

# ---- Peripheral driver + CMSIS ---------------------------------------------

PERIPH_DRIVER_DIR := $(LIBS_DIR)/$(TARGET_UC)PeriphDriver
include $(PERIPH_DRIVER_DIR)/periphdriver.mk

include $(CMSIS_ROOT)/Device/Maxim/$(TARGET_UC)/Source/$(COMPILER)/$(TARGET_LC).mk

# ---- Output helpers ---------------------------------------------------------

bin: $(BUILD_DIR)/$(PROJECT).elf
	arm-none-eabi-objcopy -O binary $< $(BUILD_DIR)/$(PROJECT).bin
	arm-none-eabi-size $<

# ---- Flash ------------------------------------------------------------------

flash: $(BUILD_DIR)/$(PROJECT).elf
ifndef LPSDK_ROOT
	$(error LPSDK_ROOT not set — cannot flash)
endif
	"$(LPSDK_ROOT)/Toolchain/bin/openocd.exe" \
	    -c "set LPSDK_TOOLCHAIN $(LPSDK_ROOT)/Toolchain" \
	    -f "$(PROJECT_ROOT)/../../openocd.cfg" \
	    -c "program $< verify reset exit"

Full File: https://github.com/arvindsa/identity-protocol-e14-challenge/blob/main/firmware/tests/ble-beacon/Makefile

This raised an error. I figured since BTStack was kind enough to share the LPSDK i thought they would also include the TI's Init Script for the CC2564B. When i checked the code at "btstack\chipset\cc256x\convert_bts_init_scripts.py" it said that "The Makefile include chipset/cc256x/Makefile.inc automates the process of downloading and converting .bts files." but it did not work for me, so i manually ran the python file as per their docs and boom

python convert_bts_init_scripts.py \
    cc256xb_bt_sp_v1.8/initscripts-TIInit_6.7.16_bt_spec_4.1.bts \
    cc256xb_bt_sp_v1.8/initscripts-TIInit_6.7.16_ble_add-on.bts \
    bluetooth_init_cc2564B_1.8_BT_Spec_4.1.c

The Bring-up Sequence

Before getting to application code, it helps to understand what bluetooth_main() in the BTstack port does before it ever calls your btstack_main

Clock on P1.7 `init_slow_clock()` routes the internal 32 kHz RTC output to P1.7. The PAN1326B needs this as its reference clock.
nSHUTD on P1.6- the port drives this line high to release the CC2564B from reset. The UART line is not valid until nSHUTD is high and the module has had time to stabilise.
RTS poll on P0.3- after releasing nSHUTD, the code spins polling the CC2564B's RTS output waiting for it to go low. Only then is the HCI UART initialised.
Baud rate renegotiation - the init script starts at 115200 baud, then a vendor-specific HCI command bumps it to 4 Mbit/s. BTstack handles all of this inside `btstack_chipset_cc256x`.

The BTstack MAX32630FTHR port provides its own `main.c` which takes care of all the run loop initialization as well as the transport initialization of the HCI interface. The application code is provided to `btstack_main()`, which is invoked by the port after it initializes itself. Therefore, there is no need to invoke `btstack_run_loop_init()` or `hci_init()`: In other words, there is no main loop in the main.c file. Read more about the Btstacks code architecture here: bluekitchen-gmbh.com/.../examples.html

#define BTSTACK_FILE__ "ble_beacon.c"

#include <stdio.h>
#include "btstack.h"
#include "gpio.h"

/* RGB LEDs — active-low, open-drain */
static const gpio_cfg_t led_r = { PORT_2, PIN_4, GPIO_FUNC_GPIO, GPIO_PAD_OPEN_DRAIN };
static const gpio_cfg_t led_g = { PORT_2, PIN_5, GPIO_FUNC_GPIO, GPIO_PAD_OPEN_DRAIN };

static const uint8_t adv_data[] = {
    0x02, 0x01, 0x06,                               /* Flags: LE General Discoverable */
    0x0A, 0x09, 'I', 'D', '-', 'B', 'e', 'a', 'c', 'o', 'n',  /* Complete Local Name */
};

static btstack_packet_callback_registration_t hci_event_callback_registration;

static void packet_handler(uint8_t packet_type, uint16_t channel,
                           uint8_t *packet, uint16_t size)
{
    UNUSED(channel); UNUSED(size);
    if (packet_type != HCI_EVENT_PACKET) return;

    switch (hci_event_packet_get_type(packet)) {
    case BTSTACK_EVENT_STATE:
        if (btstack_event_state_get_state(packet) == HCI_STATE_WORKING) {
            bd_addr_t zero_addr = {0};
            gap_advertisements_set_params(0x0100, 0x0200, 0, 0, zero_addr, 0x07, 0x00);
            gap_advertisements_set_data(sizeof(adv_data), (uint8_t *)adv_data);
            gap_advertisements_enable(1);
            GPIO_OutClr(&led_g);   /* green on  */
            GPIO_OutSet(&led_r);   /* red off   */
            printf("Advertising as \"ID-Beacon\"\n");
        } else if (btstack_event_state_get_state(packet) == HCI_STATE_OFF) {
            printf("HCI off\n");
        }
        break;
    default:
        break;
    }
}

int btstack_main(int argc, const char *argv[])
{
    UNUSED(argc); UNUSED(argv);

    GPIO_Config(&led_r); GPIO_Config(&led_g);
    GPIO_OutClr(&led_r);   /* red on while initialising */
    GPIO_OutSet(&led_g);   /* green off */

    hci_event_callback_registration.callback = &packet_handler;
    hci_add_event_handler(&hci_event_callback_registration);
    hci_power_control(HCI_POWER_ON);
    return 0;
}

The code ran fine and i was able to verify it's working using the Nordic's Connect App on my phone.

Serial UART log via hterm

The Makefile

I used BTstack's bundled copy of the LPSDK inside port/max32630-fthr/maxim/ rather than the main LPSDK installation. This keeps the BTstack port self-contained a Every BTstack source file is listed explicitly. no wildcard includes. The `-DENABLE_HCI_INIT` flag is critical: it gates the HCI transport setup inside `btstack_port.c`. Without it, the CC2564B is never initialised. I still can't understand why. if anyone can. i'll be grateful to them

PROJECT   = ble_beacon
PORT_NAME = max32630-fthr

BTSTACK_ROOT ?= ../../../third_party/btstack
BTSTACK_ROOT := $(abspath $(BTSTACK_ROOT))

PORT_DIR   = $(BTSTACK_ROOT)/port/$(PORT_NAME)
MAXIM_PATH = $(PORT_DIR)/maxim
LIBS_DIR   = $(MAXIM_PATH)/Firmware/MAX3263X/Libraries

# Machine-specific OpenOCD path only — BTstack uses its own bundled SDK
-include ../../sdk.local.mk

PROJ_CFLAGS += -DENABLE_HCI_INIT

# Core BTstack
SRCS += btstack_memory.c btstack_memory_pool.c btstack_linked_list.c
SRCS += btstack_util.c btstack_run_loop.c btstack_run_loop_embedded.c
SRCS += btstack_crypto.c btstack_audio.c
SRCS += hci.c hci_cmd.c hci_dump.c hci_dump_embedded_stdout.c hci_transport_h4.c
SRCS += btstack_uart_block_embedded.c
# BLE layer
SRCS += ad_parser.c att_dispatch.c sm.c
SRCS += le_device_db_tlv.c btstack_tlv.c btstack_tlv_flash_bank.c
# Third-party crypto
SRCS += uECC.c md5.c
# CC2564B chipset driver + init script
SRCS += btstack_chipset_cc256x.c bluetooth_init_cc2564B_1.8_BT_Spec_4.1.c
# Port-specific files
SRCS += btstack_port.c hal_tick.c hal_flash_bank_mxc.c main.c
# Application
SRCS += ble_beacon.c btstack_link_key_db_stub.c

However, there is one catch. When initializing the MAX32630FTHR port, the `btstack_port.c` file calls `btstack_link_key_db_tlv_get_instance()` and `hci_set_link_key_db()` regardless of whether we compile for BLE only. The problem is that both functions reside in the `#ifdef ENABLE_CLASSIC` block in the BTstack code. Once you define `ENABLE_CLASSIC`, you will have SBC/A2DP audio definitions pulled into your source tree that

The fix is a small stub file (`src/btstack_link_key_db_stub.c`) that satisfies the linker without touching the classic stack at all:

#include <stddef.h>
#include "classic/btstack_link_key_db_tlv.h"

/* Returns NULL — no link-key storage. Safe: classic pairing is never initiated. */
const btstack_link_key_db_t *
btstack_link_key_db_tlv_get_instance(const btstack_tlv_t *impl, void *ctx)
{
    (void)impl; (void)ctx;
    return NULL;
}

void hci_set_link_key_db(btstack_link_key_db_t const *db) { (void)db; }

Now, i tried to capture the signals using my salae logic analyzer but, it took be 10mins after i gracefully took the analyzer out of the box, hooked up the wires and tried to find the Bluetooth pins on the feather. I had the pin-out card in front of me, but realized it too late, that the pins to the Bluetooth is not broken out properly for easy access.

A note on Compiling

Even though i used the tool chain provided by the installation from LPSDK, i used the firmware from the BTStack. So, The build uses the LPSDK's bundled `make.exe` from `Toolchain/msys/1.0/bin/`. You need both the MSYS bin directory and the ARM toolchain on PATH. The cleanest way is to set `LPSDK_ROOT` in your environment (or in `firmware/sdk.local.ps1`) and use the included `build_and_flash.ps1`:

The Code Repository

You can find the project code here - https://github.com/arvindsa/identity-protocol-e14-challenge/tree/main

Next Steps

Sharing data over BLE GATT, Getting the ATECC508A crypto chip talking over I2C, provisioning a key pair, and running a sign/verify round-trip. That's where the actual security story starts.

Final notes

The BTStack helped me quite a lot, their documentation https://bluekitchen-gmbh.com/btstack/ports/existing_ports.html#sec:max32630-fthrPort was quite easy to understand which helped me quite easily. There was a time where i thought of pivoting to mbed or arduino but i stuck to my initial goal. Infact I was sure it will get frustrating that i decided to work on the BLE after my Workation at Goa. Work in the morning and Chill on a beach side with a chilled beer. Here is a photo of my Chillout time. The easy documentation BTStack propelled me and thus managed to get this BLE Working within couple of hours. I still am new to BLE and heavily using Youtube videos and ChatGPT to help me understand it. Yet, i am quite confident i will get it done.

Forum Thread 2 EchoGuard – MAX32630FTHR Setup & First Blink Program Upload

Nidhee — Wed, 15 Apr 2026 22:14:25 GMT

🔌 Hardware Setup & First Code Upload

Connecting the Boards

To begin the setup:

The MAX32625PICO is connected to the Analog Devices MAX32630FTHR using the provided socket-to-socket connector cable
Both boards are then connected to the computer using USB cables (included in the kit)

This setup allows the PICO board to act as a programmer for the main board.

⚙️ Development Environment Setup

Setting up the software environment can be a bit confusing, as most available tutorials are quite old. So here is a simple and working method.

Step 1: Install VS Code

Install Visual Studio Code (if not already installed). Link : https://code.visualstudio.com/Download

Step 2: Install PlatformIO

Go to Extensions in VS Code
Search for PlatformIO IDE
Install it

What is PlatformIO?
PlatformIO is an extension that makes it easy to develop, build, and upload code to embedded boards. It manages libraries, toolchains, and programming automatically.

You can see that I have already installed it.

⚠️ After installation, restart VS Code.

Step 3: Create New Project

Click on the alien icon 👽 (PlatformIO) on the left
Click New Project

Fill details:

Project Name: max32630_test
Board: Maxim MAX32630FTHR Application Platform
Framework: Mbed

Click Finish and wait for setup.

Step 4: Create Main Code File

Open src folder
Create new file → main.cpp

Paste this test code:

#include "mbed.h"

// onboard LED
DigitalOut led(LED1);

int main() {
 while (true) {
 led = !led;
 ThisThread::sleep_for(500ms);
 }
}

⚠️ Important Setup (OpenOCD)

To upload code properly, we need OpenOCD.

Step 5: Download OpenOCD

Download from:
https://gnutoolchains.com/arm-eabi/openocd/
Download the latest .7z file
Extract it to C:\

Make sure folder contains:

bin
drivers
share

Step 6: Find Target Config

Go to:

share → openocd → scripts → target

Find file:

max32630.cfg OR
max3263x.cfg

Remember this name

Step 7: Update platformio.ini

Add these lines:

upload_protocol = custom

upload_command = C:\openocd-20251211\OpenOCD-20251211-0.12.0\bin\openocd.exe -s C:\openocd-20251211\OpenOCD-20251211-0.12.0\share\openocd\scripts -f interface/cmsis-dap.cfg -f target/max3263x.cfg -c "program .pio/build/max32630fthr/firmware.elf verify reset exit"

debug_tool = cmsis-dap

Save the file

Step 8: Build & Upload

Click ✔ (Build) at bottom
Wait for “Build Success”
Then click → (Upload)

⚠️ Important:

Always Save → Build → Upload
Do NOT upload directly

Upload Indicator (Important Observation)

During the upload process:

The MAX32625PICO board starts blinking a green LED

This indicates:

Code is being transferred
Communication between PC and main board is active

This is a useful visual confirmation that the upload process is working correctly.

Result

If the video does not play here, you can watch it directly using the link below.

https://drive.google.com/file/d/1YMvs5PkrrpxZdh-ltdrRpU_LBdpHd_BW/view?usp=sharing

After uploading:

To demonstrate this, I changed the timing to 0.5 seconds.

The onboard LED on the Analog Devices MAX32630FTHR starts blinking
This confirms:

Board is working
Code is running
Setup is successful

Next Step

In the next update, I will:

Connect the microphone module
Start reading real-time sound signals
Begin implementing sound-based detection

If there is a simpler or more efficient setup method, feel free to share your suggestions.

Don't Forget to Set - Project Overview

Alistair — Wed, 15 Apr 2026 18:46:55 GMT

This is a quick overview of what I am intending to build. I have been intending to post this since being accepted as an entrant, but despite it being a [mostly] copy and post job there were cool and shiny things that grabbed my attention instead. At last I am actually getting down to this.

The Problem

This project is to solve the problem of me forgetting to arm the alarm when I leave the house.

I get an audio reminder to disarm the alarm as soon as I open the front door, but there is no such reminder when I leave. The door is also used for garden and workshop access so a simple reminder chime is not a viable option.

What I need to do is identify when I leave the property and set the alarm, but not set the alarm when I remain on the property.

The Solution

This solution monitors the Bluetooth tracker on my keyring and identifies if it disappears soon after the door has been opened. If it has then I have gone elsewhere and the alarm should be set.

At the heart of the solution is the MAX32630FTHR. This scans for my Bluetooth tracker I have on my keys. The module is also connected to the Internet using the Ethernet Featherwing so it can signal when the tracker is no longer in range, and arm the alarm.

Stretch goals include using other sensors (such as the door opening sensor and/or PIR) to help prevent accidental settings, an audio/visual feedback to warn the user the alarm will be set, and a more physical button presser to set alarm systems that can not be controlled across the Internet.

Project Plan

Code the BLE scanning for the MAX32630FTHR.
Add network functionality using the WIZnet based featherwing.
Create an Alexa Smart Home Skill to enable the alarm. A bit of a hack but will work with most connected alarms.

Accessing the PAN1326B Bluetooth module with the Arduino IDE (Don't Forget to Set)

Alistair — Wed, 15 Apr 2026 10:48:58 GMT

Well that was a bit of a challenge, but I am now able to access the Bluetooth module on the MAX32630FTHR with the Arduino platform without hacking any of the core libraries. I honestly expected to be able to find a simple example online that I could work from, but one did not exist, so I have created that here.

The Arduino core for the MAX32630FTHR does not have any functionality built in for the PAN1326B, but it does expose the UART and the data pins, and includes the SDK for any other definitions we may (and will) need.

Before anything we need to include some SDK libraries with definitions for some flag addresses. I have seen many MAX3260 examples including many libraries that are just not needed or used, and all we need here are these two.

#include <pwrseq_regs.h>
#include <pwrman_regs.h>

The first thing I do is to pull the reset pin low (aka active) white we set up some other things. There is an obscure hardware bug in the module design that at times prevents the reset from functioning as it should later, so if we do this now it will insure the module is reset. I will cover more about this soon.

#define BT_RST P1_6
digitalWrite(BT_RST, LOW);

Next we need to change some low level settings in the microcontroller to enable a feature that puts the 32768Hz oscillator frequency on P1.7. The PAN1326B requires this frequency and this is a very convenient way of supplying that frequency without any extra hardware. A great design idea.

This is not built into the Arduino Core for the MAX32630FTHR, but the following command using definitions from the SDK will enable it.

MXC_PWRSEQ->reg4 |= MXC_F_PWRSEQ_REG4_PWR_PSEQ_32K_EN;

This also has a side effect of hijacking P1.6 (documented in the MAX32630 errata sheet), and you may have clocked that this is what we use for resetting the PAN1326B module. Luckily it is set to an input with a pullup so it will work most of the time. This does introduce issues with power cycling, but again I will come to that soon.

Now we need to set up the UART to communicate with the module. The module is hard wired with RX and TX on P0.0 and P0.1, with CTS on P0.2 and RTS P0.3 (documented on the schematic). The hardware supports hardware flow control, but the Arduino core does not. There is also an issue as the RX and TX lines are crossed when they should not be (or are not crossed when they should be, depending on your interpretation of RX and TX). I do not know if this was a mistake, or a simplification in layout that relies on software configuration, but the microcontroller allows the RX and TX lines to be inverted so all is good.

My approach was to keep things simple and use as much of the Arduino core as possible, and then go in after and change the required flags. There is little point changing any settings before using the Arduino command to initialise the UART as most settings will be overridden.

So here is what I do. First initialise the UART, that is UART0 on the microcontroller, that the Arduino core maps to Serial0. Then set the flags to enable the RTS/CTS hardware flow control, and swap the RX and TX lines.

Serial0.begin(115200);

MXC_IOMAN->uart0_req |= MXC_F_IOMAN_UART0_REQ_CTS_IO_REQ | MXC_F_IOMAN_UART0_REQ_RTS_IO_REQ | MXC_F_IOMAN_UART0_REQ_IO_MAP;

Remember, always change the settings after initialization or they will be lost.

Finally for the sake of completeness I then attempt to set the reset pin high to enable the module. Because of the aforementioned bug this makes little difference, but if this is ever changed in a future hardware update I would want my code to continue to work.

digitalWrite(BT_RST, HIGH);

Now a small issue that still remains is that sometimes the module will not start. After uploading the code it almost always starts fine. After a power cycle it is hit and miss, and often does not initialise. Physically resetting the module by pulling the MAX32630FTHR RST pin to GNG always appears to work. Using the SW1 (soft reset) button will continue to work if it did, and will not work if it did not when pressed (aka makes no difference). My assumption this is related to the 32KHz and P1.6 issue, as if so there is little I can do in code to address the issue. At least I can rely on the hardware reset.

To test we can send the HCI reset command to the module. We should get back 0x04, 0x0E, 0x04, 0x01, 0x03, 0x0C, 0x00 .

const char HCI_RESET_CMD[] = {0x01, 0x03, 0x0C, 0x00};
BT_SERIAL.write(HCI_RESET_CMD, sizeof(HCI_RESET_CMD));

And here is a complete test sketch…

#include <pwrseq_regs.h>
#include <pwrman_regs.h>

// PAN1326C2 HCI UART (use Serial on MAX32630FTHR)
#define BT_SERIAL Serial0
#define BT_RST P1_6

// Setup procedure
void setup() {
  // Open serial for debugging
  Serial.begin(115200);

  // Reset the PAN1326C2
  pinMode(BT_RST, OUTPUT);
  digitalWrite(BT_RST, LOW);

  // from 4.5.1.5.2 Enabling 32768Hz Oscillator Output on P1.7
  MXC_PWRSEQ->reg4 |= MXC_F_PWRSEQ_REG4_PWR_PSEQ_32K_EN;

  // Initialize HCI UART at default 115200
  BT_SERIAL.begin(115200);

  // Swap the RX/TX lines and enable CTS & RTS
  MXC_IOMAN->uart0_req |= MXC_F_IOMAN_UART0_REQ_CTS_IO_REQ | MXC_F_IOMAN_UART0_REQ_RTS_IO_REQ | MXC_F_IOMAN_UART0_REQ_IO_MAP;

  // Wait for initalisation 
  delay(200);
  
  // Enable the PAN1326C2 module
  digitalWrite(BT_RST, HIGH);

  Serial.println("Starting...");

  // Send the HCI reset command
  const char HCI_RESET_CMD[] = {0x01, 0x03, 0x0C, 0x00}; 
  BT_SERIAL.write(HCI_RESET_CMD, sizeof(HCI_RESET_CMD));
}

// The main loop
void loop() {
  if (BT_SERIAL.available()) {
    char data = BT_SERIAL.read();
    Serial.println(data, HEX);
  }
}

The solution was so simple. If only it was not such a journey to find it.

So I hope that is helpful. If anyone has any insight to the initialization issues then I would really love to know. If it can be fixed in software then that would make my life so much easier. Also I need to start talking HCI to the Bluetooth module. This should just be some donkey work, and I only need a few commands for my project, but I will look to see if there is an appropriate library I can use instead. Any recommendations are welcome.

Forum Thread 1 EchoGuard – Edge-Based Intelligent Security System | Project Kickoff & Unboxing

Nidhee — Sun, 12 Apr 2026 15:07:42 GMT

👋 Introduction

Hey everyone
Welcome to my project journey!

This is actually my first post in this series, and I’m starting a complete build log where I will develop a smart security system from scratch as part of the element14 Community Smart Security and Surveillance Design Challenge, in collaboration with Analog Devices.

I’m really excited to be part of this challenge and to document my full development process step by step.

🔐 About the Project – EchoGuard

For this challenge, I’ll be building a project called:

EchoGuard – Intelligent Edge-Based Security System

🤔 Why this idea?

Most modern security systems rely heavily on cameras.

But have you ever thought about what happens when:

It is dark
There is smoke
The camera is blocked

In those situations, visual systems can fail.

That’s where EchoGuard comes in.

👂 What is EchoGuard?

Instead of “seeing”, EchoGuard listens.

It uses sound-based intelligence to detect unusual events like:

Glass breaking
Forced entry
Sudden loud impacts
Distress sounds

And responds in real time using embedded processing.

🎤 Important Update (Hardware Plan)

Before going further, I want to mention an important addition:

I will also be using an external analog microphone module connected to the system.

This will allow EchoGuard to capture real-world sound signals and detect intrusion events accurately.

📦 Unboxing the Hardware Kit

Alright, now let’s move to the unboxing part.

“Let’s open the kit and see what we’ve got.”

🎁 Stickers

The kit also included some stickers from element14.

One of them says:

“Never enough women in tech”

I really liked this message because even though women are already part of the tech world, they are still underrepresented in many areas.

I believe more balance and representation in technology is important for the future.

Main Controller Board

The main board is the:

Analog Devices MAX32630FTHR

This is the brain of the system.

It is:

Low power
Programmable
Designed for embedded applications

It will run all the logic for EchoGuard.

🔧 Programming / Helper Board

This small board is used to upload code.

It does NOT run the project itself.

Think of it as a “messenger” that transfers code from computer to the main board.

🔌 Adapter Board

This is the:

FTHR-PMD-INTZ Adapter Board

It acts like a connector bridge.

It allows the main board to connect with additional sensor modules (like my microphone input later).

⚙️ Motor Control Module

Adafruit DC Motor + Stepper FeatherWing

This module allows control of:

4 DC motors
2 Stepper motors

In EchoGuard, it will be used for physical alert actions like:

Alarm movement
Mechanical warning system

🌐 Internet Connectivity Module

Particle Ethernet FeatherWing

This board adds internet connectivity using LAN cable.

It allows EchoGuard to:

Send alerts
Communicate with a system/dashboard
Enable remote monitoring

💡 Display Module

1. IC LED FeatherWing (7×15 Display)

This is a 7×15 intelligent LED display module.

It is capable of:

Displaying text
Showing patterns
Creating smoother visual effects

This will be used for:

Detailed messages like “SAFE”, “ALERT”, “INTRUDER”
Better readability and clearer status indication

2. Adafruit CharliePlex LED Matrix FeatherWing

Adafruit CharliePlex LED Matrix FeatherWing

This is a compact LED matrix display.

It is ideal for:

Simple icons
Quick visual indicators
Low-power display output

In EchoGuard, it will be used for:

Symbol-based alerts (e.g., warning icon ⚠️)
Fast visual feedback during detection

🚀 What’s Next?

In the next steps, I will:

Test each hardware module individually
Start reading microphone signals

📌 Closing

This is just the beginning of my EchoGuard journey.

Stay tuned for the next update!

Forum#2 - MAX32630FTHR Development Environments - Adaptive Sentinel: Security Intelligence & Surveillance Hub

skruglewicz — Fri, 10 Apr 2026 04:46:50 GMT

Hey everyone!

I received the Sponsored Challenger Kit on Wednesday April 9, 2026. I unboxed the kit and took inventory of the contents. Everything was there, including some neat stickers from Element14. Unboxing other evaluation kits, I’m refered to some sort of “getting started” path to become familiar with the device. I did not find one in the MAX32630FTHR package?Since I never experimented with it, I decided to do some research to try and figure out what to do with this thing.

I noticed some confusing labels on the Analog Devices product page—specifically that this board is "Not Recommended for New Designs" (NRND). What I surmise is it just means ADI isn't pushing it for mass-market commercial products anymore. Turns out, the MAX32630FTHR is an older generation chip. While it’s reliable, ADI has moved their focus to newer chips like the MAX32650 and the MAX78000 (AI-focused) series which are supported by the modern MSDK. For us hackers and makers, it’s still a powerhouse with a great FeatherWing form factor right.

OK Fine.. then I stumbled onto the Arm Mbed OS website MAX32630FTHR | Mbed and I see Mbed is reaching “End of Life” in July of this year 2026, plastered on this page and all over the website. Apparently, Mbed OS is being phased out in favor of newer IoT frameworks, making it a "legacy" choice for this board.

Ok, now I’m beginning to wonder how the heck to program this thing. I hear you can use the Arduino IDE from fellow challenger Alistair (check out his forum post Programming the MAX32630FTHR with the Arduino IDE (Don't Forget to Set) - element14 Community). Then I hear that another challenger arvindsa is going to use LPSDK ( check out https://community.element14.com/challenges-projects/design-challenges/smart-security-and-surveillance/f/forum/56840/identity-protocol---part-3---unboxing-and-blinking-with-maxim-lpsdk ) .

I stopped in my tracks and before jumping on the band wagon and starting installing development environments, I decided to write this blog for this forum post. I’m a software Engineer and interested in embedded programming tool chains (there’s a lot of them out there). I am now interested in finding out more about these two environments, and I find there is a third option available.

So here's a breakdown of how to actually program this thing in 2026.

Supported Development Environments

Environment	Pros	Cons
Arduino IDE	Massive library support; easiest for beginners; familiar "Blink" workflow.	Harder to do deep register-level optimization; abstraction hides hardware complexity.
PlatformIO (VS Code)	Professional-grade; handles both Arduino and Mbed frameworks; great for version control.	Steeper learning curve than Arduino; requires manual environment switching.
Maxim LPSDK (Eclipse)	Official C/C++ access is provided at the "bare-metal" level. This includes the original examples and drivers, encompassing all the bare-metal register files, peripheral drivers, and original C examples.	Legacy software; Eclipse can be "clunky"; no longer receiving major updates.
Mbed OS (Legacy)	Built for ARM; great hardware abstraction for RTOS features.	End of Life (EOL); online compiler is gone; community support is fading.

MY Choice for Beginners: Arduino IDE

If you want to get a "Blinky" running in under 5 minutes, go with Arduino. Analog Devices maintains an official Arduino Core for Maxim git repo for Maxim's MAX326xx series based Boards.

Blinky Battle: Comparing the Frameworks

To see the differences in how these environments "think," let’s look at how they handle the onboard Green LED (P2_5).

1. The Arduino Way (Procedural)

C++

#include <Arduino.h> void setup() { pinMode(LED_GREEN, OUTPUT); } void loop() { digitalWrite(LED_GREEN, LOW); // Active Low on this board! delay(500); digitalWrite(LED_GREEN, HIGH); delay(500); }

Why it’s different: It uses the standard setup/loop structure. It’s simple, but it hides the fact that you're interacting with a complex ARM Cortex-M4F.

2. The Mbed Way (Object-Oriented)

C++

#include "mbed.h" DigitalOut green_led(LED_GREEN); int main() { while(1) { green_led = !green_led; // Toggle logic thread_sleep_for(500); } }

Why it’s different: Mbed treats the LED as an "Object" (DigitalOut). It feels more like modern C++ and is built for multi-threaded applications.

3. The Bare-Metal / LPSDK Way (Register-Level)

C++

#include "mxc_device.h"
#include "gpio.h"
int main(void) {
const gpio_cfg_t led = { PORT_2, PIN_5, GPIO_FUNC_OUT, GPIO_PAD_NONE };
GPIO_Config(&led);
while (1) {
GPIO_OutToggle(&led);
for(int i=0; i<1000000; i++) { __NOP(); } // Manual delay
}
}

Why it’s different: This is "the real deal." You are talking directly to the GPIO registers. It’s extremely efficient but requires you to understand the hardware datasheet inside and out.

I plan to try all Supported Development Environments mentioned above, starting with the Arduino IDE to verify my hardware works. Then,to move on to PlatformIO in VS Code. It gives you the best of both worlds: the ease of either using Arduino code or Legacy Mbed code. I might try Maxim LPSDK, since I'm familiar with Eclipse.

To set up a development environment for the MAX32630FTHR on Windows, you have several options ranging from beginner-friendly to professional-grade toolchains. Since Mbed OS is deprecated, the Arduino IDE or PlatformIO are now the recommended paths.

Required Hardware

For all environments, you must use a MAX32625PICO (DAPLink adapter) and a 10-pin ribbon cable to flash code to the MAX32630FTHR.

To prepare the boards for programming follow these steps:

Connect the MAX32625PICO to the MAX32630FTHR board with the fine pitch 10 pin ribbon cable.
Apply power to the MAX32630FTHR board through a micro USB connector.
Connect the MAX32625PICO to a computer through a micro USB connector.

My host PC is running Windows 11. Once the hardware is connected and the MAX32625PICO is plugged into the computer, the system automatically creates a new COM port and mounts the device as a USB drive.

As shown in the Device Manager below, the board is recognized as COM15:

Additionally, the DAPLINK drive appears in the file system. Upon first connection, it contains two default files:

1. Arduino IDE (Highly Recommended for Beginners)

The simplest way to get a "Blinky" running quickly.

Download & Install:
1. Download the latest version from the Arduino website.
2. Run the installer and follow the standard Windows prompts. I have installed version 2.3.8
Configure:
1. Open Arduino IDE and go to File > Preferences.
2. Paste this URL into Additional Boards Manager URLs:
  1. Go to the preferences screen (File, Preferences) add https://raw.githubusercontent.com/analogdevicesinc/arduino-max326xx/master/package_maxim_index.json to the list of “Additional Boards Manager URLs”.
3. Go to Tools > Board > Boards Manager, search for "maxim", and install Maxim's 32-bit Microcontroller.
4. Select your board: Tools > Board > Maxim ARM (32-bit) Boards > MAX32630FTHR.
5. Select a Port : Tools >Port
6. Set the programmer: Tools > Programmer > DAPLink.
Compile & Run Blinky:
1. Open the example: File > Examples > 01.Basics > Blink.
2. Connect the board via the MAX32625PICO adapter.
3. Click the Upload arrow icon.
Results:
- Here is the IDE after the Upload. Success the LED is blinking using the example code.
Windows gotchas
- Since I'm using Windows11, II ran into a few problems that I was able to resolve
- Mbed serial driver is required.
  - If you are a Windows user and do not already have the mbed serial drivers installed, then you will need to download and install them from https://os.mbed.com/handbook/Windows-serial-configuration
  - I need to get this since I'm running Windows 11. But my Chrome browser did not work on the download link, so I needed to use another browser.
  - Now that Mbed serial driver is installed , the device manager shows a different COM port from the initial connection of COM15. The port is now COM16 as shown below.
- Upload Fails
  - When I clicked the Upload icon, the upload failed. The following error appeared:
  - So what is happening? I researched this and found my Arduino IDE for the MAX32630FTHR is trying to use a legacy Windows tool called wmic that Microsoft has recently disabled or removed in Windows 11.
  - Via Command Line : Open Command Prompt or PowerShell as Administrator and run:
    - DISM /Online /Add-Capability /CapabilityName:WMIC~~~~
      - After this, restart the Arduino IDE and try your upload again.

Ok this is my Arduino setup completed on to the next environment.

Update: APR 15,2026

2. Mbed - PlatformIO Extensions (VS Code)

PlatformIO is a professional-grade VS Code Extension that provides a unified development environment capable of handling multiple frameworks—like Arduino and Mbed—seamlessly in one place.

Mbed OS (Legacy) is still supported via PlatformIO as a local framework, which is a lifesaver now that the online compiler is gone. While it's officially End of Life (EOL) and not recommended for new projects, you can still compile and run your code locally. Just select "mbed" as your framework when creating a project in PlatformIO to keep working without those discontinued online services.

- Download & Install:
  1. Install Visual Studio Code.
  2. Open VS Code, click the Extensions icon, search for "PlatformIO IDE", and click Install.
- Configure:
  1. Click the PlatformIO (Ant) icon and select + New Project.
  2. Name your project and search for a board: "Maxim MAX32630FTHR".
  3. Mbed as the framework.
- Compile & Run Blinky:
  1. Replace the contents of src/main.cpp with the blinky code. Add this Mbed code from the above section "2. The Mbed Way (Object-Oriented)".

#include "mbed.h"

DigitalOut green_led(LED_BLUE);

int main() {

while(1) {

green_led = !green_led; // Toggle logic

thread_sleep_for(500);

}

1. Connect your board via the DAPLink adapter.
2. Click the Checkmark (Build) and then the Right Arrow (Upload) on the bottom status bar.

Result
- LED is blinking GREEN now.

3. Maxim LPSDK (Eclipse-based Legacy)

Official bare-metal environment specifically for older chips like the MAX32630.

Download & Install:
1. Visit the MAX32630 Product Page and go to Tools & Simulations.
2. Download the LPSDK for Windows.
3. Critical: Install it in a path without spaces (e.g., C:\MaximSDK\) to avoid build tool errors.
Configure:
1. Launch the bundled Eclipse IDE.
2. Import an existing project: File > Import > General > Existing Projects into Workspace.
3. Navigate to the Examples/MAX32630/Hello_World folder within the SDK directory.
Compile & Run Blinky:
1. Right-click the project and select Build Project.
2. To run, right-click the project and select Run As > Maxim C/C++ Application (ensure your DAPLink is connected).

Thanks for reading my blog. hope you find it helpful. I'll be experimenting with these development environments over the next couple of days. Stay tuned and let me know what development Environments you are having success with programming the MAX32630FTHR