Looking at BLE SOCs, nRF52

[janoc]

And using nRF's softdevices, you can't have them both since they are so bloated they won't fit.

They probably would fit in the larger parts but you can't have multiple of them because they are an RTOS + protocol stack using the same hardware peripherals, so they would conflict. They are not designed to be interoperable and allow to use multiple protocols on the air at the same time.

And actually you can't have BLE either because it's still so bloated you are left with some tens of KB for your whole app, which is just ridiculous. 

Which is often plenty and all that you need. If you are using the low end parts with little flash you are likely implementing some low power sensor or a little gizmo controlled by a phone (e.g. "smart lightbulb"), so there isn't going to be a lot of sophistication in there. If you need more, you use nrf52832 or nrf52840 instead which have 0.5-1MB of flash, USB, NFC support and what not.

Don't know about the new Zephyr route but probably it's as bloated.

It is +/- the same. However, that's the "tax" of using these complex protocols like Zigbee or BLE. If all you need is exchanging a bunch of packets and don't need any interoperability, just use Shockburst and be done with it, no need to implement the protocols from scratch by driving the radio directly. Then you don't need any softdevices either. And you will still be able to talk to the old school nrf24L01+ devices which use it ...

[janoc]

the softdevice (basically a proprietary RTOS blob encapsulating their RF black magic)

I did hear these magic words a lot and I simply hate it; there is absolutely nothing RF nor nothing magic in softdevices.

The "RF black magic" is meant to be the protocol stack. If you fancy to implement something like BLE/Zigbee or ANT+ protocol stack, be my guest. However, most people aren't masochists enough to do so and/or have better things to do with their time.

Moreover, these stacks are proprietary, which is why Nordic ships them as binary "softdevice" blobs. There is an open source BLE stack in Zephyr not requiring the softdevice but there isn't (AFAIK) a Zigbee one or ANT+ one.

And I'm pretty sure softdevices do not use any kind of RTOS, just normal interrupt driven code, they even list the timers and other peripherals they use so that you can avoid using them in your own code. But of course I could be wrong.

Of course they list the used interrupts and times, any RTOS would need that too. Implementing something as complex as BLE without an RTOS would require a very special kind of crazy, IMO.

In any case, to me these softdevices look like much larger than I would expect them to be, and total lack of simple examples of how to use them is devastating.

That's because they are not meant to be used for "simple" use cases. The softdevices implement the complex protocol stacks like BLE or Zigbee, there is no way to make those "simple" or "not bloated". If all you need is to flick a few packets through the air, use Enhanced Shockburst and be done with it. For that you don't even need any softdevice.

[Siwastaja]

It seems you arrived at circular proof that because nRF folks ended up with 150-200KB+ implementations of said protocols, these protocols must be this complex. I choose to disagree. For example, I think Zigbee stack has been implemented on some PIC microcontrollers, and it's nearly two decade old stuff.

I have good reasons to believe the bloatness goes into these proprietary, closed binary blobs, from what I have seen from the code they have published, for example just simple "print text to UART" implementation being thousands of LoC.

But as they are closed and as I have no interest of disassembling and reverse-engineering them, I have no hard evidence, no interest in obtaining it, and could well be wrong.

edit: for example, Apache NimBLE seems much smaller already (http://events17.linuxfoundation.org/sites/events/files/slides/Mynewt%20BLE%20-%20ApacheIoT.pdf page 16). I don't know what would be the difference between "base" and "complete" versions but assuming base would suffice, host+controller would be just 48KB, equivalent SoftDevice is over 200KB IIRC.

Enhanced Shockburst is way too simplistic and lacks basic features for robust communication over license free bands, e.g. frequency hopping, but I kind of liked it as it was one of the only sane examples they offered. That was my starting point. When I added frequency hopping over what was basically a copy of "ESB", the improvement in radio range (between my living floor and concrete basement) was just massive.

And I don't think that one can fundamentally choose that BLE and Zigbee cannot coexist. Why are the products marketed as if they support all these protocols if you have to fix it design-time? You sure can talk both TCP and UDP through a single Ethernet PHY, and you sure can share radio time between BLE and Zigbee so it's an arbitrary limitation. Given shared resources, you could always time-division multiplex them. It's surely not easy to implement but seeing these "secret magic" implementations are so large one could maybe expect they also would deliver such special features.

In fact, the project I'm currently working on could have some customer demand for combined BLE and Zigbee and despite not high on priority list, I'm keeping my eyes on if it could be implemented with less than 100KB of flash, and single radio. You probably say it's impossible, but I have been doing these "impossible" (to some) things before. In the meantime, we are going with my own "masochistic" protocol which works great and is just a few K, with the obvious limitation of no interoperability but no one has asked for it - yet.

[cv007]

The RADIO peripheral gives you all the low-level BLE long range greatness

I realize that, but my question was whether you use ble or not. I take it the answer is no. For anyone wanting to use ble with these mcu's, as the original post indicates, the reason is most likely that there is a requirement to communicate with a cellphone. The self-designed rf protocol is useless if that is the case.

[janoc]

It seems you arrived at circular proof that because nRF folks ended up with 150-200KB+ implementations of said protocols, these protocols must be this complex. I choose to disagree. For example, I think Zigbee stack has been implemented on some PIC microcontrollers, and it's nearly two decade old stuff.

I invite you to read the specification of BLE, try to implement it and then you would have a leg to stand on to complain about bloat. Until then you are only ranting about stuff based on guesses and (wrong) impressions. The "Core Specification" for Bluetooth has "only" 3000+ pages and that's without the specs for all the extra profiles, etc. - that's thousands of pages extra.

The low energy controller part relevant for implementing BLE is 440 pages by itself. On top of that you have all the various services, profiles, etc. that you will need for a practical application, such as GATT, HID over GATT, the mandatory crypto, bonding, etc.

Good luck.

I don't have any illusions about code quality in any proprietary blobs but the "bloat" you are ignorantly ranting about is the direct consequence of how voluminous and "everything but the kitchen sink" design Bluetooth is. BLE is a bit better than the "Classic" Bluetooth in this regard but it is certainly not a "lean" protocol by any measure.

And I don't think that one can fundamentally choose that BLE and Zigbee cannot coexist.

Nobody said they can't. Don't put words in my mouth. I have said the softdevices can't do that because they weren't designed for it and they use the same hardware, so if you try to load them at once they will conflict. That's all. Feel free to implement your own multiprotocol stack. The Bluetooth specs even have a part dedicated to coexistence with other protocols.

In fact, the project I'm currently working on could have some customer demand for combined BLE and Zigbee and despite not high on priority list, I'm keeping my eyes on if it could be implemented with less than 100KB of flash, and single radio. You probably say it's impossible, but I have been doing these "impossible" (to some) things before. In the meantime, we are going with my own "masochistic" protocol which works great and is just a few K, with the obvious limitation of no interoperability but no one has asked for it - yet.

Don't forget that there is a huge difference between a hacked up "lite" implementation of the stack that does only what you need for your application - and a complete, qualified stack that has to handle even things you don't use and didn't implement. But someone else does and does require that certification because they want to put the official Bluetooth logo on their gadget and don't want to get sued by the Bluetooth SIG over it.

However, again, you are very welcome to implement a dual protocol stack in 100kB of flash, I am sure there would be a lot of people even willing to buy it if you did. There isn't anything similar on the market, AFAIK.

[nctnico]

Don't forget that there is a huge difference between a hacked up "lite" implementation of the stack that does only what you need for your application - and a complete, certified stack that has to handle even things you don't use and didn't implement. But someone else does and does require that certification e.g. because they want to put the official Bluetooth logo on their gadget.

Agreed. It makes no sense to try and implement a BLE stack from scratch. The ones you get with the various RF chips are certified and likely have many tweaks & hacks to cover the blank areas in the specification to ensure real world interoperability.

A long time ago I wrote an ISDN protocol stack from scratch because these where not available to mere mortals. I tested it against the test vectors as used for certification. But when I started to deploy the ISDN stack for real, it turned out various (telephony) switches had their own idea of how the protocol would work in certain situation so I ended up with having to support quite a few ISDN flavours as well. Moral of the story: creating a robust and versatile protocol stack for a complex protocol is not easy and not a small job.

[Siwastaja]

Talk is cheap, but answer this simple question:

If there exists two different solutions (nRF52 deprecated softdevice, and Apache NimBLE), both implementing the same specification, one of which is 4 times the size of other, to the point that it just barely fits the device it's intended to run on, why I am not allowed to express my opinion that the larger one is probably bloated, without being questioned whether I could implement yet another version of said protocol? Film critics need to make better movies themselves? If your answer is that one of the stacks has more features (which can't be stripped down for user needs), then congratulations, we agree: that's exactly the definition of bloat.

Also, if ability of implementing this full stack from scratch is prerequisite for discussing it, have you done it? If not, shut the fuck up.

Or, actually, don't bother replying. You are obviously just confrontational for no reason. Ignored from now on.

[nctnico]

From what I've seen quite a few RF chip vendors have (more or less) dropped their own Bluetooth implementation in favour of Nimble nowadays.

[SiliconWizard]

You mean that? https://mynewt.apache.org/

[tszaboo]

However, again, you are very welcome to implement a dual protocol stack in 100kB of flash, I am sure there would be a lot of people even willing to buy it if you did. There isn't anything similar on the market, AFAIK.

Silicon Labs has multiprotocol stack. I'm not trying to convince you all BTW, just different perspective.

[robca]

From what I've seen quite a few RF chip vendors have (more or less) dropped their own Bluetooth implementation in favour of Nimble nowadays.

I have been writing firmware for commercial IoT products based on nRF52 (832 and 840), using the "old" nRF5 SDK (still fully supported). The initial earning curve was relatively painless: good toolchain (based on Segger, free license for Nordic users), great examples with "ready to ship" code, great Nordic support and community. I never disclosed the company I was working for, so I got the same support that Nordic would provide a hobbyist, and that was well above my expectations. Plenty of tutorials to get started on the toolchain and libraries. IF you need to build, e.g. a cycling speed and cadence monitor, you simply take the Nordic sample, change the name to reflect your name, and you can ship that one as is. Want OTA update? add the Secure DFU example, compile the secure bootloader, and you have a BLE S&C sensor with updateable firmware.

I came as an hobbyist from the STM32 world, where the ST HAL code is barely usable, with non-existent sample and ST support. I still love the STM32 for certain things, but the ST libraries are not one of those

Yes, the Softdevice is a proprietary blob, but well implemented, bug free (for all my purposes) and supports additional protocols like ANT+. There are various version, depending on the features needed with different memory footprints (also, different working RAM, depending on the functionality). More importantly, the Nordic libraries fully implement things like a secure wireless firmware update (over any of the supported protocols), with guaranteed recovery in case of problems. Good luck rebuilding all of that on top of a library like NimBLE. I mean, it can be done, but I'd rather spend my time on writing unique code for my scenarios. And even if we implement a half dozen of BLE profiles and are running BLE and ANT+ at the same time, sending data at 100Hz plus managing analog channels and IMU sensor fusion on the M4 (using ST's MotionFX), we never had any memory issue or slow execution.

Lastly, thanks to Segger's MMD (Monitor Mode Debugging), you can fully debug your code while maintaining the BLE (or ANT+) connection alive. MMD works with the Softdevice to allocate enough cycles to the radio code, while giving you full step-by-step control of your code (on a single core processor). Debugging BLE applications is much harder without something like MMD.

A radio stack by itself is rather useless if you need a full solution with multiple radio stacks. Try sending BLE and ANT+ data at the same time, like pretty much all sports enabled devices do these days, and doing it on a device with exceptional battery life like the nRF52.

There are stupid parts to the Nordic SDK (like the sdk_config.h file, which is a hot mess, but something you deal with only once then copy over and over), and things that are questionable choices, but minor quibbles for the most part.

And, no, I don't own Nordic stock just a happy user sharing my experience developing for commercial products.

P.S. ANT+ is Garmin proprietary and only available as binary implementation. Nordic is, as far as I know, the only implementation that works with BLE on the same radio

[Siwastaja]

I guess the design choice of a "complete finished but modifiable megaproject" is either a total hit or a total miss. If you can take an example project and it's close to your final application, and you have no design constraints (i.e., can define your project as you go), then you can pretty much ship the example or modify it a bit. If the example compiles and runs, you can get your IoT thing finished in a week. Especially if your own part is trivially simple (in which case it would fit in the remaining 50K of flash, too).

Things totally change if your project has its own goals - functionality, architecture, even coding style -, or even worse, existing implementation. In other words; your project is complex, and radio is just small part of it. For example, I might already have a working secure firmware update tooling, with all server infrastructure, in place. Then I just want a radio communication layer, nothing more. If I have a 100kLoC project and I want to add radio functionality to it, then I want a radio-only library and clear documentation thereof, where "getting started" guide must look like "call this init function, call this send function, link with these linker settings". In such case, a 200LoC example, minimum viable code which demonstrates BLE only, and not logging in multiple colors, is much more valuable than a 200-file, 100kLoC example which is a complete product.

Massive megaprojects are also problematic when something goes wrong. As I explained, I spent a week trying to get the examples working, and did not succeed, and I can find similar experiences from a simple Google search. Then again, for others, the examples seem to work out of box, so . Maybe it depends on which devboard you got, which SDK version you happened to download, or if you made some stupid mistake or wrong assumption early in the path - I probably did - that some others apparently do not make.

Nordic Semi's support has been excellent, probably the best in class, this I can agree with.

I would prefer to see "unix philosophy" more, that is, self-contained libraries with clear and documented interfaces, which you can use as building blocks. It seems the MCU world is going the opposite way, where you get a complete "ecosystem" or a project which you then modify. Learning how to integrate a library has a bit steeper learning curve than getting out-of-box ready project you just modify, but this learning curve is relatively constant over all types of projects, simple and complex.

[robca]

Especially if your own part is trivially simple (in which case it would fit in the remaining 50K of flash, too).

The nRF52832 has 512kB flash, the nRF52840 1M. The Softdevice is 100kb for the basic BLE peripheral, ~120kB for full BLE (more for bigger versions, but not much). Nordic offers a family of device all code compatible with no changes, so not sure why flash size is such a big deal in this discussion. We use complex algorithms (including third party code like MotionFX) and multiple services, plus local data processing and a variety of peripherals. We have flash to spare even on a nRF52832 with the BLE/ANT+ combined Softdevice. And I have a hard time imagining what kind of application would you have to write to eat all that flash, and still decide to run it on a single core M4. There are plenty of startwatches with complex UI and apps using those chips

I'm not sure how you'd only have 50kB flash to play with, unless you chose the wrong chip for your application. Even the smallest device with 192kB flash and the basic BLE stack would have more than 85kB to play with, but it's easy to move to a chip with more flash. Is NimBLE+RTOS (the Softdevice is both) really that much smaller than 100kB when compiled for a nRF52? I can't find any example or information on that. Do you have an .hex file compiled for a nRF52 to see the size? did you manage to build a sample app using NimBLE and, if so, what was the total size?

The Softdevice doesn't force you into a specific coding style, while I agree that if you cut&paste examples, you would inherit that coding style. But with NimBLE you also have to use their environment for lot of things, unless you port everything to your environment and manage updates.

Our code didn't start from examples, btw, but over time we pulled in bits and pieces from the examples, adapting to our needs. Having a working example that implements exactly what you need and is "ready to ship" saves countless hours of development. Even just by being able to look at how something works on the SDK board and debugging that. And, for what is worth, our firmware is modular: the same core functionality is used for common things (like secure OTA firmware update, battery, configuration services, etc) but it is customized to ship dozens of different devices with different functionality.

I love the "unix" mindset when I'm working with powerful PCs and servers. For embedded devices, every time I find a working implementation from the manufacturer with good examples and good support, I'll gladly take it. Strict HW integration, timing and especially battery life make developing generic libraries that work on multiple incompatible HW very, very hard. We focused on memory, but if for example the NimBLE library used 10% extra battery life in a specific scenario, I'd rather trade off memory for better battery life. The Nordic stacks have all been optimized for incredibly good battery life and work with the rest of the chip to save battery everywhere. And NimBLe only supports Nordic and one Renesas chip, so not exactly generic.

Nordic has a really good track record and their BLE and ANT+ stacks are industry standard by now, probably one of the most common BLE stacks you are likely to encounter in the wild. For an OEM focused on shipping hardware, the bootstrap time is short and the results predictable. iOS and Android phones have also been fully tested against those devices, unlike something like NimBLE. That alone is worth peace of mind for me.

But I agree that it comes down to philosophy and preferences, I'm just sharing my experience with becoming productive in a much shorter time than I thought possible (and I'm not really a good programmer at all)

[Siwastaja]

The nRF52832 has 512kB flash, the nRF52840 1M. The Softdevice is 100kb for the basic BLE peripheral, ~120kB for full BLE (more for bigger versions, but not much).

512KB/2 - 120 = 136KB remaining for the app, which is quite acceptable actually. I was looking at some other softdevice which was around 200K, don't remember which, and don't know why I looked at it instead of the "basic" version, if the basic suffices.

so not sure why flash size is such a big deal in this discussion.

Would you guess why? Some of us do this for a living, and if something does not work and cannot be fixed, then it's a no go. No hard feelings - but it has to be ditched. I'm merely stating the fact it is too big to the constraints I'm working with - you may disagree, with different constraints, but you are the only one who's making it a "big deal".

We use complex algorithms (including third party code like MotionFX) and multiple services, plus local data processing and a variety of peripherals. We have flash to spare even on a nRF52832 with the BLE/ANT+ combined Softdevice. And I have a hard time imagining what kind of application would you have to write to eat all that flash, and still decide to run it on a single core M4.

Nice to hear that your project fits. Ours does not. It uses flash for configuration settings, duplicated copies of which exist for graceful fallback to old settings, it has mbedtls and Paho libraries, and a lot of other stuff, and every piece of application code (except very tiny and simple bootloader) - including TLS and radio stack - is over-the-air upgradeable, so must exist twice in the flash, as brickage cannot be accepted in case of power loss during update. This is why there is ~60K left for radio stack. This is why we don't invest any time in trying to learn how to use Nordic's softdevice - it does not fit. Custom stack fits excellently so we are doing it that way. NimBLE is considered if business case exploration reveals demand for mobile phone interoperability - no one has asked for it yet. On paper, NimBLE fits. Does it really fit - I have no idea. Nordic SoftDevice does not fit even on paper, so would be wasted time to explore.

I'm not sure how you'd only have 50kB flash to play with, unless you chose the wrong chip for your application.

Yeah, good old "let's blame the user for not buying excessive hardware" excuse for bloat. I merely pointed out this obsolete implementation is many times bigger than what some others claim to be, and why I think it is a problem. Your mileage may vary, and I'm glad it doesn't matter in your project.

Even the smallest device with 192kB flash and the basic BLE stack would have more than 85kB to play with,

Nope, 192/2 - 100 = -4KB, does not fit at all. But then again, I choose to not build non-upgradeable mass market devices which we need to then recall when a serious security bug appears instead of just OTA upgrading it. Your mileage may vary, and I'm well aware that in IoT business, safety practices are all over the place.

Is NimBLE+RTOS (the Softdevice is both) really that much smaller than 100kB when compiled for a nRF52?

I don't know. I quoted numbers I found from a presentation. Because NimBLE claims to be tailored for nRF52, I'm assuming these size numbers are also real for nRF52. I have not tried it. I also don't need an RTOS (NimBLE comes with something they call RTOS, and I have no problem with it, as long I don't need to touch it besides the bare minimum). I also have absolutely no idea if NimBLE is any good or not. If someone has more in-depth experience, I'm willing to hear.

[robca]

so must exist twice in the flash, as brickage cannot be accepted in case of power loss during update.

No, that's really not the case. I mean, yes, one could have a monolithic app+communication stack and have to use twice as much flash. But Nordic, which does this as their core business, realized a long time ago that the ideal solution is a secure bootloader (~2k including crypto libraries), a small communication stack (Softdevice ~100k) and the user application. The OTA DFU supports a fully buffered approach where it requires twice the memory, and in case of problems reverts back to the full functionality. But it also supports a memory-efficient model where each of the 3 components is updated and verified independently (or even just one of the 3, usually the user app), and in case of problems stays in bootloader OTA DFU mode, never losing functionality. I mentioned it in a previous post that the Nordic DFU guarantees a no-bricking situation. And it's secure end to end, with full validation before, during and after.

The only time when some memory needs to be doubled, is the Softdevice update, which is a rare occurrence. But in that case it can be done while the user app is not in flash, so it's never a limitation.

As a matter of fact, using the Nordic Softdevice, I can update a much bigger user app than I could with a monolithic app that includes the communication stack, even if the other communication stack were, say, half as big. I could have a 350k user app in a 512k device, with some flash left for storage (which is also handled properly during DFU). And, yes, one could also write the other solution to separate the communication stack and develop a secure bootloader, plus all the mechanism to handle every possible scenario. It's just a lot of work with a lot of pitfalls I'd rather not have to deal with for no other reason that a trivial memory footprint save (at the cost of using a library that could use more power, have unknown bugs, not officially supported with guaranteed responses for commercial development)

I have to say that this conversation is becoming frustrating: you are arguing about non-existing problems with a platform you are not familiar with, while suggesting as a better alternative a library you haven't tested... All along implying that I don't understand the platform I, my colleagues and thousands of companies have been using for 3+ years and that has been shipped in more than a billion devices.

To be clear: I'm not dissing NimBLE or the other approaches. To each their own, and there are cases where owning the communication stack is beneficial. But there's a reason why, for certain low power BLE scenarios, Nordic is a de-facto default choice.

[Siwastaja]

So you are just confirming exactly what I said, with some marketing weasel words poured in, but coming into conclusion that you trust the softdevice update is "rare" enough you can ignore the update concerns of it. I choose to disagree, I am not putting a 180KB binary blob (I looked into both peripheral + central which is why my numbers were higher) which cannot be updated OTA, and reach the same conclusion as Nordic Semi themselves: not use the softdevice.

No matter how much you add, simple logical truth does not change: in flash-based technology, where erase is slow, for each piece of code that needs to be updated, same amount of extra flash is needed to store a copy. This is a well-known truth and you can try to twist around this reality but it starts looking like you were rationalizing flat Earth trying to make it look more plausible than it is. In other words, the only way to break free from this flash size doubling, is to choose that significant part of the code cannot be safely updated. It looks like you are not eager to admit this and try to hide this non-upgradeability behind pretty marketing words. I don't like it. Just admit it can't be upgraded and you trust it's bug-free; it's a valid and often used approach, just one I choose not to do.

The reason I want to be able to update the whole stack is long enough experience that shows that doing otherwise is risky. Risk is awkwardly small; it's a classic small-risk-high-consequence situation, which is why it's hard to see to some, especially management. Simply put, I put no value to marketing bullshit bingo saying "this is their core business, trust them, they realized long time ago this is ideal...", especially when they, for some weird undisclosed reason, discontinued that very practice!

I want to give 10-year guarantee to customers though and that includes future maintainability of the project. I don't like throw-away IoT products. They need to keep working. They need to expand into new radio stack versions, and security fixes need to be applied. And unlike expensive special gear where we could fly to the customer and update it through JTAG, IoT stuff must be OTA updateable, and cost must be minimized. And if we are projecting truly high sales numbers, then NRE costs can be allowed to be higher, including good optimization of flash size.

Sad to hear you find this frustrating. You are free to go. You are the one who is questioning my points and getting agitated. Problems I mention are definitely not non-existing, even if they do not affect your design because you have chosen different design constraints and goals. For me, both difficulty in getting started with the SDK, and large size of softdevices were real showstoppers; take this with a grain of salt and feel free to express your disagreement. Your experience can be different but does not negate mine; there is no singular truth in complex engineering matters. We can choose to disagree and that's fine to me, even if it's not fine to you.

[robca]

So you are just confirming exactly what I said, with some marketing weasel words poured in, but coming into conclusion that you trust the softdevice update is "rare" enough you can ignore the update concerns of it. I choose to disagree, I am not putting a 180KB binary blob (I looked into both peripheral + central which is why my numbers were higher) which cannot be updated OTA, and reach the same conclusion as Nordic Semi themselves: not use the softdevice.

You are wrong. As I said, each of the 3 components can be updated independently or all at once (in any combination). In all cases, the OTA DFU ensures you can recover from a problem and never brick the device. And never require twice the flash of the full firmware. The Softdevice can be easily updated OTA, we have done a few times (but it's so stable now that it's rarely required, that was my point).

Considering that you keep being wrong on the supposed problems of the Nordic solution, the rest of your arguments are rather pointless.

[nali]

You are wrong. As I said, each of the 3 components can be updated independently or all at once (in any combination). In all cases, the OTA DFU ensures you can recover from a problem and never brick the device. And never require twice the flash of the full firmware. The Softdevice can be easily updated OTA, we have done a few times (but it's so stable now that it's rarely required, that was my point).

That's not quite true, this shows valid combinations of updates


The DFU is only validated if there is enough room in flash to buffer the update before writing to flash which Nordic call Dual Bank update, so that's basically the same as Siwastaja is saying. If there isn't room then it will do a single bank DFU, if that fails the device remains in DFU mode until it receives a successful update.

[Siwastaja]

That table is clear as day. You update the softdevice with the same major version of the same softdevice, since the softdevice isn't double buffered and has to modify itself. It's unknown how much complexity this update feature adds to the softdevice itself, but probably some. Many prefer simple solutions with minimized risk and no vendor lock in, and this is polar opposite to it. Which is probably why people didn't like it and it got discontinued.

(See also https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.2.0%2Flib_bootloader_dfu_banks.html )

And that "DFU mode" "receiving" a "secure" update must mean it has safe and secure BLE implementation and crypto (i.e., the softdevice), you can't erase that. No amount of data shuffling fixes it; if you try to swap the softdevice as a separate step, then you need enough buffer space to store a copy of it, and this space cannot be used for app. No matter how you shuffle data and numbers around, it always end up with the same result: if you want to update everything, you will need double the space. Creative use of compression and self-expanding code could actually mitigate, but it's unclear by how much, and by what cost.

This is as simple as verifying claims of overunity. No amount of mental acrobatics change the simple physics, or in this case, elementary school math and logic. It is easy to make outragerous claims if you don't exactly know what you are talking about and define things loosely, in marketing speak, this is exactly what we are evidencing here when this marketing shill popped out of nowhere to pick a totally unnecessary fight.

His confusion probably stems from the fact that all that complexity is hidden from him so he doesn't know what's actually happening under the hood; he, just like janoc, assumes there is black magic going on. In reality, there is no magic, just science and engineering, and the "single bank" update mode has risk of application loss, but in a typical battery-powered design with a fixed, non-user-replaceable li-ion cell and no physical power switch, risk of power outage during update is small, so one can "play around" as if the problem I described didn't exist. And then the constraints change, devices are manufactured in tens of thousands and they are not battery but mains powered, and you want to change to a different radio stack. What now?

Personally, I have used non-dual-banked flash updates in many projects, and always use RAM as the buffer and verify CRC before erase-write cycle. But it still has a section of death which lasts for a few seconds. This is then an accepted and documented tradeoff.

This is all basics to embedded engineers who can write code and build their own tooling, but probably black magic to those who modify examples. I'm not claiming either is superior way of working, just different. It is just that experience shows that the more you trust in the complex and unique software solutions offered by chip manufacturers, the more risk there is; and if you believe it's magic, the risk shoots through roof. There probably is reason why 99% of the Kickstarter IoT startups fail to deliver. Prototyping is quick, even using an Arduino; reliable product which can be manufactured and maintained totally different.

[Siwastaja]

This is how softdevice update actually happens:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.2.0%2Flib_bootloader_dfu_banks.html

tldr: old application is erased, also old softdevice is erased, all you have left is the new softdevice + the new DFU. It has to work, there is no fallback.

Even if you trust it's free of bugs and nothing can go wrong, the point is totally moot if your update path is not BLE + customer having a bluetooth device with update app installed. For example, I do secure firmware update through MQTT/TLS/TCP/Ethernet in a product, so erasing the app and using Nordic's BLE DFU is out of question, it won't do it. We have these IoT devices which need to upgrade on their own, customer might be 1000 kilometers from home.

There is no replacement for understanding what's happening under the hood. Robca, if you are still young, drop the arrogance and continue learning - and don't forget to question yourself. Arrogance is sure way to destruction. I know that because I have had those moments too.

[nctnico]

To me this looks like a consequence of having too little flash to work with for the software provided by Nordic. So either roll your own software or use a device with more flash (if available). Assuming the 'Nordic software' supports using mirrored data where you have (at least) one working image while writing the update. A different example: Espressif's S32-S3 together several MB of flash has the ability to store 3 firmware images and one never gets erased as this is the 'factory' image. So even if you have 2 messed up OTA images (for whatever reason), the device still has a working firmware. I agree that microcontroller manufacturer provided software typically isn't the best but after having spend a while with Espresssif's IDF I must say I'm quite satisfied with what is there out of the box (including encrypted firmware images). The most interesting part is that Espressif doesn't really impose a particular update method / protocol. The actual transfer of the image is left to the implementer so you can transfer the file any way (serial, BLE, Wifi, network, etc, etc) you want for as long as it ends up in the right flash section. In other words, if ultra low power isn't an issue but being able to do OTA is important, then the Espressif S32-S3 series is definitely worth a look.

[robca]

Without refuting every single misleading statement, let me at least correct the biggest misconceptions:

You can update the softdevice to any version (even different major versions) as long as you also have the right bootloader for that new softdevice. If you want to update only the softdevice (i.e. no bootloader update), it can only be the same major version (table provided by @nali says as much, but it can be red wrong and mistakenly assume only same major version can be installed). The toolchain manages everything for you, and you do not need to do anything manually.

If you don't have enough flash to update everything at once, but still want to update everything, the DFU deletes the old app, uploads a new copy of the softdevice (and bootloader, if needed), verifies that everything is working, then deletes the old softdevice. There's no condition where you are left with a non-working configuration and no way to recover. Then , once bootloader+softdevice is validated, the app is loaded (new or old). It's the most efficient use of flash possible while still having a safe fallback.

The whole process is secured by crypto-signed binaries (can choose the crypto libraries)

The Nordic ship only supports BLE, ANT+ and a few other protocols. No Wifi, no ethernet. Every protocol and transport supported can be used for DFU updates, including ANT+. Of course you can't update over a non-existent interface... We are not discussing a general approach for every conceivable platform, just what the OP asked for: BLE SOCs.

1MB is more then enough flash for everything that can conceivably run on a M4 at 64MHz and Nordic has provided tools to address any common developer and user scenario. Everything discussed here works just fine, misconceptions aside. Not saying it's a perfect device, and clearly there are devices with more flash (even external flash). But none works from a CR3032 for a long time, as far as I know. If I needed WiFi or more processing power, the ESP32 would be a strong contender.

Everything is a compromise. If you are designing a BLE or ANT+ device, though, you'd be hard pressed to find a better platform today than the Nordic one. I have no connections to Nordic, just a happy user, and sharing my experience on the OP question.

[Siwastaja]

robca, all that is based on assumption that customer is running the update through BLE using their mobile phone and installing an updater app. This is not possible in many IoT products! IoT products, by definition, are connected to the Internet, and BLE is not Internet.

In fact I did not even think about it since none of the few projects I have using these parts for could do that. If I had thought about it, I would have understood your point better from the start.

The most interesting part is that Espressif doesn't really impose a particular update method / protocol. The actual transfer of the image is left to the implementer so you can transfer the file any way (serial, BLE, Wifi, network, etc, etc)

I think this is pretty usual. Almost always you want to come up with your own update infrastructure and cannot just use manufacturer's preferred interface. Having modular design with clear interfaces would allow you to use some of the manufacturer supplied software components for any communication layer. As manufacturer solutions often do not allow that, it leads to writing everything from scratch, which I'm fine with, except that some complex enough stuff like TLS, BLE stack or filesystems I don't want to write; therefore I want them as easy-to-use libraries.

And now I can correct what I said earlier by adding a conditional: the size of softdevice doubles in flash if the update path is not Nordic's BLE updater app, which for many purposes, including all those use cases of mine, is always the case, but I kinda understand how robca was not met with this limitation as he modified the examples and could update through BLE.

Everything is a compromise.

Oh, you are starting to get it! Nice to hear that.

[robca]

robca, all that is based on assumption that customer is running the update through BLE using their mobile phone and installing an updater app. This is not possible in many IoT products! IoT products, by definition, are connected to the Internet, and BLE is not Internet.

In fact I did not even think about it since none of the few projects I have using these parts for could do that. If I had thought about it, I would have understood your point better from the start.

Look, I kept answering the original question in this thread: BLE SOC. By definition, you update a BLE device via BLE. There's no reason to have a BLE device if you don't also have a smartphone or other BLE control point  . Nordic provides a standalone DFU app, or the manufacturer can incorporate Nordic code in their smartphone app to provide seamless DFU. That's how BLE devices work and it's an optimal end user experience (custom app with automatic updates). Nordic provides the same if you only ship an ANT+ device, commonly used in sports. The end user doesn't need more than that for these devices.

Along the way, someone complained that the Nordic solution didn't work by providing incorrect information due to being unfamiliar with the platform. Having used that platform extensively, I provided the correct technical information and how the platform addresses all the concerns raised (for those specific scenarios, not in general). The softdevice is extremely mature and, for all its downsides, nicely solves every conceivable scenario raised. Other options like NimBLE simply are not as mature to provide an end to end solution that covers as much. The developer using that must write a lot of code and solve a lot of problems that are already working in the softdevice/sdk.

I never disagreed that there are better ways for generic IoT devices to manage updates and the software stack, or the superiority of open vs closed implementations. But that has nothing to do with the topic here, and I'm not interested in that part. If a developer wants to develop a pure BLE or ANT+ device, they'd be hard pressed to find a better solution than the one Nordic offers and supports. There are better devices and frameworks for other scenarios. I really don't think there is much to argue with this position, but I'd be interested in some else's experience with BLE SOCs offering as much (just BLE, our customer base needs/wants nothing else).

[Siwastaja]

Look, I kept answering the original question in this thread: BLE SOC. By definition, you update a BLE device via BLE. There's no reason to have a BLE device if you don't also have a smartphone or other BLE control point  .

What!? No, of course not! You can't just arbitrarily come up with such limitations for others; for your own product, sure! Of course others can have a real need for BLE communication without BLE DFU path.

I already explained a use case, which is not synthetic at all, but what I'm actually currently working with: the devices are updated through ethernet port, automagically, without user intervention, because user might be on the other side of the planet. Users pay us a monthly fee exactly so that the things keeps running trouble free; we can't ask users to install updates. BLE would be used for example to communicate with external temperature, humidity etc. sensors, but also for user interaction when the user happens to be present, e.g. during initial configuration or looking at real time data, but that doesn't necessarily coincide with the need of update. Now if you stop to think about this use case, you also realize why I would need both BLE central and peripheral. Now combine all this information, and 2*180K for the softdevice becomes reality. Talk is cheap; show me a real way around it without changing the constraints I just explained. To me, NimBLE looks the best way forward - if it's any good and up to promises, that is.

And before you go, "oh, that's a very special case", I say no it isn't. What does the I in IoT stand for? I would assume the Internet is the primary DFU path in nearly all IoT devices. Of course, not every BLE device is IoT though.

Your posts demonstrate the problems of "full package" manufacturer solutions: they are completely inflexible, but they are also so complex that it is not instantly obvious what you can and cannot do. The deeper you dive, the more limitations, which cannot be circumvented, you find. If you promised an internet-connected device only to later find you can't update it through the internet, but only interactively by the user, it's going to take a full year of re-design, re-certification etc. to get the fixed device on market. The cost is easily a million in wages, lost revenue, etc. In my opinion, having looked at some startups, too much trust in "easy" manufacturer solutions and too little competent workforce of your own is one of the key reasons why so many of them fail to finally deliver (even with promising early prototypes), but I could be wrong and maybe these technological problems are always solvable. Then again, I do also see some that are very successful with the approach you describe. It completely depends on requirements.

I'm merely suggesting, be informed before you make the decision; assumptions in engineering are root of all evil. And being informed consists of reading and understanding both my and robca's viewpoints - those parts that have some actual content of their own, the part where he makes strawmen out of my arguments is unnecessary noise.

Now at this point I'm done with this troll and this discussion. I merely offered my professional opinions which I think I explained properly, but got in two unnecessary fights with two fanboys*, which hijacked the thread. Hope it was still helpful to others.

*) fanboyism is cancerous in engineering