Categories

[ZeROSEro7] Transparent keyboard

This week, I worked on the USB keyboard, the SPI Slave, the read/write in Flash and casing.

USB Keyboard

The USB keyboard is now fully transparent. All input works and LED about Caps lock and NUM lock are managed according to SET REPORT from the computer as well.

I could add a feature to copy directly important descriptor of the keyboard plugged like PID and VID to be more transparent. It will be done if the time allows it.

SPI Slave

Currently, the most important part is the SPI slave. It’s used on two devices (USB Sniffer and Stealth Drop) to communicate between nRF52 (Master) and STM32 (Slave).

The configuration of the STM32 is as follow:

  • 16bit
  • CPHA = 0, CPOL = 0
  • MSB-first
  • NSS Hardware
  • Motorola mode
  • Slave mode
  • Rx interrupt on

I also add SPI_IRQHandler() in the vector table which called every interrupt.

I receive some data from the nRF52 but I got only the first byte of each tram and the Overrun flag turn on. So I fixed it while using mail box to manage received data.

Flash

I tried to read and write in the flash of the STM32F407 (Olimex). It’s not the most important features, but there is more storage in the flash memory than RAM and password will be safe in flash memory if the device is unplugged or the host computer is turned off.

First of all, I added a section in the linker script reserved for password data. I choose a lonely sector to be sure to not conflict with other data. In the software, I got back address from this section.

I can easily read in my section with the right address. Nevertheless, to write inside, I have to unlock the flash access with the right code in the right register. Every first write works well when flash is 0xFF value… But to write again, I have to erase the section before. And I have some trouble with the erase instruction because the STM32 crash… And the device become no bootable at all. I have to reload a program to fix it…

Casing

With Vincent, we designed the prototype casing of USB Sniffer and Spy Talk. We worked on Autodesk Fusion 360 software. See results on the following pictures:

Spy Talk

USB Sniffer

Last week

I have to fix the SPI slave and code the USB Sniffer demo software.

[ZeROSEro7] BLE fully operationnal

I made the last improvements to the BLE control and enabled fast two-way connection to a characteristic with a simple programming interface. I am using Write requests with no response on the GATT client side and notifications on the server side along with the highest MTU available for the nRF52 (200+ bytes). This will be usefull for the USB sniffer where we will download a great amount of data.

I ran a test program on our SpyTalk custom PCB and the BLE and LoRa chip worked. Yet, because of difficulties when welding, one of the Quartzs doesn’t seem to work but it is not critical. It will only raise consumption during off time.

I prepared a test program on the nRF SPI for the USB Sniffer that sends packets to the STM32 and expects a response. This program is proven to work because it did with the LoRa chip so now Erwan and I can implement the SPI driver on the STM side and imagine a simple protocol to exchange our data. This part will be even easier on the Stealth Drop because only a wakeup is sent. It could be done with a simple GPIO.

My next priorities are to finish the USB Sniffer, including the final user interface, and to design and implement a simple protocol over LoRa for the SpyTalk. This protocol will include at least addressing, retransmission, and basic AES encryption. I abandonned using LoRaMAC because this protocol, despite being very efficient for what we want to achieve, requires gateway stations which are usually public and it is not what we planned as our network architecture. It would also require different hardware. Given the time left, I may also add synchronization for lower RX time, better security with changing keys and any other ideas that may come to my mind. I’d also like to add bonding and security on the BLE connections.

Erwan and Vincent made great progress on their side and I think we are very close to having every of our 3 gadgets fully working!

[ZeROSEro7] WiFi and SD Card

Since my last post (a long time ago), I made several improvements.

I continued to work on WiFi chip and important parts in downloading and uploading files are finished. More specifically, from a smartphone, we can choose to upload or download a file.

Upload button will make the user choosing a file from smartphone memory and send it through http in blocks. WiFi chip will save each block into its FLASH as files. At the same time, STM32 will read and delete each block through UART. The content will be printed using RTT.

About downloading, a whole file, saved into WiFi chip FLASH, can be downloaded into smartphone “Download/” folder.

Before continuing WiFi communications, I want to make STM32 able to read and write in SD Card and to communicate with BLE. Now, files are not saved into STM32 memory so I want to implement SD Card interface . Moreover, STM32 doesn’t know when it need to wait for an upload (from smartphone), smartphone doesn’t know when WiFi chip FLASH is full and it doesn’t know available files to download. These problems can be solved using BLE to communicate from STM32 to smartphone.

I also worked on SD Card communications. I implemented and tested four main functions using ChibiOS:

sd_write_byte # Write a single byte at specified addresse

sd_write # Write several bytes from a buffer

sd_read_byte # Read a single byte at specified addresse

sd_read # Read a memory area

To deal with file saving, I will begin softly with only one file saved. Then, I want to use FAT C libraries to deal with files. I read the AmpeROSE post about SD Card and I would like to use the same API.

This week, I will continue to work on SD Card and on WiFi communications.

See you next week.

[ZeROSEro7] Keyboard works !

This week, we made a great improve with the USB keyboard. Indeed, we are able to use it on a computer with the STM32 (Olimex) between both. I also worked with Vincent on the porterage from the STM32F407 (Olimex) to the STM32F205 (USB Sniffer and Stealth Drop). Finally, I started to work on the SPI communication between an STM32 (Olimex) and a nRF52 (BLE).

USB Keyboard

The USB keyboard works on a computer with an STM32 (Olimex) between both. So I’m able to get every input from the keyboard to detect password, email, etc.

First of all, I got back an HID USB connection between the computer and the device. This communication start, the STM32 send its device, configuration, interface, HID and endpoint descriptor. These descriptors are currently hard coded. This will be done dynamically soon.

On the other side, a host USB communication start when a USB keyboard is plugged on the device (Olimex).

All interruptions from the keyboard are directly transferred to the computer, so it’s possible to use the keyboard normally… almost normally!

Input is fluent, every combine of input works except Caps lock and NUM lock! Indeed, all reports from the keyboard are sent to the computer, but no in the other direction. Caps lock and NUM lock input, update the status of LED on the keyboard managed by the computer. Worse, when the computer sends to the keyboard (STM32) the status of LED, the STM32 crash.

Hello World USB Sniffer !

As we received our PCB.

We wrote a code able to test each feature on board. On the USB Sniffer we want to test :

  • STM32F205
    • RGB LED
    • USB A male
    • USB A female
    • SPI communication
  • nRF52832
    • LED
    • BLE communication
    • SPI communication

We got back features from STM32F407 (Olimex) to use one the STM32F205. For that, we needed to manage the board.h and the tool chain compilation. Enguerrand choose the code to flash in the nRF5283.

And the very great news is every thing works !
Now we have to try the SPI communication between STM32 and nRF52

Slave SPI

I started to work on the SPI communication between an STM32 and an nRF52. It’s important that the nRF52 is the master of the communication ! Unfortunately, ChibiOS doesn’t implement a slave communication in SPI…

I got back STM32cubeF4 which is an MCU Package for STM32F4 series (HAL, Low-Layer APIs and CMSIS (CORE, DSP, RTOS), USB, TCP/IP, File system, RTOS, Graphic – coming with examples running on ST boards: STM32 Nucleo, Discovery kits and Evaluation boards). This one implements an example of slave SPI.

I’m trying to merge that with ChibiOS…

Next week

I want to valid the slave SPI communication between STM32 and nRF52 and add this feature to the USB Sniffer. I would like also to upgrade the USB keyboard to copy the dynamically USB descriptor and fix the problem with Caps lock and NUM lock.

[ZeROSEro7] Android CI, GATT dynamic connection and custom service

Great progress was made since my last post!

First of all, the CI was greatly improved. We now use smaller docker images for the different jobs and the code formatting is asserted using the checkstyle pluggin for gradle.

I’m intensely working on the BLE part as it is essential for all 3 sub-projects. We tested it on our USB Sniffer PCB and the BLE part is working with a 20dBm compared to the Nordic dev kit which enables a roughly 15m range for connection. This is completely satisfying for all gadgets but a bit short for the stealth drop. We don’t need a connection, but one advertisement has to be sent. We will measure the range for this packet reception once the stealth drop is welded.

I implemented GATT connection to a custom service on both sides (nrf52 and android app). It uses write and notification callbacks for faster transmission. Reading is much slower as it requires more transmissions. Just for the reminder, during our connection protocol, the device first waits for a specific advertisement from the phone (just the name field is examined for now, more complex mechanisms could be implemented if we have time). It then advertises itself as a smart shoe (nobody will try to find it ;)) and the phone initiates the GAP connection to this advertising. The connection is already dynamic, that is to say timeouts, disconnections and restarting is handled from both sides smoothly. The device also returns to observe mode a few seconds after the advertisement.

I read some documentation on bluetooth security and found many ways to have a secure process and connection. Nothing is enabled right now, but if I have time before the deadline, which is in 10 days, I could do the following:

  • Enable privacy by randomly masking the address of the device. An IRK (identification resolution key) will have to be shared with the phone.
  • Enable GAP connection encryption with AES and MITM protection
  • Enable GATT layer similar protections
  • Whitelist the phone’s scan requests instead of observing to get it’s advertisments. This has the downside that for demos with other phones, they either need to be in root userspace, or their BLE address must be entered in th device through some other way.

In the near future, I will provide the SPI interface to communicate between the phone and the STM through the BLE and the corresponding UI. Once the BLE is completly finished, I will switch to the LoRa communication to have the final Spy Talk prototype.

I am very confident that us 3 will have fully working demos for all 3 projects :). Yet, I have doubts concerning the range and data rate for the Stealth Drop.

[ZeROSEro7] USB Keyboard detected !

This week, we have finished schematics and PCB. We finally ordered PCB of USB Sniffer, Spy Talk and Stealth Drop devices. I also worked on the USB Keyboard and the SD card.

USB Keyboard

I created a macro to change usbDbgPrintf by rtt_printf. Therefor, all debug functions are usable on the RTT connection.
I listened M. Tardieu advice and I tried to use the USB_FS (OTG1) instead the USB_HS (OTG2). And it’s worked ! The card detects the keyboard and generates interrupt. It’s even possible to print the key pressed on the keyboard thank to the HID USB.
The next step will be sending keyboard descriptors to the computer to be a man in the middle device.

SD card

I started to work on the SD card. I just got back an example from ChibiOS to read and write SD card by the RTT connection.
The software is able to detect the SD card and report information about it but the read command fails.

After Christmas Holiday

I will continue to work on these two issues.

[ZeROSEro7] WiFi connection

During this week, I worked on schematics and on WiFi module.

Our schematics were verified by teachers and several advises were given. I made several modifications to fix these problems.

Then, I updated stealth drops PCB.

I also progressed with WiFi chip. The AMW106 can easily discuss using commands defined into ZentriOS-W. This command set could be sent by UART from our µP (STM32F215).

I had a problem to communicate with this chip. When a command is sent to the chip, it can respond with two kinds of messages, “Reponse” and “Log”. Some basic commands respond only a “Response” (for example commands to get ZentriOS version or variables content) but others send a “Response” and several “Log”.

I was able to send and receive properly  commands with a single response, but when several responses were received, I was only able to receive the first one. After that, timeout (~1s) occurred on the UART. I understood that the time between responses can be over several seconds and number of responding for a command can be different depending of the response’s content. I fixed this problem by waiting for a customizable delay (for example 4s is a good choice for a WiFi network scan). This long delay is not a problem for the project because we do not need to communicate with WiFi except for data transfert. Bluetooth is used to discuss between smartphone and our board.

I am now able to start a WiFi server on the chip with this command: “setup web”. A smartphone can connect to the chip with a correct password and access to the web service on the board (at setup.com). It’s a default website which allows to control the chip (file upload, remove, display, GPIO control, …).

I worked on a smartphone application (android) to upload and download data on the chip. I first made a wifi scan function on smartphone to verify that I can see the chip network. I am now working on the file upload.

I will continue to work on the smartphone application this week. I have three goals;

  • perform a file uploading from the smartphone to the chip
  • a downloading
  • make wifi network more secure and/or discreet

[ZeROSEro7] SX1276 DIO, ANT and now low power

Last week I improved my LoRa driver by using the IRQ through the DIO pins and greatly improved range. I increased the dBm output to 14 and made sure the RX sensitivity was correctly set. I then played with the CRC and spreading factor parameters to have best range performance. I still have to do an exterior range test with the antenna we will use, but with the dev kit, we were able to receive the signal on the other end of Telecom with all it’s walls.

I am now working on the power consumption, that is to say on sleep modes and wakeup times. Since I am focusing on the spy talk, I preferred the ON base current standby consumption for the nRF to save roughly 100ms on wakeup for only double the sleep consumption. I think this tradeoff is justified because even if the spy talk has low throughput, it should be able to send alarm messages really quickly. I must now try to disable as many peripherals, including the SX12 when I want to save energy. Depending on the algorithm, deep sleep may also be needed later.

I had a good look at the MAC layer from Semtech, but I’m not sure we will be using it. As mentionned above, we will aim towards very low latency and I’m not sure it will achieve that. Moreover, there is a lot of overhead and Everything isn’t completely customizeable. I still need to investigate this more, but for now I think I will design my own TCP-like protocol.

My next step will be to run a GATT server on BLE and I should have all my basic blocks to start the Spy talk software.

[ZeROSEro7] Host USB still get no descriptor…

This week, as last week, I worked on schematics and USB Keyboard.

Schematics and PCB

We almost finished schematics ! The second review on the USB Sniffer and the Stealth Drop was valid and few details have to be updated on the Spy Talk. PCB will be updated very soon.

USB Keyboard

I continued to work on the USB Keyboard issue. I updated the Makefile to compile with the ChibiOS_Contrib to use hal_usbh.h library.

In this file, there are some interesting typedefs:

  • USBHDriver
  • usbh_status
  • usbh_device
  • usbh_port
  • usbh_ep

…and some interesting functions:

  • usbhStart(USBHDriver *usbh);
  • usbhMainLoop(USBHDriver *usbh);
  • usbhDevicePrintInfo(usbh_device_t *dev);
  • usbhDevicePrintConfiguration(const uint8_t *descriptor, uint16_t rem);

I also found a very nice post on the ChibiOS forum which explain USB Host stack and driver for STM32. The contributor said he is still in development but he did it with some device like a Keyboard. It was 2 years ago, but I found some //TODO comment in the last ChibiOS version.

I got back files from HOST_USB example to integrate it in my project. I’m able to compile it and I added code in the main.c to use it. I configured OTG_HS (OTG2) pad correctly. I even verified the 5V tension on the USB_VBUS with a multi-meter and some device like a mouse where I can see LED turn on.

I used usbhDevicePrintInfo and usbhDevicePrintConfiguration on the USBHDriver USBHD2 to observe on the RTT connection all device information. Nevertheless, nothing happens and I only can see :

usbhDevicePrintInfo
----- Device info -----
Device descriptor:
USBSpec=0000, #configurations=0, langID0=0000
Class=00, Subclass=00, Protocol=00
VID=0000, PID=0000, Release=0000
----- End Device info -----

usbhDevicePrintConfiguration
----- Configuration info -----
Configuration descriptor:
Configuration 101, #IFs=104
----- End Configuration info -----

I’m still working on the step to get back USB Keyboard descriptor…

Next Week

Next week, I will command all PCB before Christmas and I will continue to work on the USB Keyboard.

[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