Nordic Semiconductor Acquires Memfault

Nordic makes some good products. When I was doing hardware design for a product that uses a battery my options for power profiling were either not to do it or spend some eye watering amount of money. Then I discovered Nordic makes the PPKII, a cost effective, highly accurate profiler with quite good software. I detect good things in store for the company just based on the quality of stuff they have been putting out.

Looks like it switches different ranges. ST makes something similar that has similar dynamic range without switching. They use analog circuitry (op amps and junk) to compensate for the resistor drop, so the path is uninterrupted. I've had systems where the auto-ranging on a bench meter is enough to cause it to reset. I can't find a schematic for the PPKII (haven't looked too hard though) but if it's actually switching the supply, that can cause issues to devices downstream. Especially if that switching causes a voltage drop change.

> Nordic makes some good products

and godawful software. the SDK for their NRF52/3/4 is pure madness, i haven't even managed to set up the toolchain, documentation always out of date. They used to have another toolchain for the older parts, but good luck setting it up now.

It switches the detection range, but not the actual power supply. You can ramp from <5 uA up to 500 mA and back all you want. I haven't noticed any glitching on the actual supply.

Schematics: https://www.nordicsemi.com/Products/Development-hardware/Pow...

The PPK2 is one of the best pieces of kit I have and it'd be worth it at 5x the price.

There's an unofficial Python library as well. I have power consumption tests running as part of my automated firmware test suite.

Segger Embedded Studio is a complete solution. One installer. You might need to pick an older version to go with an old SDK version, but its very straightforward.

Do they have nice open-source SDKs for these nice products?

Congrats, sounds good for everyone.

The TinyCurrent or uCurrent can be used for this as well when paired with a scope with scpi. However, the ranges aren't dynamic which is annoying if you're using something a WiFi part where you're going from uA to 200mA.

https://n-fuse.co/devices/tinyCurrent-precision-low-Current-...

I'm sorry you've had a bad experience but I don't agree, I prefer it to the ST, TI and definitely the Microchip tooling. It's CLI first, like the Espressif and Pico tooling which is a big plus for some and not for others.

Also, no mandatory login walls for toolchains and datasheets gets them a lot of goodwill in my book.

I'm proficient with many MCU families.

Microchip tooling: download, double click, install, just works. Zero need for any framework, good bare metal support. a C project is an actual C project. Granted, if you use that MCC piece of shit you're in for a bad time, but going bare metal require zero effort, a single include file if you need to access peripherals, and you actually have documentation to do so.

ST tooling: sort of almost just works, more effort but you can still go bare metal with relative ease.

Current nordic: it's actually a zephir project, thousands of files to generate and compile. No options to go bare metal. (used to be possible with the older SDK, or so they tell me. Too bad i can't seem to be able to let a project compile with the old SDK, or set up the IDE for intellisense with the new SDK, but i haven't had enough time yet.)

Bonus: Espressif. At least their VSCode integration really just works. The peripherals are frustrating and severely bugged though and there can be supply chain issues, and that's the reason i'm looking at nordic for some BLE-enabled project, because the ESP32 parts won't cut it for this or that reason (usually the basic yet still bugged peripherals).

But i'm willing to put up with microchip's BLE modules again (i evaluated them several times over the years, always a disaster. But not the newer based on PIC32MZ, and the price have come down to be reasonable.) if the only option with nordic is the zephir monstruosity.

I don’t think most have this experience. Zephyr is the future.

I mean, you _can_ go bare metal with Nordic chips, but you'd definitely be swimming against the current. I'm not a fan of Zephyr, but it really wasn't that much trouble to put together a docker image that would let me spin up whatever version of the SDK I needed and then just build from the docker. Quite tolerable.

I'm working with NRF5 SDK. Most of its source is available (no idea if it's free software or not, but sources are there). The most glaring exception is softdevice - that's BLE implementation, it's huge binary blob, taking control over most CPU.

Their newer SDK based on Zephyr RTOS, I didn't work with it, but I think it's mostly open source as well.

I completely agree. I spent lots of time trying to figure out their modern SDK, but in the end I abandoned it and just used their old SDK. Their examples and approach are terrible, but in the end I was able to make it work, after untangling the holy mess of macros they put there. Their old SDK is bearable, their new SDK... I still think I need to go there, but I don't have enough willpower to do that. So much moving parts. Custom build system, not just one, but actually three of them at once (cmake, ninja, west). The whole RTOS which I never needed. And not just simple one like FreeRTOS, but absolutely humongous one. Add their terrible software which they insist I must use to install their stuff. Just give me zip, I don't want to install nothing.

Let me write simple Makefile, give me thin layer over CMSIS called SDK and that's all I need. Don't make things harder than they should be, my project is simple, I don't need operating system for it.

I spent so much time trying to get the SDK working for NRF52 that I genuinely just gave up and redesigned our whole product to use an ESP32 instead of the NRF plus other uC.

I think that is genuinely the reason espressif is eating everyone's lunch. All the old players in the IC business have such inexcusably bad SDKs that the acceptably designed and documented ESP-IDF framework just makes the most sense to use. Why would I spend six weeks fighting with Nordic SDKs with their weird system-wide installation when ESP-IDF can be set up in five minutes isolated to your user directory?

Seriously, it takes longer to find the correct Nordic SDK installer than it does to git clone, idf.py install, ./export.sh

And Nordic's weird documentation web portal is just egregiously bad. Espressif puts it in a static HTML page with a selector for the framework version. It's simple, elegant, and fast.

I did like using the NRF52 once it was finally behaving, but the ESP is just so easy.

Installing a whole toolchain and SDK system-wide is such nonsense.

Espressif's toolchain and SDK are in a git repo that you add as a submodule, or in a directory anywhere you want.

If I want to use microchip or Nordic on a new machine I have to go through this whole process of installing and configuring everything. My ESP projects simply involve a git pull and I'm done.

Nordic was a special pain in the ass because I had to hunt for the exact correct version of the SDK which was hidden away because it's a few versions old. If I need to do the same for espressif, it's literally just a git switch away.

Espressif is in an entirely different league from ST, nordNordic, et al. They're not even playing the same game. Espressif wants anyone and everyone to use their stuff and ST seems to actively hate developers and only want to work with companies buying tens of thousands of units. Like, ST cripples their USB programming tool to only accept 'genuine' ST parts. It's frankly disrespectful.

I've had bad experiences with Zephyr in the past. It's been half-baked and passed around from company to company for ages.

Be Linux or don't be Linux, but don't be halfway between the two.

I have a lot more hope for PX5.

With the onset of cheap 16-bit, 18-bit or even 24-bit sigma delta ADCs, it isn't a very hard circuit to shove a 1 Ohm sense resistor, 2.048V reference and have sensing down to 31uA (16-bit), 8uA (18-bit) or less for 24-bit ADC.

SigmaDelta gets pricy if you want higher speeds though. But it's possible.

I actually disagree.

We have lower power bare metal systems, think AVR/STM stuff (in the 1Mhz to 50Mhz range with 128K or less of RAM) here FreeRTOS, no freeRTOS, custom driver code and some basic application code makes sense. For simple to very complex systems.

Then there's 1Ghz+ stuff with an MMU and 2GB+ RAM. Linux makes sense here.

Companies are now making chips 200Mhz+, 4MB RAM, with no MMU. This is precisely where Zephyr excels, you want a full networking stack? Switch that on. A file system, easy. Driver for some more complex thing? Maybe an SDIO radio? boomboom

Congrats to the Memfault team!

nRF52820 is 256 KB Flash and 32 KB RAM chip. Actually it's around 150 KB flash, because you need space for 120KB softdevice blob (and some RAM too). And it's perfectly enough for many devices. They want developers to use Zephyr for this chip.

I'm the co-founder and CEO of Memfault. We were in the W19 YC batch. I never thought our news would make the front page of HN!

This is a very exciting day for us (after a very intense few months). We've known the Nordic team for years and could not think of a better partner to grow our platform.

Happy to answer questions, if you have them.

It's all on Github (https://github.com/nordicsemiconductor), but it is not technically open source as it is a modified BSD that does not let you use the SDKs with other chipsets.

Thank you!

Thank you!

I've found old SDK actually not that bad. Documentation is not great, but sources are available and it's just mostly C code with some hairy macros, but it's manageable. After few weeks I became quite proficient. I don't like their suggested approach "copy&paste example you like and tinker it", I never do that, so I had to untangle their Makefiles, I had to research their defines (app_config.h, what's a monstrosity), I had to write my own linker scripts, but in the end I have my application under control and it's all standard gcc toolchain, no fancy stuff.

I have the ST one (X-NUCLEO-LPM01A), but its range is actually not enough for something like an ESP32, it goes into "overload" as the max current is 50mA for dynamic (100kHz bandwith) and 200mA for "static" measurements.

Looks like the PPKII can do up to 1A.

This is great news. We are implementing memfault, probably in September/October period, but were struggling with the pricing model for long-term growth.

I'm assuming Nordic gives the company the support and reach their mission and discover a more workable business model.

> I don't like their suggested approach "copy&paste example you like and tinker it", I never do that, so I had to untangle their Makefiles, I had to research their defines (app_config.h, what's a monstrosity), I had to write my own linker scripts, but in the end I have my application under control and it's all standard gcc toolchain, no fancy stuff.

Sounds very similar to ST.

You can use NimBLE on quite a few of these chips.

"allows customers to focus on innovation – free from the burden"

Sounds great, but does it actually mean lock-in, in reality?

Hi Pete -- email me (francois at) and I'll get you early enrolled into the special deals we have coming for Nordic customers.

Every vendor you bring in comes with switching cost, and this is no different. But we do our best to make it easy for folks to migrate off of our platform should they decide.

Love that most of the comments here are love for PPKII

Strong agree with all those comments - it’s a great little tool at a great price!

> Throughout the product lifecycle, continuous software upgrades strengthen the security, performance, power consumption, and functionality of products in the field.

This doesn't feel right to me. Back in the day when I started in embedded systems you would have to get it right before you shipped it. That had it's own problems of course, but at least you knew where you stood and if something worked well it would continue to work well until the hardware died.

Also I think the right word grammatically is continual not continuous. I suspect they changed it because continual software upgrades sounds terrifying.

In hindsight I think the correct word would be "regular software upgrades".

i did not use Nordic-Zephyr, but i have run Zephyr on ESP32/STM32.

It's true that the learning curve is very step, but their idea is reasonable.

The execution is ... not that good at this moment imo. It's nearly impossible to debug device tree "macro hell", the preprocessor is not designed to debug that, and they abuse the hell out of it.

Also i'm wondering why you dont want "RTOS", in Zephyr setup, your entry point is still old boring "main" loop.

i dont like espressif build system.

like "component" directory in cmake, or just call our "cmake function" to include this source files. Or modify this variable to add your custom dir.

Why they can't just stick with vanilla cmake ?

That's the reason i run Zephyr on esp32, no cmake nonsense from espressif.

Don't keep us guessing -- what was the bag?

I have been developing firmware for Nordic chips for about 5 years now, and I have roughly the same amount of experience with Memfault.

The idea of Memfault is like Datadog for IoT stuff. The reality of Memfault is that everyone just uses it to push OTA firmware upgrades through the cloud, and capture stack traces on crashes. Sometimes you bolt on their metrics later, but 95% of the value is in OTA firmware upgrades and crash reports.

Nordic has started to assemble a juggernaut of a tech stack, and a collossal moat. They keep most of their Zephyr contributions outside the main source tree, in something they call the nRF Connect SDK. They've been developing vendor-specific extensions to Memfault's SDK for years.

The upside with Nordic is you get a complete embedded tech stack out of the box. The downside is that, if their stack doesn't doesn't offer what you need, you have to grapple with the incomprehensibly complex SDK in the entire industry. For some companies, it works great. For others, it's an attractive nuisance.

I don't know how much actually changes for either company with this acquisition. It probably isn't good news if you're ST, Infineon, or Microchip.

Love Memfault, very happy customer. Hopefully this is a great exit for everyone and a great future for the products.

That was actually very much close to my use case - ESP32 modules sit right in this range.

Parsing the stock exchange notice [1], the three founders seem to have received 42 Million USD. If they had the same amount of shares, they received around 14 Million each.

> The three founders of Memfault - CEO Francois Baldassari, CTO Chris Coleman and VP Developer Experience Tyler Hoffman – will reinvest 30% of their share sale proceeds in Nordic Semiconductor shares, totalling approximately USD 13 million.

[1] https://newsweb.oslobors.no/message/649971

Moved to nordic nRF52840 based system (RAK) because of the 9mA average draw to run Meshtastic for LoRa radio at 900mhz. Longest link so far from flat land is about 40 miles. Moving up the mountain to see what improved line of site can do.

Nordic chip is super impressive and power efficient compared to ESP32

The BLE library at least is plain BSD-3-Clause. Most of the other ones are the same, a few don't have licenses applied though. Which repo has the modified BSD license?

Wow! That's an impressive bag!

Yeah, it's pretty weird.

But for the most part, I find it pretty easy to ignore and use a more vanilla style of cmake. It all works fine without the component stuff

How will tariffs affect where these pcbs are built?