[ZeROSEro7] SX1276 on nRF52 dev kit

Since we will be using the SX1276 connected via SPI to the nRF52, I started to implement basic LoRa communication by plugging the SX1276 on the Nordic dev board. Now that I made my first BLE transmission, I am quite comfortable with the Nordic dev kit and I’m also a bit used to piloting the SX12 with iCube. Unfortunatelly, the LoRa Middleware is only available for STM32s. I could pilot it by manually coding all SPIs transmission, or I could bridge the LoRa Middleware and make it work on Nordic’s dev kit instead of iCUBE.

What I got from iCube isn’t just Semtech’s LoRaMac driver, STM enhanced it a bit for cortex 4, which is also included in the nRF so I’ll rather start with the iCube version of this SX12 driver. I had already dived into the code of both SDK and found the proper layer of abstraction where I can replace the header files in iCUBE with my custom ones. I found out that the middleware was already designed to be portable by implementing 3 custom headers : hw_spi hw_rtc and hw_gpio. It even provided templates for it. But with the additions of iCube, there’s a bit more to it : I also need a hw_conf to define some compiler specific symbols. I reduced to the minimum the templates, especially the gpio one which is only used to reset the SX12 by toggling a single pin with a few ms delays.


After a lot of understanding the SDKs, I was able to create a Makefile combining both SDKs interesting parts and using my own headers. That was a really interesting and challenging puzzle. I really enjoyed it and gained much experience. From there, I started implementing the source files for those headers.

The compiler specific one was the first and i had minor troubles because Nordic also used it’s version of CMSIS, like iCube so some symbols were redefined, causing a comilation error when I tried linking both. I could have tweaked nRF’s Makefile but I found a simpler solution in enclosing my definitions in an #ifned.

That done, I implemented the RTC bridge. I hesitated for some time when choosing which one of the 3 (!!!) timing drivers from Nordic which are poorly named. I opted for app_timer, which works on the RTC peripheral from the MCU after checking if the timing precision was sufficient. Then, by carefully reading through iCube’s implementation of the RTC part, I designed my own relying on Nordic’s functionnalities. Some functions were very misleading. The worst was a getTime for which the documentation said “get Time in ticks. Returns time in microseconds.”. I was speechless. Also this is not at all an isolated case. Hopefully they corrected it in newer versions of the middleware. Anyway, each time I made a function, I tested it through my RTT and the LEDs and checked if the timing was alright. Even though Nordic as quite a good documentation, I was stuck for a few hours because the RTC wasn’t starting but no error was raised in the code. The doc doesn’t mention it, but I found on a forum that to enable the RTC module, the app_timer_init() function isn’t enough ! You also have to ask for some other driver that uses the low frequency clock to start it as a side effect ! Once I found out, I simply started my BLE module because softdevice is one of those drivers having this side effect. I really think all SDKs with which I have worked in embedded systems should spend more efforts on documenting.

Thereafter, I started working on the SPI bridge. I tested the SPI demos from Nordic with a logical analyser and coded my version of hw_spi.c.

Here is where I’m at. I still haven’t tested using the SX12 in any way but I implemented almost all necessary files to that the LoRa driver is compatible with the Nordic SDK. Only the gpio is missing and I will start connecting the SX12 and make it happen.


Hopefully I will run the ping pong demo on the nRF dev kit by next week. In the meantime, I will also work on the PCBs.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>




This site uses Akismet to reduce spam. Learn how your comment data is processed.