Thingy:53 – Multisensor Firmware Development, USB CDC Issue and AIDA PUSH Project

Hello Nordic Semiconductor Support Team,

My name is Marius, and I am the founder of AIDA AS, a Norwegian engineering company working with industrial engineering, HVAC systems, offshore installations and technology development.

We are currently developing AIDA PUSH, Predict the Failure. Prevent the Cost. AIDA PUSH is intended to become an industrial condition-monitoring and predictive-maintenance platform.

Our objective is to develop a compact, intelligent sensor system capable of continuously monitoring industrial equipment, identifying abnormal operating conditions and detecting potential failures before they result in equipment damage or unplanned downtime.

Typical applications include:

  • Electric motors, pumps and fans

  • Gearboxes and rotating machinery

  • Bearings and mechanical components

  • Valves and actuators

  • Engine blocks and powertrain components

  • Offshore and industrial HVAC equipment

We have selected the Nordic Thingy:53 (nRF5340) as our initial development platform because of its integrated sensors, processing capabilities, Bluetooth connectivity and support for Zephyr RTOS.

Our immediate objective is to develop a single firmware application that can operate all, or as many as practically possible, of the Thingy:53's onboard sensors simultaneously.

We are particularly interested in:

  • BMI270: Accelerometer and gyroscope

  • ADXL362: Low-power accelerometer

  • BMM150: Magnetometer 

  • BME680: Temperature, humidity, pressure and gas resistance 

  • BH1749: Light and color sensor

  • PDM microphone: Acoustic measurements and analysis

  • Bluetooth LE: Wireless communication

  • USB CDC ACM: Communication, diagnostics and data streaming

  • External flash: Local data storage

The firmware should support concurrent sensor acquisition with configurable sampling rates, timestamps and buffered data processing. Our intention is to combine multiple measurements to identify changes in equipment condition. For example, a motor could be monitored through vibration, acoustic measurements and temperature trends simultaneously. We also intend to implement:

  • FFT and vibration frequency analysis

  • RMS calculations

  • Sensor fusion

  • Baseline measurements and trend analysis

  • Anomaly detection

  • Local processing and wireless transmission

In a later development phase, each physical PUSH device will be associated with a specific asset and component, such as a motor, gearbox, bearing or valve. This will allow us to maintain individual equipment histories and develop asset-specific condition-monitoring algorithms.

Our current setup is:

Hardware

  • Nordic Thingy:53

  • nRF5340 application processor

  • USB connection to a Windows development PC

Software

  • nRF Connect SDK v3.4.1

  • Zephyr RTOS

  • Visual Studio Code with Nordic extensions

  • West build system

  • MCUboot / sysbuild

  • nRF Connect for Desktop Programmer v4.8.0

We are experiencing difficulties getting our custom application to start and communicate after flashing. The following steps have been verified:

  1. The application builds successfully without compilation errors.

  2. The Thingy:53 is recognized by Windows when started in MCUboot DFU mode.

  3. nRF Connect Programmer detects the device.

  4. The generated DFU package is accepted by Programmer.

  5. Firmware transfer completes successfully.

The Programmer reports:

"MCUboot DFU completed successfully!"

However, after disconnecting and reconnecting the device in normal operating mode:

  • The device does not appear as a USB CDC ACM COM port.

  • Windows does not detect an expected USB device.

  • We receive no serial output.

  • We cannot confirm whether our application is executing.

  • No visible LED indication confirms application startup.

We have enabled the following configuration options:

CONFIG_I2C=y
CONFIG_SENSOR=y
CONFIG_BMI270=y

CONFIG_CONSOLE=y
CONFIG_PRINTK=y
CONFIG_STDOUT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_BOARD_SERIAL_BACKEND_CDC_ACM=y

CONFIG_LOG=y
CONFIG_LOG_DEFAULT_LEVEL=4

We have also added an early startup message in main():

printk("AIDA PUSH: MAIN STARTED\n");

However, we cannot observe this message because USB communication is not established during normal operation.

At this stage, we do not know whether the problem is related to:

  • MCUboot image compatibility or activation

  • USB CDC ACM configuration

  • Devicetree configuration

  • Application initialization

  • Sensor driver initialization

  • Incorrect build or flashing configuration

We would appreciate guidance on the recommended configuration and debugging procedure for this hardware.

Questions

Does enyone have an existing reference application, demonstration project or GitHub repository that supports simultaneous operation of all or most Thingy:53 sensors? We are specifically looking for a working application with source code that we can use as a foundation for further development.

What is the recommended approach for concurrent acquisition from multiple Thingy:53 sensors using Zephyr RTOS? Would Nordic recommend separate threads, asynchronous sensor APIs, message queues or another architecture?

Is there a known working configuration for USB CDC ACM on Thingy:53 using nRF Connect SDK v3.4.1 and MCUboot? Are there specific board configurations, overlays or bootloader considerations we should be aware of?

Could you advise how to verify that our generated firmware image is compatible with the MCUboot version installed on the device, and how to confirm that the application has actually started after DFU?

Are there recommended Nordic or Zephyr libraries for implementing FFT, RMS calculations and real-time vibration analysis on the nRF5340?

Are there any existing Nordic reference projects combining multiple sensors, Bluetooth LE, USB communication and local data logging?

Our long-term intention is to develop AIDA PUSH into a scalable industrial monitoring platform. The Thingy:53 is our initial prototype and software development platform. As the project matures, we intend to develop custom hardware using Nordic Semicondssible. Any guidance, example projects or recommendations from you would be greatly appreciated.

Thank you for your time and support.

Best regards,

Marius
Founder / CEO
AIDA AS
Norway

AIDA PUSH – Predict the Failure. Prevent the Cost.

Parents
  • Hello Marius,

    Since the application fails to boot and doesn’t print any logs, an external J-Link is really needed to debug the issue further. I would recommend using an external J-Link for programming and debugging anyway if you plan to do any active development on this device. Our DKs have a Debug out port that lets you use the on-board J-Link with external boards such as the Thingy. Either way, as a first step here, I would try one of the SDK samples that are tested on this board target, if you haven’t done so already of course. For example, the Bluetooth: Peripheral LBS sample which I also think can be a good project to use as a starting point. Next step can then be to start enabling the sensor acquisition for one sensor at a time.

    The nRF54LM20b may also be worth considering as a potentially more proof SoC in case you are able to utilise the NPU: https://www.nordicsemi.com/Products/nRF54LM20B & https://www.nordicsemi.com/Products/Technologies/Edge-AI 

    Best regards,

    Vidar

Reply
  • Hello Marius,

    Since the application fails to boot and doesn’t print any logs, an external J-Link is really needed to debug the issue further. I would recommend using an external J-Link for programming and debugging anyway if you plan to do any active development on this device. Our DKs have a Debug out port that lets you use the on-board J-Link with external boards such as the Thingy. Either way, as a first step here, I would try one of the SDK samples that are tested on this board target, if you haven’t done so already of course. For example, the Bluetooth: Peripheral LBS sample which I also think can be a good project to use as a starting point. Next step can then be to start enabling the sensor acquisition for one sensor at a time.

    The nRF54LM20b may also be worth considering as a potentially more proof SoC in case you are able to utilise the NPU: https://www.nordicsemi.com/Products/nRF54LM20B & https://www.nordicsemi.com/Products/Technologies/Edge-AI 

    Best regards,

    Vidar

Children
No Data
Related