That's an odd way of spelling "maintaining a stable market share in the face of Chinese competition".
Going forward, IoT security is going to be an increasingly important factor for new designs. The EU is quite serious about combating security problems with IoT devices. And security is something that the new products coming out of Nordic is very serious about.
I don't think many big, serious device manufacturers are willing to risk being the target of the first catastrophic IoT attack just to save some pennies on a dirt cheap Chinese design, with some poorly verified RISC-V core thrown in with a power hungry Bluetooth radio.
ARM TrustZone is not something the RISC-V ecosystem has a clear standardized answer to yet. So I think that's a reason why ARM will keep its role as the main application processor in high-end BT/Thread chips for the next several years.
From AliExpress, it'd probably be $2-$3 including shipping.
They don't ask questions when ordering large volumes of microcontrollers either.
If someone wants to get a hot air station and a bunch of $1 chips and reprogram their own devices, it would cost them less than a hundred dollars, 150 tops.
Anyone can learn any skill. If you can draw anything recognizable, you can do electronics.
They are popular only because they are so cheap. Also, so far as chip shortage, China kept pumping them out.
Ikea, for example, ships tons of "smart lightbulbs" with silabs/EFR32.
I don't think security is a real problem for me. Smart devices on their own intranet takes away a lot of problems.
All Nordic chips are susceptible to bootloader attacks which make them a poor choice for storing key material. This can be mitigated in the design phase by adding an external security chip like a ATECC608B but if you were to tear down a device and see a board present without this module it certainly will have other vulnerabilities too.
Having worked extensively with both Nordic and Chinese chips, what makes Nordic win is the ease of development - they are by far the best in market when it comes to programmability. Hands down.
The security problems have been known since the NRF51 and despite that those vulnerabilities were carried over into the NRF52 because the cost of validation of chip designs is so prohibitive they did not want to touch it and filed the “oh some random person can extract the entire contents of the chip” bug as “won’t fix”. They are baked into a silicon ip core and can’t be fixed with a software update.
As for RISC-V, there are some amazingly innovative and brilliant alternatives to TrustZone presented at the conference but I suspect Rambus may block innovation here using their position on the board (and chairing the security standing committee) in favor of their own (patented) solutions using an embrace, extend, extinguish strategy.
This seems to be the norm for Chinese chips in general.
Poor documentation, even in the native Chinese, no official dev boards, sometimes no JTAG debuggers, random bugs, just a whole lot of bullshit to deal with as a foreign developer.
I suspect it might be a cultural thing; developers are less prone to pouring over data sheets and more prone to asking their friends/colleagues to introduce them to someone who works at one of the microcontroller companies. (This is just a hunch, and I could be completely wrong.)
That aside, Nordic still seems the best choice out there though quite a lot of features are leveraging the ARM ecosystem. RISC-V involvement is possibly toe in the water stuff/de-risking from ARM ("who owns them today?"). The recent big switch in SDK's (nrfSDK to Zephyr) wasn't teribly welcome, so the possiblility of another one is not welcome (if there was an approximately equal competitor with more stability we'd jump ship).
RISC-V members have to sign an agreement when they join, which has clauses to prevent this sort of situation.
On Raspberry Pi for example, you can write the hash of your own public key to locations 47-54 of the OTP memory block:
https://www.raspberrypi.com/documentation/computers/raspberr...
Here's the QuickStart for the entire process: https://github.com/raspberrypi/usbboot/blob/master/secure-bo...
Note that the Raspberry Pi does not have a full TrustZone implementation to protect secure mode memory, etc. But it is a widely available device with good documentation and allows developers to experiment with and learn about the basics of TrustZone architecture.
If you start building your own hardware and/or buy devices with unlocked bootloaders, you can load whatever you want in EL3 to play with TZ. This isn't a problem with TZ.
You must be kidding, right? It's not that they would have cared much in the past. Now, I would be the first to celebrate a change in that regard, but it's just not the world we live in now.
The small budget OEMs will save some pennies on a dirt cheap Chinese design. The big, serious device manufacturers will do the design themselves by starting with an open reference design and making some minor modifications that suit them, then pay someone to fab it because they're shipping millions of units. Who does that even leave?
> ARM TrustZone is not something the RISC-V ecosystem has a clear standardized answer to yet.
This has almost nothing to do with IoT security, if not being directly opposed to it as a thing used to prevent people from installing custom firmware on devices the OEM fails to support.
The #1 problem in IoT security is OEMs that release a device which they neither patch nor allow anyone else to patch. And the first can't be a solution for small OEMs because they go out of business, so the only way to actually fix it is to have devices that users can update with third party firmware. For which the lack of ARM TrustZone is an advantage, since it's often used to prevent this.
With that being said, I've worked with both the Nordic NRF SDK and the Espressif SDK and greatly preferred Espressif.
For doo-dads that I make for my home, esp32 and esp8266 are fantastic. The modules are inexpensive and the community is huge. I would not want to be in Nordic's shoes right now.
We matter a little and can be somewhat of an indicator sometimes. Right up until we don't. A lot of times what matters to us just doesn't apply at scale.
Only, in the tech industry that's almost always a bad sign, the competitors are winning new designs that haven't yet really started to ramp, while the existing vendor is coasting on the current device using their parts. Then what happens is they get stuck in a declining revenue/volume situation while the newer cheaper better competitor slowly eats the market, and at that point investing in a "dying" product just about never happens.
The other thing which really bit me was someone here used a symbol name which collided with one used in the SDK, but the build system allowed this to link without error.
nRF Connect is a different world, comes with a lot more options, some really rooted in Zephyr OS, some lessons learned from the prior SDK. And if you're familiar with Linux build configuration system, that is basically what Zephyr brings to the table (comes from Linux foundation). But yeah all that flexibility comes as a penalty when you want simple stuff, compared to ESP32-Sx
Yes, I ended up editing the .emProject files by hand. It worked, but it felt like I was doing something wrong. I assume that you are referring to the soft device blob? Has that been abandoned in nRF Connect?
Quite, yes. They took the ZephyrOS approach, but it comes with a learning curve penalty, unless you go the easy route of nRF Connect GUI. In that case you do have some limitations of how you organize the code base (so that the GUI works), but even that is miles ahead in configuration compared with to the nRF5 SDK + Segger Studio.
Some skim reading material about it: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/...
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/...
On the other hand, checking in the whole SDK as part of a project gives an impressive LoC tally ;)
Link issue was possibly macro craziness? The scars of sdk_config.h etc.
<file file_name="../../../../../../components/libraries/log/src/nrf_log_backend_rtt.c" />
The link issue was, I think, the result of what Nordic does with weak symbols. I don't recall the symbol name, but it was something which caused very unusual results.
Regarding LoC tallies, I often try to minimize mine. :-)
Oh lordy. Bluetooth is about to get even worse? AFAIK, Nordic's harwdare and software are among the few high quality Bluetooth stacks.
Maybe something the Western competitors should learn from.
It's not surprising that they have taken off like they have. Initially it was because it was inexpensive, but now the community is huge and that is a very attractive selling point.
You've also got the nRF52 USB dongle which seems similar to those cheaper ESP32 kits, for around $10.
> and going past that requires a JTAG programmer
No, the official Nordic devkits comes with a built-in debugger. Same for micro:bit. It's just plain USB.
That said, I do think Nordic could be better at penetrating the hobbyist/student market. I think one problem is the lack of a combined BT/WiFi chip.
I think once Zephyr becomes more mature and there's more tutorials/guides around it, a good BT+Thread+WiFi solution from Nordic could become very popular. Zephyr is a bit hard to get into, but incredibly powerful once you get used to it.
Right, the devkits can do this. If you want to go past that, like making your own PCB with a NRF52 on it you need JTAG, which is not a requirement for esp32.
Maybe the NRF52 has some sort of ROM serial loader that I've missed though.
[1] https://www.seeedstudio.com/Seeed-XIAO-BLE-nRF52840-p-5201.h...
Out of curiosity, how do you flash the nrf52832 board?
[1] https://www.tag-connect.com/product/tc2030-ctx-nl-6-pin-no-l...
Segger has been really successful at marketing "JTAG == JLink" but it is just not true.
And that was just the mechanical parts...
The small local hardware store near me is great for common things like M3+ screws, but understandably doesn't stock slightly exotic items like M1.6 threaded inserts. There's larger e-shops that sell those, though I can't speak to the markup. Larger parts are generally easier to find.
Back in the day our university was flooded with Atmel AVR kits.
I don't know about my university now, but many high schools now use BBC micro:bit kits, which uses Nordic Semi SoCs.
https://www.ceva-dsp.com/product/rivierawaves-bluetooth-plat...
At the end of the day, 2.4 GHz frontends can be done in the same silicon process that makes your SoC and the antenna needs to be nothing more than a PCB trace, so what on earth was going to save Nordic from competition?
Most of their chips fall into this or a related niche: good-enough computating and IO capabilities with RF for battery-powered devices. If I were to build something like this, they'd be my top choice.
I wish they would move away from the third-party suppliers for making their integrated modules. So you could buy a 'nRF-53 module with antenna' instead of browsing third party websites.
Speaking of competing with China: A Wi-Fi-capable Nordic chip is a glaring omission in their lineup. Give Espressif some competition!
Not in my experience. Reputable chipmakers are as important as they ever have been. "Westernized" supply chains are a selling point to investors.
Regardless, Nordic leads the space because their firmware libraries are best-in-class, and their documentation and support are least-terrible-in-class. The hardware has never been the most sophisticated (or the cheapest) in the segment. ex: until the nRF5340 came out, SiLabs blew them out of the water architecturally, but SiLabs' development tools are a tire fire so it doesn't matter.