Categories

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

[ZeROSEro7] As small as a USB key

This week, we finished to find all of our main components; µC, WiFi , BLE and LoRa modules. Then, I worked on three different parts. I wrote specifications of these components, I worked on on the USB Sniffer architecture and I began to work with the WiFi module SDK.

Components specifications

Because all our components where chosen, I wrote their specification to make it clearer.

During this work, I noticed there is no demos with the STM32F215 (the µC) in ChibiOS. Therefore, I looked for another µC with a Chibi demo and two USB ports. The best I found was the STM32F429. Moreover, it has two times more FLASH and RAM (2MB and 256KB). Unfortunately, it is bigger (16x16mm), more expensive and it’s oversized for our needs. This µC will be used into USB Sniffer, with high size limitations so I made drafts of USB Sniffer hardware architecture and understood that 16x16mm is too much. To conclude we will use STM32F215 and work without Chibi demos.

USB Sniffer hardware architecture

Satisfied of my drafts made during the previous part, I continued to design the USB Sniffer hardware architecture. I choose to make a 3D model using Blender because I know this software and it’s pretty easy to work quickly.

All components dimensions are based on datasheets. Differences between this model and the final device can come from the PCB and fixation constraints. This model could help to imagine the size of the USB Sniffer.

USB Sniffer architecture

USB Sniffer 3D model

WiFi module software

After choosing development board for the WiFi module (CC3220SF-LAUNCHXL), I began to discover several tools to use and program this board. We will receive the board next week and I’m waiting for it to blink a LED !

 

See you next week