[ZeROSEro7] Schematics

This week I worked on schematics.

I improved USB Sniffer schematics because there were several mistakes. nRF52832 chip and its antenna route constraints were not respected, wire width were improved (bigger for VCC and with a 50 ohm impedance for antenna), several ground pad were no linked.

Moreover, I routed Stealth Drop board using what I learned from USB Sniffer routing.

I still have to make a basic Android app to send and receive WiFi data.

See you next week

[ZeROSEro7] First LoRa transmission

Last week I worked further on controlling the SX1276 from the nRF52. Once I could use the high level functions from Semtech, I tested it and checked if the registers were set as expected. To complete the implementation, I had to write the code to control the antenna switch, which is trvial on our schematic. I also had to link the handlers for the optional IRQ DIOs. Unfortunately, the SDK doesn’t support them being disconnected so I had to rewrite a small part of the SDK with a similar behavior but without the IRQs. It is possible to switch back to the previous code by defining a symbol for the preprocessor. This will reduce CPU execution time but is completly optionnal otherwise.

I had very few debuging options to finally transmit over LoRa. I knew my timing and SPI transfers were right, but the transmission wasn’t working. After further analysis of the SX12 datasheet and checking the state registers, I was able to make a first transmission !

Among other things, there was a very misleading naming for modes :

There was the continuous mode vs packet mode, which states wether the rx data goes in the fifo or to the DIO. I chose packet.

And the continuous mode as opposed to single-shot mode. In single-shot, the antenna only goes to rx mode for a few symbols of time so I couldn’t receive anything. So I had to choose this continuous mode.

Before I resolved this ambiguity, I ran into troubles because the receiver didn’t have the expected behavior and spent all his time in standby mode.

Aside from this, I helped reviewing the schematics and PCBs that Erwan and Vincent made.


For this week, I’ll try to finish the parrots on both LoRa and BLE to close those PSSCs in time. I’ll use the remaining time (if any) to help Erwan with the USB. Indeed, driving 2 USB bus in parallel will probably be a tough challenge and will require to dive into the drivers if we want to respect the timing constraints. I also hope that we will finish all our PCBs before next week.

[ZeROSEro7] Understand USB Keyboard

This week, I worked on Schematics, PCB and USB Keyboard.


We finished first schematic version of each device. I updated some details on schematics before to begin all PCB.
I also added a spreadsheet of the STM32Fxx pin functions. Finally, I added a file in the wiki about the power supply of each component.

USB Keyboard

I started to work on the USB Keyboard Issue. The goal is to plug a PC to an STM32 (Olimex OTG1 port) and to plug the same STM32 (Olimex OTG2 port) to a USB Keyboard. The PC has to detect a keyboard without to see the STM32 between both. The STM32 has to get all USB Keyboard interaction as descriptors and interrupt to send it to the PC.

The first step would be to get USB Keyboard descriptors and show it on the RTT connection. However, I’m still working on this step.

I started to check the Olimex board connection to know jumper position and I updated the file board.h correctly.

USB protocol

I read documentations about the USB standard from the official website, some blogs as site OUAIBE de la BIDOUILLE and some forums. I got knowledge about how USB works. There are four types of communication : control, bulk, interrupt and isochronous. Note that Keyboard works with interrupt.

Each communication is constructed with different packet:

  • Token
8bits 2x4bits 7bits 4bits 5bits 3bits
  • Data
8bits 2x4bits 1024bits 16bits 3bits
  • Handshake
8bits 2x4bits 3bits
  • SOF (Start of Fram)
Sync PID FramNumber CRC5 EOP
8bits 2x4bits 5bits 3bits

Finally, there are four descriptors : devices, configuration, interface and endpoint descriptors. Each descriptors has field contain information about the device. The PID, VID, consumption, type of communication, etc.

USB on ChibiOS

My difficulties are to implement that on the STM32 and more specially with the OS we choose: ChibiOS.

I got back usbcfg from ChibiOS/testhal/STM32/STM32F4xx/USB_CDC_IAD/
This example uses two SerialUSBDriver SDU1 and SDU2 but not as a host.

I found another example at ChibiOS/community/testhal/STM32/STM32F4xx/USB_HOST/ which logically implement what we need. Nevertheless, the code is very hard to understand and is not possible to compile it. I try to debug the Makefile, but there are too many errors. I will continue to read ChibiOS documentation, code and forum to find a solution.

Next week

Next week, I will finished the spy talk PCB and continue to work on the USB Keyboard Issue.

[ZeROSEro7] WiFi finally works

This week, I worked on WiFi module: AMW106. This chip must be controlled by UART so I used OLIMEX stm32f407 board. I can now send commands to the AMW106. ZentriOS is implemented into this chip so every WiFi communications could be done with high level interface using this command set. For example, I successfully tried to get all available SSID.

Moreover, I improved USB Sniffer schematics, almost finished to route it and I made first version of Stealth Drop schematics.

I must now make a basic Android application to discuss with AMW106 chip, i.e. send and receive data. I will also continue to work on schematics.

See you next week.

[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.

[ZeROSEro7] Schematics

This week, I worked essentially on the USB Sniffer schematics and Spy Talk schematics.

LoRa SX1276

first day of the week, I continued to work on the SX1276. The purpose was to write an SPI interface between the microprocessor (nRF52832) and the LoRa module (SX1276). The difficulty is to well understand the microprocessor SDK (Nordic) and the LoRa SDK (icube) to merge each SPI interface.

We finally choose Enguerrand to manage this issue because of his great knowledge about Nordic and icube SDK. In addition, it was an emergency to start schematics, what I did.


I got back Vincent’s work about USB Sniffer and continued the schematics on the XpeditionPCB software. I finished the first schematic version of this device. We got Mr. Polti A. feedback about it and I’m working to fix errors and update the schematics before start the PCB. I also started the Spy Talk schematics and almost finished the first version.

Next week

Next week, I will finish schematics of USB Sniffer and Spy Talk and start one PCB. We also received two USB OTG cables to plug a keyboard on the Olimex card. So I would like to begin working on the issue about reading keyboard action on the Olimex (STM32).

[ZeROSEro7] WiFi chip switch

The previous week, I worked on the WiFi development board C3220SF-LAUNCHXL.

At the previous post, I was able to compile and load program with command line into the development board. Also, TI provides an IDE to load and debug a program. However, I was not able to debug with command line. Therefore, without the whole board (only with the chip), I can’t debug any program.

I used JLINK to access the CC3220SF chip but several errors occurred. More specifically, AHB-AP registers of the Cortex-M4 values are wrong (DBGDRAR, which is read only is not valid for example). I am now stuck at this step.

After 3 week working on the WiFi module, we decided to change it. The stealth drop architecture is changing: we will replace the C3220SF by a STM32F215 (same as USB Sniffer µP) and a AMW006.

I also worked on USB Sniffer schematics. I almost finished its first version. I need to choose an antenna.

This week, I will try to use the AMW006 chip and I will finish USB Sniffer schematics.

See you next week

[ZeROSEro7] First transmission from smartphone to nRF52

As Erwan said, we swapped the LoRa and BLE dev kits and explained to each other what we understood. Since the SW1276 dev kit has changed, he will have some modifications to make but I hope we’ll eventually get the LoRa Ping Pong demo code run on this one very soon !


Additionnaly, I made great progress on the nRF52 dev kit. Erwan did a great job and could run the Fibonacci program and even toggle some LEDs, but I couldn’t run any code including BLE from the SDK. I eventually found out that the driver responsible for BLE, “softdevice” had been obfuscated. It’s actually a binairy file that I had to place at the start of the flash. It contained an SVC interruption handler at the specific address which then tried calling different “observers” by finding them in the binairy through function IDs. It’s the only part of the SDK which doesn’t provide it’s source code and works so weird. Anyway, this adventure helped me understand how most of the BLE functions bizarre prototypes. Indeed, they look like this :

SVCALL(SD_BLE_GAP_ADV_START, uint32_t, sd_ble_gap_adv_start(ble_gap_adv_params_t const *p_adv_params));

This discovery was made possible because I had implemented a logging tool via RTT. Not only can I printf things with it, but I also mixed it with a few debug tools in the dev kit. For instance, I was able to override a weak error_handler that is called every time a SoftDevice function returns an error code and print it. I also found a translator that, for a given error code, returns a printable string describing it. It is then easy to find the Doxygen I generated for the SDK and have additionnal information.


After that adventure, I was finally able to make a successfull ble_init ! The next step was to communicate with something else through BLE. Since our gadgets have to be discreet, I didn’t wanted the dev kit to advertise itself but rather wait for a particular signal before starting a connection so in the first steps of the use case, the gadget will actually act as a “central” BLE device rather than a “peripheral”. Unfortunatelly, this will mean more power consumption since BLE is an assymetrical protocol so that the peripheral can reduce power.

After reading the examples, I incrementally built a software to detect BLE advertisements, and then a nice function to parse them and print each field separately through RTT. It worked and I discovered 2 BLE peripherals advertising in my area but unfortunately among their 31 bytes of data was only a “manufacturer specific” field and private addresses so I couldn’t know what was their use. I then tried to see if I could receive the name of my phone through BLE by activating it. But it didn’t work.

Indeed, phones advertise themselves in normal BL and not BLE ! So I had to write an app to do the job, which I did. I learned all I had to learn in Android and made a “service” to advertise just the name of the device in BLE. And it was a success ! Here’s what I printed via RTT on the other end :

=> Advertisement detected

 Address : Type = 0x00 , GAP = 0x38B020490

 Advertisement Type : 03 

Parsing advdata : 

Data field :Type = 0x09 Data :ZeROSEro7 phone


Once this was done, I added the gitlab CI rules to produce the apk as an artifact and run all JUnit tests if any.


Next week : Wifi, PCB schematics

We have a huge assignment aside from ROSE to make a PCB that is due on Thursday so I won’t have much time for the projects. My next goals are to help Vincent with the wifi module and also to advance on our PCB schematics. I also really enjoyed working with the Nordic SDK because it has a nice documentation and Android is cool too so maybe I’ll try to create a GATT connection on BLE.

See you next week,


[ZeROSEro7] Running demo and Fibonacci on the STM32F4xx Dev Kit

I didn’t post last week because I participated in the ATHENS program. I wasn’t in France and I was pretty busy.
Nevertheless, this week, I continued the ZeROSEro7 project and I’m writing about my advancement in the project.

nRF52 dev kit (BLE) to SX1276 dev kit (LoRa)

After finishing the nRF52_DK environment and successfully close the issue “nrf52 dev kit Fibonacci”, I let Enguerrand to continue BLE development on this dev kit.

In addition, I started to manage about the new SX1276 dev kit received last Wednesday. I read the datasheet, schematic, etc. about SX1276 (LoRa). I got back useful documents from the Internet and from Enguerrand’s works to push into a git repository. I obviously spoke with Enguerrand about his works on the previous LoRa dev kit to save all useful information about his works.

I also connected the SX1276 dev kit to the STM32 dev kit (Olimex) with breadboard jumper cables in SPI communication:

Tab 1 : Connexion Olimex – SX1276
VCC UEXT – 1 J3 – 4
GND UEXT – 2 J2 – 7
NSS J3 – 6 (SX1276) J2 – 3
MOSI UEXT – 8 J2 – 4
MISO UEXT – 7 J2 – 5
SCK UEXT – 9 J2 – 6



I have to verify the right connexion between olimex and sx1276 with example program to flash in the STM32.

Fibonacci on the STM32F4xx Dev Kit

like with nRF52 dev kit (Nordic), I made an environment for the STM32 dev kit (Olimex).
I added ChibiOS in our git repository and to the usb_dev_kit directory, there is the environment to develop on the STM32 dev kit.
With the Makefile, it’s possible to format the code, compile and debug with gdb.
I updated CI tests to use adapted docker image to compile with the last version of arm-none-eabi-gdb.
All CI tests pass, I merged with dev branch and I closed the issue Fibonacci runs on STM32 dev kit.

Schematics and PCB

I’m improving on the mentor software to draw schematic and I have to start a schematic about one device before next week.

Next week

So for the next week, I will continue about SX1276 (LoRa) with Enguerrand’s help and I will start schematic of one device.

[ZeROSEro7] CC3220SF-LaunchXL

This week, I worked on the WiFi development board in order to be able to launch and debug programs.

The CC3220SF-LaunchXL board is pretty easy to use because there is several tools to develop on this board.

There is a lot of documentation, a SDK, a program used to flash the card and a complete IDE based on eclipse.

Despite all this tools, it’s very difficult to compile, flash and debut some program “manually”.

Hopefully, SDK gives some examples so I am able to compile a program.

Moreover, a set of command lines are defined to flash the card. Therefore, I can flash the board with my own programs. Actually, I found three different ways to flash the card.

However, I’m not able to debug this program. Using IDE, I can make whatever I want, i.e program, compile, flash, and debug, but I can’t use command line so I can’t make it easy to use.

I will spend this new week to continue working on the CC3220SF-LaunchXL and I will start to use Expedition PCB.

See you next week