Nordic nRF5x BLE - anyone been throught it?

[jnz]

I'm considering starting a project on the Nordic Bluetooth Low Energy line, the nRF52 probably.

It's an ARM m4 with a "soft device" (BLE stack) that runs on the same processor in restricted space. It's kind of a cool system that allows them to update the BLE stack without needing to re-certify the product because the software carries it's own cert. Compared to other options like some of the TI that run dual ARM processors on the same chip it has pros and cons, but so long as you don't mind the BLE stack interrupting your code at unknown times I think its a pretty good idea.

Does anyone have experience with these? I'm considering running a module and if the prototype is successful turning it into a real product that will get it's own FCC cert.

Things I'm not sure about are transfering large(ish) amounts of data over BLE, updating OTA, secure bootloader/DFU, how good Nordic's software is, if the BLE event handling will become difficult while running along side my application in an RTOS, etc?

Anyone with some experience on this?

[westfw]

It's about to become an "Arduino Primo"
http://www.arduino.org/blog/1-the-new-blog/arduino-targets-iot-developers-at-maker-faire-bay-area-2016
And the nRF51822 (CM0 based) is in the Intel Curie module used by Arduino 101, and (I think) the "Simblee" modules as well.
So there's no shortage of "evaluation platforms."

I haven't done much with the boards I have other than notice that "Bluetooth LE" is a lot more different from ordinary Bluetooth than I expected it would be.  Much more transaction/"remote value" based and less "stream"-like.  For instance, in order to achieve a com-port-equivalent, you need to invoke proprietary protocols (both ends provided by Nordic, so maybe that's OK.)

[linux-works]

the curie does not have the exact same nrf stuff as nordic.  can't say more than that, though, sorry.

[linux-works]

and, bill is right, ble is nothing like bt classic.  I don't really love ble, to be honest.  seems a huge step backward and ignores a lot of tried/true comms concepts, as if it was designed by younger players who were not around during the previous generations of data-comm devices.

serial streams are not easy and not supported out of the box.  bulk data is clumsy.  packets are small.

ble also has some security issues (I've read about it; no direct experience).  OTA for ble is also problematic.

it needs more time to bake.  rushed to market, like so many other things.

[Dielectric]

BLE was never meant for bulk data transfer.  It's meant to transfer a few bytes with as little overhead as possible, so you can sleep the radio 99% of the time.  There is a reason they didn't/don't have a serial stream profile, and most of the time when I see people trying that, there's a better way if you work with the GATT layer a little smarter.  Let the protocol handle parsing instead of putting together some crazy packet and sending it over serially.

That said, you can get some pretty decent throughput, hundreds of kbits/s, if you drop to the lower levels of the protocol and use L2CAP.  It's even faster with 4.2 parts because they upped the max packet size.

Security got a big bump in BLE 4.2, it was pretty rudimentary in 4.1.

[jnz]

BLE was never meant for bulk data transfer.  It's meant to transfer a few bytes with as little overhead as possible, so you can sleep the radio 99% of the time.  There is a reason they didn't/don't have a serial stream profile, and most of the time when I see people trying that, there's a better way if you work with the GATT layer a little smarter.  Let the protocol handle parsing instead of putting together some crazy packet and sending it over serially.

That said, you can get some pretty decent throughput, hundreds of kbits/s, if you drop to the lower levels of the protocol and use L2CAP.  It's even faster with 4.2 parts because they upped the max packet size.

Security got a big bump in BLE 4.2, it was pretty rudimentary in 4.1.

All true with one exception. Device to device can use the 4.2 stuff. Using a tablet/phone esp anything Apple those new features won't be there (yet?).

But you are spot on that BLE is excellent at what it's designed for - low throughput, easy setup, fast connection. The BLE handshake is so much smoother and faster in real apps than anything Bluetooth Classic I've ever used.

[jnz]

It's about to become an "Arduino Primo"
http://www.arduino.org/blog/1-the-new-blog/arduino-targets-iot-developers-at-maker-faire-bay-area-2016

I haven't done much with the boards I have other than notice that "Bluetooth LE" is a lot more different from ordinary Bluetooth...

Yea, BLE and Classic are wholly incompatible except for the name and the physical radio. I like BLE for what it's for though. Esp if you want to connect an Apple device, BLE is the easiest option.

On the Primo... Yea I saw that today, that's a pretty good get, but it's object oriented Arduino so it doesn't exactly 1:1 apply to me with C, Keil, and RTOS. It's a good point about support though.

He other thing that's REALLY bugging me... That Arduino Primo presser that appears to be put out by Nordic... Says that board has "Wifi".... No, I don't think it does, and they should know that. Maybe it does have wifi, but I sure as hell don't see how, at all.

[jnz]

On the topic of the streaming / SPP / data xfer... Yea, sometimes you do need to do this like for firmware updates and it is kind of a pain.

You can use 2 GATT "buffers" (characteristics) to load the transfer data and keep cycling in new packets but 20 bytes per packet it sure is annoying.

I wish there were some published or even talked about methods for doing this - but it seems everyone is just happy to duplicate work over and over.

[laneboysrc]

One thing to watch out for with the nRF51822 is that the peripherals seem to be less capable, and less in numbers, compared to ARM MCUs from STM or NXP.
For example the UART does not do 9 bit mode, there are only 3 timers (one 32bit, two 16bit), and some peripherals share resources so only one can be used at a time.

I have not used the chip for Bluetooth, only for the proprietary Enhanced Shockburst, so I can't comment on that part.

The library comes in two flavors: a low-level part that basically only hides direct register access, and "drivers" (uses the low-level lib internally) which provide a higher level abstractions.

cheers, Werner

[jnz]

One thing to watch out for with the nRF51822 is that the peripherals seem to be less capable, and less in numbers, compared to ARM MCUs from STM or NXP.
For example the UART does not do 9 bit mode, there are only 3 timers (one 32bit, two 16bit), and some peripherals share resources so only one can be used at a time.

I have not used the chip for Bluetooth, only for the proprietary Enhanced Shockburst, so I can't comment on that part.

The library comes in two flavors: a low-level part that basically only hides direct register access, and "drivers" (uses the low-level lib internally) which provide a higher level abstractions.

cheers, Werner

That's an excellent point and something I hadn't considered. For my example, I haven't checked to see if nRF52 support LIN on the USART, I had just assumed it would. I'll go review that right now. I'm focused on the nRF52 (cortex m4) as I see no reason to not start with the new part, but it's still a great point!

That library method compared to STM's current disaster sounds lovely.

How was Shockburst?


edit: Yep. The nRF52 does have some resource sharing on the perihperals, but it mostly all makes logical sense. For example, SPI0-Master is shared with SPI0-Slave and "two wire interface", so that's all fine. UART is shared with UART-DMA again makes sense. Everything they seem to advertise seems to be there for concurrent use.

[stmdude]

I've worked _extensively_ with nRF51x22 based products, and I just this week completed my "research" into how the nRF52832 compares.

Things I'm not sure about are transfering large(ish) amounts of data over BLE

Like other people have mentioned, this is not what BLE was designed to do. You _can_ do it, but the energy/bit ratio makes it less efficient than regular BT once you pass about 1.5Kbps.

updating OTA

Nordic has a DFU-over-BLE implementation in their SDK and softdevice. It's.... Adequate...

secure bootloader/DFU

There's no such thing as security in a Nordic chip. There are various attempts at security, but since the read-out protection is cracked since a while back, it's all security theater.

how good Nordic's software is

The SDK is actually pretty okay. The examples are a convoluted mess though.
For example: You can take the RSC (Running Speed and Cadence) example, and trim it down from 3000+ lines of code to about 200-300 lines, and retain full functionality.

If you don't like the library, the peripherals aren't very complicated, and the documentation is pretty good, so banging the bits yourself isn't very hard.

if the BLE event handling will become difficult while running along side my application in an RTOS, etc?

Nordic _just_ introduced RTOS support in their SDK. It works remarkably well for their first attempt, but the integration between the softdevice and the RTOS (FreeRTOS in their case) is a bit awkward at times.
They'll get around to it though, I'm sure.

In its current implementation, there's a _slight_ power penalty for running FreeRTOS though. Their port is using the SysTick interrupt at a fixed rate, so there's no way to do dynamic ticks.

As for Nordics support, go visit their forums. I've never posted a question there myself, but my googling points me there quite often, and the Nordic people on it seems to answer all questions with remarkable technical know-how (as opposed to many other manufacturer forums)

Right now, we won't be switching over to nRF52832 from nRF51822. Mainly, because the 52 isn't available in WLCSP (yet), but there are other issues as well.
The entire chip seems to be 16MHz, except the CPU (64MHz). This means that things most certainly won't be going 4x as fast. In fact, you'll have plenty of wait-states for excecuting code from flash.
Also, the cache in the Cortex-M4F seems to be configured to cover the _entire_ address space. This means that if you want to write to a hardware register, and be _certain_ that the write went through to the peripheral before continuing, you need to read back the register..
Also, the wake-from-sleep latency seems (haven't measured though) a bit longer than the 51s. This is a major issue for us, as we're severely power-constrained.

[jnz]

[lots of excellent info]

- I agree and understand on large data transfer, but, sometimes you have to do it and that's all there is to it. The alternative is Bluetooth Classic with many regulations and thousands of dollars poured into Apple's mFI program.

- Follow up on the read out crack? Do you think this applies to the nRF52? If I'm using the nRF52 as my application processor this is a bit of a concern. Was it a side channel or silicon error?

- On the RTOS, I saw that they're just getting to that now. Not terribly comforting that it's so new, but like you said they seem to be decent at support and follow up. Their infocenter and datasheets are actually some of the more helpful I've come across.

- The peripherals all being clocked at 16Mhz isn't that unique for ARM processors right? I mean, it's a little low, but aren't most like 1/4th clock or so? (EDIT: I see on the STM32 it's about 1/2 clock) I get the issue, but I don't think this is a terribly big concern for me as the alternative for my application is a Cortex M0 where I'd be doing software AES. I did see they had one or two examples of reading a register faster writing, a good point but I can only think of maybe two or three places that would apply to me.

With WLCSP and power considerations you and I couldn't be futher from the same product I have no power or size issues, so large transfer and the nRF52 works great in theory.

All in all excellent info, thanks.

[stmdude]

- I agree and understand on large data transfer, but, sometimes you have to do it and that's all there is to it. The alternative is Bluetooth Classic with many regulations and thousands of dollars poured into Apple's mFI program.

True. If Apple is involved, BLE is the way to go..

- Follow up on the read out crack? Do you think this applies to the nRF52?

It was a creative way of manipulating the reset-vector using SWD. Since JTAG is on when the chip is reset (you can turn it off through SW, but by then, it's too late)
http://blog.includesecurity.com/2015/11/NordicSemi-ARM-SoC-Firmware-dumping-technique.html

They might have fixed it in the nRF52, since they swapped out the CPU core _and_ the MPU.

- The peripherals all being clocked at 16Mhz isn't that unique for ARM processors right? I mean, it's a little low, but aren't most like 1/4th clock or so? (EDIT: I see on the STM32 it's about 1/2 clock)

True. I was comparing to the nRF51x22, where _everything_ is running off the same 16MHz clock. Super simple.

I get the issue, but I don't think this is a terribly big concern for me as the alternative for my application is a Cortex M0 where I'd be doing software AES.

The nRF51x22 and nRF52832 both have hardware AES blocks. Just so you're not discounting the 51 because of that.

I have no power or size issues, so large transfer and the nRF52 works great in theory.

Aw, that's almost too bad. The nRFs are bad-ass at low-power stuff. Feels good to have an established BLE connections going, and seeing the DMM indicate an average of <=5uA current draw..

All in all excellent info, thanks.

I aim to please.

[jnz]

Makes sense on the SWD glitch. I'll follow up with Nordic about it though, because while I'm planning on the firmware being insecure, I don't have to try to make it easy for a hacker.

I was discounting the 51 mainly because the 52 is .30-.60 more expensive and is a much faster chip. Plus the BLE4.2 softdevice, plus my application does have some occasional lifting to do so the 48Mhz is ideal. As well as the 512Kb ROM with ~112 taken up by the softdevice, that leaves me enough room for dual bank firmware updates. So, the stars were aligning. There is a chance if I was a better coder I could get by on the 51, but I'm a one man team here, so I'm going to use all the extras I can buy.

Too bad yourself I enjoy having an endless supply of electrons! Yea basically, I have way more money than time on this project and I'm already pushing some of the requirements. Making this all work in a true low energy scenario isn't another challenge I need right now. I have a physical transceiver that's going to pull 70mA while it's running, so I'm not terribly concerned about the processor usage right then

Thanks friend, have a great day.

[westfw]

the cache in the Cortex-M4F seems to be configured to cover the _entire_ address space.

I didn't think that the M4 architecture included cache?

[jnz]

For the record:

Nordic writes:

Note that the behavior is changed in the nRF52 where the access port is either disabled (0xFF) or enabled (0x00): Access port protection can only be disabled by issuing an ERASEALL command via CTRL-AP. This command will erase the Flash, UICR, and RAM.

So they don't allow that (stupid) mode of allowing "some" mcu register access via SWD at all. SWD is either fully allowed for development or not at all for production.

[stmdude]

Nordic writes:

Note that the behavior is changed in the nRF52 where the access port is either disabled (0xFF) or enabled (0x00): Access port protection can only be disabled by issuing an ERASEALL command via CTRL-AP. This command will erase the Flash, UICR, and RAM.

So they don't allow that (stupid) mode of allowing "some" mcu register access via SWD at all. SWD is either fully allowed for development or not at all for production.

Cool beans. Thanks for coming back with the information!

[jnz]

Nordic writes:

Note that the behavior is changed in the nRF52 where the access port is either disabled (0xFF) or enabled (0x00): Access port protection can only be disabled by issuing an ERASEALL command via CTRL-AP. This command will erase the Flash, UICR, and RAM.

So they don't allow that (stupid) mode of allowing "some" mcu register access via SWD at all. SWD is either fully allowed for development or not at all for production.

Cool beans. Thanks for coming back with the information!

No issue at all! I was a little worried after your post that I'd have to walk away from the nRF52 because of at least attempting to keep code secure, but it seems like I'll be alright assuming I can get the actual application up and running.

Their RTOS stuff seems a little weak. They really want to push their scheduler instead of an RTOS but I can't do it. I'll have too much going on in this chip. I'll gladly accept a little latency for ease of tasking. But for the same issue I think they aren't RTOS welcoming, I have a concern they are doing ALOT inside of ISR handling. Like it seems the entire SoftDevice functions all take place during high level IRQ events, I can see why this may screw with RTOSes.

Overall I think Nordic is the right path. TI's CC2650 or whatever looks alright, but non-updatable and smaller flash, less periphs, and costs more.

[alexanderbrevig]

Just as a quick side-note, the Primo will have WiFi (using ESP8266). It also has an STM32 for CMSIS DAP and an IR interface.

In case you're on windows I made this: http://alexanderbrevig.github.io/technology/2016/01/25/nRF52-gnu-toolchain/
A simple step-by-step to get up and running with the open source toolchain.

Even though I'm affiliated with the Primo, I'd recommend that you get a DK from Nordic. In case you need support from them, communication will be easier.
They are awesome at customer service BTW.

[jnz]

Just as a quick side-note, the Primo will have WiFi (using ESP8266). It also has an STM32 for CMSIS DAP and an IR interface. Even though I'm affiliated with the Primo, I'd recommend that you get a DK from Nordic. In case you need support from them, communication will be easier.
They are awesome at customer service BTW.

Saw the Primo, looks good.

Yea, got the DK hardware from Nordic, and the latest SDK (v11). I'm just having a couple of issues now with their RTOS handling. It seems they really want to push you away from it, because they can't give the softdevice ultimate priority it needs without putting the OS in some weird positions where it might miss events. I understand, it's just definitely a con when compared to a separate module or to the TI which runs dual unique cores.

So far the Nordic is definitely winning. It's just I'm giving up a little on a peripheral or two and the OS. Compromises.