RoadTest: STMicroelectronics Discovery Kit for IoT node
Author: vitorafsr
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: null
What were the biggest problems encountered?: Configuring ISM43362-M3G-L44 (eS-WiFi) to work with a driver from mbed OS.
Detailed Review:
In this roadtest, I reviewed the board B-L475E-IOT01A Discovery kit for IoT node. The board features are:
To work with the B-L475E-IOT01A Discovery kit for IoT node I opted to develop a solution I called "Shot Analyzer", and comment along the development. It is useful to know that this is my first experience with ARM programming.
Before describing the testing and experiences, I would like to sum up some ideas at the beginning.
The board comes with lots of sensors and is very suitable for prototyping. I come to some other ideas to implement with the board before the actual one, and all of them were completely implementable with this board. A first simpler idea that came to my mind was to acquire temperature and humidity from the board, and infer the color of a flag based on a table that says when weather is appropriate or not for practicing exercise. I abandoned this idea to a more complete one that I can explore the board more.
The documentation of the sensors in the board are directly available in the site st.com. And there are also Design Tips that help developers in lots of points when programming the sensors and microcontroller. I could find documentation for everything I needed either coming from ST or from the community.
On the other hand, I concluded the board manual focus on the hardware point of view, directing the user to implement code via STM32CubeMX and HAL Drivers. Example: Wifi ISM43362-M3G-L44 is said to work via UART and SPI. The first idea that comes to mind is to enable UART and send string AT commands. It does not work that way! I tried UART and SPI with HAL Drivers directly but nothing. Then I discovered mbed OS that is a better approach to program the board as a standard product. Then I began using mbed drivers, and discovered that the Wifi driver talks to the wifi via SPI. The link for the board drivers in mbed OS is https://os.mbed.com/platforms/ST-Discovery-L475E-IOT01A/ . There is a message on the board enclosure that says "ARM Mbed Enabled" and also in the beginning of the manual but they are very subtle. This way, the novice user does not go to mbed OS at first.
The board manual has a pattern of describing peripherals by its hardware features that repeats along the manual for all sensors, peripherals, etc. This approach is more adequate to an engineer designing a customized board with a microcontroller. But not for someone that intends to use the board features directly as a ready information from the sensors.
I wrote the road test chronologically to express my experiences with the board. First I set up the environment for programming, than began coding. Every step are put in the text as I think they are useful for the ST company.
The source code of the final software of Shot Analyzer is at https://bitbucket.org/vitorafsr/shot_analyzer/
The solution I chose to use the board is to attach it to a hand gun to spot common mistakes beginners do during shotting, using the magnetometer.
The project aims to detect the direction of the bullet when the error in pointing the gun is so large that the bullet does not touch the target. The instructor in case will point the mistakes looking to a graph. The small errors are easily identified looking to the target hole.
The three common errors to be identified by the project are described below.
All the movements of the gun is going to be registered by the board via the magnetometer X,Y,Z, and the data is going to be sent to the PC to be plot. Data is sent through Wifi client connection to a server in the PC. Each time someone fires the gun, he or she will press the user button to send the last 5 seconds of data to be plotted.
The instructor, looking to the graph will show the mistakes.
In the board, the LIS3MDL magnetometer will register the gun position.
The board magnetometer is attached to the I2C bus. Then the setup is to repeatedly pool X, Y and Z via I2C, store data circularly in a array, and transmit data through Wi-fi to be plotted on a computer. The array always contains the last 5 seconds of data. New data overwrite the oldest one.
The board will send data to the computer via Wi-Fi module Inventek ISM43362-M3G-L44.
The board and the PC will be connected to the same LAN via a Wifi access point, both to the same SSID. The computer will instantiate a TCP server to listen to data on a TCP port; I chose receive data via netcat listen. The board will submit data to the server TCP port via an interrupt caused by pressing the blue user button on the board.
Data is going to be plotted with gnuplot. All the development is done in Linux.
ARM programming for the STM32L4 microcontroller is done with:
My OS is Linux (Ubuntu 16.04.3 LTS) then I search for a toolchain that fits it. As my style of programming is closer to Vim+Makefile I chose STMCubeMx to export code for the toolchain/IDE as Makefile.
I chose not to use an IDE, but I searched for one. During the time I was looking for the toolchain/IDE, I identified that the majority of options are for Windows. One IDE I thought is adequate for Linux users is CrossWorks that has no native support inside STMCubeMX but can import project from other toolchain/IDE as described in this video https://www.youtube.com/watch?v=-GcWhUdXCYI . This is a suggestion to other users.
STMCubeMx installation is very straightforward: just download, unzip and run. It is supported in Linux as it uses JVM.
The JRE I used was
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
To understand at first what STMCubeMX is I watched videos on
Watching videos was very clarifying.
Pinout setup must be done looking to the board manual, especially the "Schematics" section and the "STM32L4 Discovery kit for IoT node I/O assignment" section. I say that because on the board manual the following statement is encountered: "On the STM32L4 Discovery kit IoT node, the I2C2 bus from STM32L475VG is used [for the High-performance 3-axis magnetometer]". Based only on this affirmation, I was influenced to just activate I2C2 peripheral on the pinout setup but the schematics and assignments clarify that GPIO_EXTI8 also must be activated. Going to schematics was valuable at this point.
A difference between the manual and STMCubeMX is about configuring board to send and receive text over serial. Virtual serial /dev/ttyACM0 is said to be reachable via USART1 of MCU on the manual (actually the manual says USART6 that does not exist, and is wrong, but fortunately I supposed the correct is USART1). Then I navigated at pinout tree of STMCubeMX (on the left) and activated USART1 to "Asynchronous". It enabled PA9 and PA10 pins on the MCU picture. I thought alright and tried to communicate with the board. Nothing! Back to the manual, it says USART1 (actually it says USART6, wrongly), and on the table 11 the pins associated to USART1 are PB6 and PB7. Surprise! Pins on the manual are different from those auto activated by STM32CubeMX! It took time to discover this misbehavior. Back to STMCubeMX, I enabled PB6 and PB7 as USART1 accordingly to the manual, and nothing. Then after enabling PB6 and PB7 on the chip picture, I enabled USART1 again at the pinout tree on the left and at this moment it did not activated PA9 and PA10 as in the beginning but highlighted PB6 and PB7, i.e., same activation behave differently depending on pins selection before directly on the MCU. Fortunately everything was right at this moment. Possibly a bug that was hard to discover and understand.
Code was written using datasheets, board manual, schematics, examples from en.stm32cubel4 and source code from the mbed OS site.
I downloaded compiler from the link below. It was just extract and point installation directory inside Makefile. https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
Before compilation, I fixed a bug on Makefile file generated by STMCubeMX that included some filenames twice. The tip I extracted from https://primalcortex.wordpress.com/2017/11/03/stm-cubemx-and-multiple-definition-errors/#comment-3524
After the Makefile fixed, it was just put compiler path inside "Makefile", issue 'make' and compilation was done.
I received the board after STM32CubeProgrammer was released then I used this software to program the board.
After installing the software, as my Linux is Ubuntu 16.04.3 with OpenJDK JRE by default, and the STM32CubeProg claims for a Oracle JRE, I could not run at first. I had to install openjfx to finally open it.
After receiving the board, I proceeded a firmware upgrade of the board which at finish let me without communicating with the board. Before upgrade I could connect. The message was "Error: ST-LINK error (DEV_NO_DEVICE)" when trying to connect.
Changing "Reset mode" on the right of the software panel to "Hardware reset" the connection could be established again. But the problem in "Software reset" mode remains.
Finally, I opted to program the board with a command line: "STM32_Programmer.sh -c port=SWD reset=HWrst -w shot_anlyzer.bin 0x08000000"
The board arrived later after I have set up the software environment. The board was delayed at customs as customs were on strike in my country.
On the right is the picture of the board as it arrived: just the board inside a box. And that was sufficient as the communication PC<->board needs only a USB cabe similar to the ones to charge smartphones: type-A, micro-B. And this cable is easily available.
The board has four feet that are very useful when putting over a table to avoid touching components directly to the table.
At first I tried to turn on and off user led to handle with the board. A very clean configuration. Just follow the board manual and HAL Drivers to set and reset GPIO.
To debug the implementation I chose to send data via serial. I opted to implement data through serial with a function similar to printf but that requires less effort than rewrite printf. I create a char array, populate it with "sprintf", and then send the array via "HAL_UART_Transmit". Transmission ends on the '\0' character from the array. It works very well.
I put magnetometer to work with everything as expected. The module is reached via I2C bus and all went well as the documentation says.
I undergone the challenge to put wifi to work. A forgettable experience that must not be fully explained as coding finished weirdly working. I at first tried to communicate with the board via UART3 as it is said to communicate with this bus by the manual. No way! Tried SPI3. Did not work. Discovered mbed OS. Tried mbed OS. It was a bad experience. All tools I tried to put to work at some moment failed with simple problems as link does not exist, binary is not found, and some more. Looked to the mbed OS driver source code for wifi. It seemed tractable. I copied it into the directory of the project and began a fusion. STM32CubeMX generates a code that conflicts with the driver code. I had to make adjustments. Also used bad patterns for today programming as declaring a "extern" variable. But in the end wifi module worked. I inferred that mbed OS is a well planned OS but I was not lucky. Programming with HAL Drivers and STM32CubeMX was a better experience. But I admit that mbed OS code is the way to go as it makes many things easier. Really the paths I followed are not for a beginner.
Very straightforward implementation. I configured interrupt associated with the user button on STM32CubeMX, look at source code from GPIO_EXTI project of STM32L476G-Discovery of STM32Cube_FW_L4_V1.10.0, implemented my side of programming, and everything went well.
The code I set up in the first round for Wifi had a bug: it established a TCP connection always, even without a TCP server. Then I looked again at mbed OS source code, and opted to put all as was, and only call methods believing that SPI being configured twice (first by STM32CubeMX code, then mbed OS driver) would not conflict. It worked very well, and the TCP connection could finally connect to only an existing server. Without a server, it could not connect. My approach was to checkout mbed OS driver via "hg clone" and program via methods published by the driver.
By the previous experience with Wifi from the mbed OS driver, I reimplemented the code to talk to the magnetometer sensor using the mbed OS driver as it contains many more already implemented features than mine.
The pictures with title "Magnetometer data" is the data collected from the magnetometer when the board is in rest during 5 seconds period. Data was smoothed for the plot via "smooth csplines" in gnuplot.
The board was attached to a gun as can be seen in the following figures. The gun is an airsoft gun that fires based on air flow. There no bullet in this test, only the movement of firing.
It is to point that the airsoft movement is far soft than the real one, and I can say that the movement of the gun because of the air was not sufficient to stimulate the board sensor as I expected in the beginning. I tried to use a real gun. Unfortunately, I could not do a real fire as I was blocked by a stand owner because he did not allowed to attach the equipment to the real gun, and then I opted to go with the airsoft solution.
The pictures below show how I connected the board to the gun.
The following video show how the gun moved during a shot.
From the assembled solution, the following graphs show the data collected from the magnetometer.
Shooting right: X data goes up in the graph.
Shooting down: X data goes up in the graph.
Shooting left: X data goes down in the graph.
Shooting up: X data goes down in the graph.
It is possible to notice that the X axis is the more sensible one, varying during all movements. The others axis were not as sensible as X axis.
There is some opportunity for improvements as the sensors accelerometer and gyroscope were not used to collect data in this test.
In this second attempt, I implemented the Design tip DT0060 to exploit the gyroscope to update tilt measure and e-compass. The position of the board attached to the gun also changed: it was put in front of the gun to receive more movement after a fire is dispatched. The results are below.
Shooting right: Y data goes up and down in the graph.
Shooting down: no pattern identified.
Shooting left: Y data goes down and up in the graph.
Shooting up: no pattern identified.
Similarly to the first test, one of the axis -- Y in this second test -- gives clear information about the movement of the gun.
I conclude the board is a complete solution for prototyping. Many sensors, a powerfull microcontroller. The environment for ARM coding is well satisfactory once the pieces are understood. mbed is a OS that offers a direct and clean interface to the board features and is the first place for a developer to go to work with this board.
One point is that the board is big to be attached in objects similar to the one in this project. A breakout boards with a base board with microcontroller like a NUCLEO-L031K6 is another solution to pursuit when size matters in a prototype.
The sensor partially output data as I expected from the initial plan. X data in the first test and Y data in the second gave the graph from which we can distinguish between left and right, but it is not possible to distinguish between up and down. Perhaps some better positioning of the sensors, and correct treatment of the raw data can help in the objectives of the project. But this is a research for a whole project that is out of the scope of this report.
Thanks Randall Scasny, Element14 and ST for the opportunity to work with the board. Thanks Trajano, Ambrósio, Isaac, Dantas, Juan, Mariana that helped me do the tests.
