[Little Brosers] Narrowing the components list and pushing my first commit !

SoC final choice

After more digging into SDK features, we finally chose the NRF52832 from Nordic as our SoC thanks to Nordic’s great SDK.

Why this choice ? I’m glad you asked!

Comparing NXP, Cypress and Nordic SDKs, I came to the conclusion that our development process would be simplified the most using Nordic’s SDK. Not only the C libraries from Nordic such as the nRF5 SDK v14.1.0 are impressively well documented but we will also be helped by the Nordic Android BLE SDK and user guide for the mobile app we plan to develop.

Other tools may be considered. For example, Nordic provide the Power Profiler Kit allowing developers to estimate the current consumption of the SoC during our code execution from 1µA to 70mA with a resolution of 0.2µA.

Also, Nordic’s SoC come with OTA firmware update feature. Allowing us to easily setup the firmware update process though BLE.

Choosing the Flash memory

We had less specific needs for the flash memory.

To estimate the needed size, I used the following values:

  • A message with payload +  Little Brosers’s overhead should take less than 400 bytes
  • A drop should be able to store around 9000 messages
  • A worst case scenario 4-ary Merkle tree with this configuration should have a size of 300kB with 128 bits long hashs
  • The total of those estimation gave us a size of around 4MB

Of course those estimations are not precise but 9000 messages is quite a big number and we’ll allow us to store less messages on a drop if needed.

I also knew that a easy to solder package like SOIC-8 would be way more convenient during the soldering process of our PCBs.

In the end I had 5 flash models packaged in a SOIC-8 with similar features and I selected one of average price, well balanced set of feature and allowing several power modes to adapt its consumption. This is the AT45DB321E from Adesto Technologies.

Pushing my first commit

Indeed, for the drops firmware we plan to separate the C source code supposed to be used in the drops and the C++ source code only executed one our PCs to perform quick simulations. This structure should allow us to develop the hardware independent C code for the drops and test it using C++ ease of use. Those simulations will allow us to perform Merkle tree merges without the whole BLE communication process. We will emulate it with C++ objects.

So, i spoke about my first commit… and what a commit !

Indeed, we decided to start from a Nordic’s SDK’s example four our Makefile structure. Thus, I had to put the whole Nordic SDK in the repository (~120MB).

In the following weeks, I’ll work on editing the Nordic’s Makefile to include our C++ simulation environnement.

Eventually, we would like to have a Makefile from which we could run the following kind of targets:

  • make sim : build a x86 binary including hardware independent C code and the C++ simulation code
  • make devkit : build an ARM binary for the NRF52 DevKit including hardware independent C code, SDK and DevKit specific code
  • make firmware : build an ARM binary for the drops including hardware independent C code, BLE code, SDK and Drops specific code
  • make clean : well… clean the project
  • make flashdv : flash the DevKit with its dedicated binary
  • make flashd : flash a Drop with its dedicated binary

See you next week !!

Antony Lopez

[Little Brosers] SoC choice

Here come the end of the third week of ROSE and the Little Brosers project keeps evolving!

For the past week, we have been designing the project based on a approximative idea for the SoC we will use.
We knew we needed a SoC including at least on-chip BLE and some hardware cryptographic blocks like AES and random number generator. The SoC choice should also be conditioned by the chip’s consumption.

Eliminating candidates

First choice was the NRF52840 from Nordic with its “ARM CryptoCell-310” providing a lot of security features that we wouldn’t have to implement in our software. The full description is available here. Unfortunately, this chip is not easily available right now and its consumption could be a problem if placed in a Drop.

We also considered the DA14681 from Dialog Semiconductor with the same kind of features but we’ve been informed that Dialog Semiconductor’s SoCs use to cause problems during implementation and its consumption would also be incompatible with our needs.

The five remaining SoCs

The remaining SoCs we had in mind were the NRF52832 and the NRF52810 from Nordic. Also listed are the QN902X and the MKW31Z from NXP. Finally, one of Cypress Semiconductor’s SoCs could be eligible, the CYW20737 . All of those SoCs have an associated DevKit and SDK.

The main difference between Nordic, NXP and Cypress is the presence of Bluetooth 5 in the Nordic chips. However, even if Bluetooth 5 makes our project ready for the next ~5 years of Bluetooth technology, we won’t take advantage of its higher throughput and longer range because less than 5 main stream smartphones feature Bluetooth 5 for now. Thus, the Little Brosers project will use BLE from Bluetooth 4 standard (even if it includes Nordic chips) in order to be compatible with the most of the smartphones out there.

How to choose the winner ?

The NRF52810 is basically a NRF52832 with less GPIO, PWM, RTC, TIMER and bus protocols. The RAM/flash capacity is also shrunken and NFC, I2S and the low power comparator have been removed. Thus if we go for the NRF52832, we will switch to its little brother only if we realize that the NRF52810 can run our code flawlessly with its reduced memory capacity.

On the other hand, the NXP and Cypress chips are quite similar from each other and for now we can’t decided which one we would pick if we only based our judgement on hardware.

Then comes the manufacturer’s SDK. This is gonna be my main research subject for the next days to determine which SDK will make our development flow easier and therefore, will help us finalize our SoC choice.


Stay tuned !


Antony Lopez