RoadTest: Seeking an IoT Product Reviewer for the STMicroelectronics STWINBX1 Development Kit
Author: gordonmx
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?: Nordic Thingy:91; STM SensorTile.box
What were the biggest problems encountered?: Lack of clear documentation
Detailed Review:
First off, I would like to thank STMicroelectronics and Element 14 for the opportunity to evaluate the STEVAL-STWINBX1 Development Kit (“the STWIN.box”).
Summary Conclusion –
NOTE: Before I start my review, as many of you already know, STMicroelectronics (STM) has been around for a while. Can anyone tell me what the letters in STM stands for? See the end of the “Summary Conclusion” for the answer.
As mentioned in the body of my review, despite the documentation, the STEVAL -STWINBX1 development kit doesn’t fit the description of a full feature development board, maybe more as a reference design used to demonstrate a limited subset of the complete functionality of the design. Hence the EVAL in the full product name (i.e. STEVAL -STWINBX1). However, the STWIN.box is still a worthwhile board to explore design possibilities in low power, portable IoT applications.
Like my last review of a STM board, my biggest concern is the disjoined organization of the documentation. Most of my time was surrounded by the time to locate all the details needed to get started with my review. As an example, I begin my review by outlining what the documentation tells me what I should expect (result or output) from operating the product. For the most part, the majority of the user manual lays out a very impressive set of features. Every dev or eval kit I’ve tried in the last 30+ years comes with one or more pre-installed apps with instructions (some cleaner than others). The STWIN.box does comes with a pre-installed (default) app, FP-SNS-STBOX1_BLEDedaultFw v1.4.0, but with little instructions on how it works. Section 4, “Default Application”, of the user manual, all 2 pages, cover the firmware download process. The Over-The-Air (OTA) software update/download was impressive. And there are other downloadable demos, but again, limited docs. But enough about documentation for now.
The board does support STM’s eclipse-based IDE when coupled with an open-source serial and debug adapter (STLink-V3MINIE or a STM32 Nucleo Dev board). If you already have the .hex or .bin download file, you can load it using the USB-C port and STM’s STM32CubeProgrammer.
I haven’t tried it, but STM has an application note for working with the Microsoft’s Visual Code IDE. I expected a little better documentation organization and cross referencing, but found a longer than expected learning curve.
NOTE: One of the best guides is the STM32Cube function pack – Quick Start Guide (See Useful Documents Links Section)
Pros –
Cons –
Overall, the design is workable, and I would recommend the STEVAL-STWINBX1 Development Kit for a potentially good starting point in understand future product features.
Useful Documents Links-
NOTE: Logging into the respective websites may be required to access some of the documents.
NOTE: The list of documentation seems fairly long, but there is more. Be sure to check out STM’s product, Wiki and GitHub sites.
In Section 1.1, Precautions for Use, of the User Guide, the following battery related warnings are issued:
Warning: Charge your device with a DC 5 V–500 mA USB charger at a temperature from 10°C to 35°C. The kit must be used within the working temperature range. It must never be exposed to excessive heat such as direct sunlight, fire, or heating equipment.
Danger: Use only USB chargers equipped with short-circuit protections to prevent fire hazard.
Danger: Use only the LiPo battery provided with the kit (HiMax 752535). A replacement of the battery with an incorrect type can defeat a safeguard. LiPo batteries can be damaged and even explode if they are short-circuited or overcharge or with an improper usage, such as mechanical crushes, hot oven, or battery cutting.
On more of a local note in Twin Falls, Idaho, USA. Last week a 35-year-old, owner-built log cabin burnt to the ground due to an overheated LiPo battery in the owner’s Alexa device.
Answer to today’s question: “STM” comes from the merging of two government-owned semiconductor companies in 1987. Italy-based SGS Microelectronic and French-based Thomson Semiconductor. SGS stood for Società Generale Semiconduttori or General Semiconductor Company. For further information, see https://en.wikipedia.org/wiki/STMicroelectronics.
Part Ia – A Little more about STM?
Before digging into details of the “dev kit”, let’s start with a little history of STM. Once again courtesy Wikipedia (among other sources), as mentioned earlier, STM (actually SGS-Thomson semiconductor division) didn’t spring out of thin air, but as a merger between two separate government-owned companies in 1987. In 1998, Thomson sold their share of the company and STMicroelectronic or STMicro or for this review STM, was reborn. The company is currently incorporated in the Netherlands and headquartered in Switzerland and is the largest European semiconductor manufacturer. Within the global semiconductor industry, they are ranked among the top 5 companies. A true global oriented company with an eye on sustainability and the environment.
Part Ib – What is the STEVAL-STWINBX1 (STWIN.box)?
Per STM’s website (see Useful Documents Links section), the main assembly of the STWIN.box is the core system board, STEVAL-STWBXCS1, featuring a powerful ARM Cortex-M33+ based STM32U585AI MCU with FPU and TrustZone at 160 MHz, provides an affordable and flexible way for users to try out new concepts and build prototypes by choosing from the various combinations of performance and power consumption features. The unit includes a number of processing, sensing, connectivity and expansion options. Here are some highlights of the STWIN.box board:
NOTE: Digressing for a moment, the following is an attempt to define what “development kit” mean. All kits by nature are evaluation systems, used to highlight one or more of a MCU’s features. For the most part, terms in the title like board, tool, discovery kit, may be used interchangeably. All boards, if designed correctly, can act as a reference design.
* Development Kit – The most flexible of evaluation systems for the part(s) being showcased. In the case of a MCU, all I/O pins may be easily accessible, while a minimum number of dedicated pins, like clock crystal lines or power, may be fixed. The accessibility of these pins can allow the initial concept of your product to be tested before creating dedicated PCBs. Development systems usually have full external programming and debugging capabilities.
* Evaluation or Experimenter Kit – As suggested, this kit’s function would be to evaluate the highlighted part or perhaps a particular feature (i.e. touch pad), but with limited functionality. The kit includes some method for programming through JTag, RS232 serial or USB ports. The latter 2 methods may require some internal resources that reduce the functionality to the developer. Not intended for product development.
* Demo Kit – Demo kit’s sole purpose is to demonstrate one or more of the highlighted part’s features. The evaluator has little he can do besides push a button, turn a knob or view a display. A touch panel slider with an LED array would be an example.
Some kits cross the line in some areas. A demo board may include some programming functionality through an external port, but this does not make it a development kit. These boards normally are more restrictive in access to certain system lines because these lines are being used to demo or eval a feature. For our DK board the LCD display lines are used for the demo and therefore not available for developing an application.
So, what does this mean for the STEVAL-STWINBX1 Discovery kit? The User manual states that the DK is a “complete demonstration AND development platform”, which the later may be a little bit of a stretch. I would label it more as an evaluation/reference design kit, but open to further discussion.
But let’s get back to “What is the STEVAL-STWINBX1”? And again, the main component of the STWIN.box is the STWBXCS1 (see the following block diagram) and is broken up into 3 functional subsections:
1)Sensing, 2) Processing & Connectivity, 3) Power Management & Protection
STEVAL- STWBXCS1 Overall Block Diagram -
STEVAL- STWBXCS1 Sensing Functional Block -
As a reference design the STWIN.box is loaded with nine (9) sensing related components interfacing to the MCU through a combination of 4 different interface ports: I2C2, SPI2, ADC1 and ADF (Audio Digital Filter), as show in the following sensing block diagram.
STEVAL-STWBXCS1 Sensing Block Diagram (Courtesy of STMicroelectronics)
The next 2 figures show the placement of each sensor component on the main broad.
STEVAL- STWBXCS1 Processing and Connectivity Functional Block -
Again, as a reference design the STWIN.box is loaded with multiple channels to communicate to and from the MCU, including a RS485 serial port, USB-C, MicroSD card, BLE, Wi-Fi and NFC (Near Field Communication) using interface ports: I2C1/2, SPI1/3 and USART2 as show in the following Processing and Connectivity block diagram. Also in this section is reference to the authentication and data security components. For component placement for this section, please see the User Manual.
STEVAL-STWBXCS1 Processing and Connectivity Block Diagram (Courtesy of STMicroelectronics)
STEVAL- STWBXCS1 Power Management & Protection Functional Block -
Per the user’s manual, the STWIN.box core system board includes a wide range of power management features that enable very low power consumption in final applications. The main supply is a lithium-ion polymer battery (3.7 V, 480 mAh) and the integrated battery charger (STBC02) with VIN from 4.8 to 5.5 V. Also included in this section is references to environmental protection devices (i.e. ESD, voltage suppression, etc.). For component placement for this section, please see the User Manual.
STEVAL-STWBXCS1 Power Management & Protection Block Diagram (Courtesy of STMicroelectronics)
Power management ICs –
U1: EMIF06-MSD02N16 six-line IPAD, EMI filter and ESD protection
U10: LDLN025PU275R, 250 mA ultra-low noise LDO
U16, U19: ST1PS02CQ, 400 mA synchronous step-down converter
U15: STBC02AJR Li-Ion linear battery charger
U22: TCPP01-M12, USB Type-C
port protection for Sink applications
U25: STEF05SGR, electronic fuse for 5 V line
Q1: STL6N3LLH6, N-channel 30 V, 6 A power MOSFET
Protections and connectors –
U17: USBLC6-2P6, low capacitance ESD protection for USB
D4: STPS120M, 20 V, 1 A STmite power Schottky rectifier
D6: ESDA25P35-1U1M, high-power transient voltage suppressor (TVS)
TVS1, TVS2, TVS3: ESDALC6V1-1M2, single line low capacitance Transil
TVS4: USBULC6-2M6, ultra large bandwidth ESD protection
J4: Battery connector
J5: 5 V external power supply connector
PWR: power button
STEVAL-STWBXCS1 Power Supply Block Diagram (Courtesy of STMicroelectronics)
Part Ic – What is the STM32 family and where does the STM32U585AI16Q fit in?
The STM32 is a family of 32-bit ARM Cortex-Mxx based microcontrollers (MCU). The family of MCUs is further divided into 4 functional area: High performance, Mainstream, Wireless and Ultra-Low power as shown in the following chart. The heart of the dev kit in this review (see highlight MCU) is part of the ultra-low power subfamily and includes a 160 MHz Cortex-M33 MCU intended for use in smart applications with some of the “most demanding power/performance requirements”, such as wearables, HMI, personal medical devices, home automation and industrial sensors”.
Courtesy of STMicroelectronics
The STM32U585AI devices are an ultra-low-power, high performance microcontrollers family (STM32U5 Series) based on the high-performance Arm® Cortex®-M33 32-bit RISC core. They operate at a frequency of up to 160 MHz.
* Includes ST state-of-the-art patented technology
* Ultra-low-power with FlexPowerControl
- Wide 1.71 V to 3.6 V power supply range
- Wide –40 °C to +85/125 °C operating temperature range
- Low-power background autonomous mode (LPBAM): autonomous peripherals w/ DMA, functional down to Stop 2 mode
- VBAT mode: supply for RTC, 32 x 32-bit backup registers and 2-Kbyte backup SRAM
- 160 nA Shutdown mode (24 wake-up pins)
- 210 nA Standby mode (24 wake-up pins)
- 530 nA Standby mode with RTC
- 1.9 μA Stop 3 mode with 16-Kbyte SRAM
- 4.3 µA Stop 3 mode with full SRAM
- 4.0 µA Stop 2 mode with 16-Kbyte SRAM
- 8.95 µA Stop 2 mode with full SRAM
- 19.5 μA/MHz Run mode @ 3.3 V
* Core
- Arm® 32-bit Cortex®-M33 CPU with TrustZone®, MPU, DSP, and FPU
* ART Accelerator
- 8-Kbyte instruction cache allowing 0-wait-state execution from flash and external memories: up to 160 MHz, 240 DMIPS
- 4-Kbyte data cache for external memories
* Power management
- Embedded regulator (LDO) and SMPS step-down converter supporting switch on-the-fly and voltage scaling
* Benchmarks
- 1.5 DMIPS/MHz (Drystone 2.1)
- 651 CoreMark® (4.07 CoreMark®/MHz)
- 450 ULPMark-CP
- 109 ULPMark-PP
- 51.5 ULPMark-CM
- 133000 SecureMark-TLS
* Memories
- 2-Mbyte flash memory with ECC, 2 banks read-while-write, including 512 Kbytes with 100 kcycles
- 786-Kbyte SRAM with ECC OFF or 722-Kbyte SRAM including up to 322-Kbyte SRAM with ECC ON
- External memory interface supporting SRAM, PSRAM, NOR, NAND, and FRAM memories
- 2 Octo-SPI memory interfaces
* Security and cryptography
- SESIP3 and PSA Level 3 Certified Assurance Target
- Arm® TrustZone® and securable I/Os, memories, and peripherals
- Flexible life cycle scheme with RDP and password protected debug
- Root of trust thanks to unique boot entry and secure hide protection area (HDP)
- Secure firmware installation (SFI) thanks to embedded root secure services (RSS)
- Secure data storage with hardware unique key (HUK)
- Secure firmware upgrade support with TF-M
- 2 AES coprocessors including one with DPA resistance
- Public key accelerator, DPA resistant
- On-the-fly decryption of Octo-SPI external memories
- HASH hardware accelerator
- True random number generator, NIST SP800-90B compliant
- 96-bit unique ID
- 512-byte OTP (one-time programmable)
- Active tampers
* Clock management
- 4 to 50 MHz crystal oscillator
- 32 kHz crystal oscillator for RTC (LSE)
- Internal 16 MHz factory-trimmed RC (±1%)
- Internal low-power 32 kHz RC (±5%)
- 2 internal multispeed 100 kHz to 48 MHz oscillators, including one auto-trimmed by LSE (better than ±0.25% accuracy)
- Internal 48 MHz with clock recovery
- 3 PLLs for system clock, USB, audio, ADC
* General-purpose input/outputs
- Up to 136 fast I/Os with interrupt capability most 5V-tolerant & up to 14 I/Os w/ independent supply down to 1.08 V
* Up to 17 timers and 2 watchdogs
- 2 16-bit advanced motor-control, 4 32-bit, 5 16-bit, 4 low-power 16-bit (available in Stop mode), 2 SysTick timers and 2 watchdogs
- RTC with hardware calendar and calibration
* Up to 22 communication peripherals
- 1 USB Type-C®/USB power delivery controller
- 1 USB OTG 2.0 full-speed controller
- 2 SAIs (Serial Audio Interface)
- 4 I2C FM+(1 Mbit/s), SMBus/PMBus®
- 6 U(S)ART (SPI, ISO 7816, LIN, IrDA, modem)
- 3 SPI (Serial Peripheral Interface) {+2 with OCTOSPI +3 with USART}
- 1 CAN FD controller
- 2 SDMMC interfaces
- 1 multifunction digital filter (6 filters) + 1 audio digital filter with sound-activity detection
- Parallel synchronous slave interface
* 16- and 4-channel DMA controllers, functional in Stop mode
* Graphic features
- Chrom-ART Accelerator (DMA2D) for enhanced graphic content creation
- 1 digital camera interface
* Mathematical coprocessor
- CORDIC for trigonometric functions acceleration
- Filter mathematical accelerator (FMAC)
* Up to 22 capacitive sensing channels
- Support touch key, linear, and rotary touch sensors
* Rich analog peripherals (independent supply)
- 14-bit ADC 2.5-Msps with hardware oversampling
- 12-bit ADC 2.5-Msps, with hardware oversampling, autonomous in Stop 2 mode
- 2 12-bit DAC, low-power sample and hold
- 2 operational amplifiers with built-in PGA
- 2 ultra-low-power comparators
* CRC calculation unit
* Debug
- Development support: serial-wire debug (SWD), JTAG, Embedded Trace Macrocell (ETM)
* ECOPACK2 compliant packages
Part II – The Unpacking: 8^)
Welcome to the unpacking and our first look at the actual STWIN.box. I have read many different views on the value and/or importance of the unpacking segment, but I feel it is important because it is often our first glimpse into what to expect in the product and support. I’m excited to road test this kit, not just because of STM’s expertise and extensive experience in the field of low power ARM-Cortex MCUs, but they’ve packed (no pun intended) so much unto the board.
The dev kit arrived in a puffy envelope, yet undamaged due to the internal plastic case.
NOTE: The QR codes on the back of the plastic case are links to Apple and Android supporting apps. No other website links are shown for the kit documentation or operation other than the main www.st.com link. However, this not unusual as we have all seen with every dev/eval/demo kit produced for the last 10 years, all documentations are available only through download. And as you can see from the Useful Documents Links section, there is no shortage of supporting documents.
The back of the plastic case had the following labels. NOTE: “Reference Design Board” label.
The shipping envelope also included the following stickers 8^).
The contents of the kit are shown below (Courtesy of STMicroelectronics):
Part III – Assembling the STWIN.box:
Unlike most evaluation board, the STWIN.box needs a little assembly before turning it on. Most likely driven by the LiPo battery safety requirement. However, assembly is straight forward with the exception of the battery installation. I had not used the Molex Pico-EZmate power connectors before, and it was not intuitive on how to mate the connectors. Since there is no example or instructions on what to expect from powering up the STWIN.box, I spent a little longer than expected trying to communicate with the box that wasn’t really powered up. It turns out the connector was not fully seated and needed a little more forcefulness to mate. It looked seated, even using my magnifying glass, but I didn’t want to break the connector on the first try. Thanks to Molex’s website.
Another issue related to the battery connector is the removal. Again, not the easiest of tasks, but there is not physical power switch to disconnect power to the board, so the battery needs to be removed before modifying the board, but I wasn’t careful enough even with Molex’s website instructions. In trying to remove the battery, I also removed the PCB pads. OOPS!! To fix the damage I had to solder the battery wires to the PCB. Fortunately, there were battery test pads on the board. From the schematic, NTC thermistor temperature sensor (white wire) from the battery is connected to R17 on the top side of the board (not shown).
Finally, well maybe I shouldn’t say that yet, aside for the USB C port and the DIL24 interface cable slot, the only way to access the board is by removing the cover, held on by 5 screws. If you are using a MicroSD card to log your data, you must remove the cover to access the port.
NOTE: The USB interface port is type “C” and a cable was not included in the kit, however I probably only have a couple dozen lying around anyway. Other items that would be needed to fully test the board includes a MicroSD card for standalone data logging and a DIL24 board to check for an external sensor. Aside from the USB port, there are other debugging configurations that would need other external connection that are mentioned in the user manual.
Part IV – Connecting and Powering Up the Kit (or Now for the fun stuff):
At this time, I normally power up the kit to get a feel for whether the unit will show any sign of life. As mentioned earlier, the user manual gives very little information as to what to expect. NOTE: The box may be power through multiple different sources, but may require some PCB modification, so my initial and follow-up tests will use the USB-C connector as the power supply source.
The box has 3 LEDs. The red LED (LED_C1) indicates the battery charging state. During charging this LED is flashing and is driven by the battery charging IC, U15. The green LED (LED1) indicates the state of BLE connectivity. While the box is searching for a BLE connection the LED will flash and driven by the main MCU (STM32U585). Also driven by the main MCU, the orange LED (LED2) indicates a user input.
The initial powered on status is flashing red (battery charging), flashing green (scanning for BLE) and off orange LEDs.
NOTE: The expected battery life with a full charge can vary based on the sensor and connectivity configuration. However, with the box powered on, but not connected to BLE, the battery will last about a day.
So, let’s move on to software installations and setup.
Part Va - Software Installation – Android Apps:
NOTE: My smartphone is a Samsung Galaxy A15 5G run Android 15
The QR code on the back of the plastic shipping package will take you to the Google Play store link for the ST BLE Sensor app. Of course, your smartphone must support BLE and NFC.
ST BLE Sensor installation screenshots -
NOTE: Pay no attention to the ST BLE Toolbox icon. I loaded it to see what it does, but hadn’t got a chance to explore it yet and it is not referenced in the user manual. 8^)
Open ST BLE Sensor –
The 1st screen upon opening the app is to set your “level of proficiency”. The choice is between beginner and expert. I initialing choose beginner but later switched to expert because the program limits the program functionality under beginner. Press [NEXT]
Screen 2 sets your profile selection. Again, each catalog has its own limitation, so I choose Firmware Developer for the most flexibility. Press [Done]
Next the BLE permissions needs to be set –
Press “While using the app” twice and finally “Allow”. 
The STWIN.box (BLEDfFW) should appear on your smartphone running the BLE default firmware v1.4.0. NOTE: the default FW is loaded in Bank 1. There are 2 FW banks for remote updates that can be swapped during operation.
For your initial BLE connection, the app will request pairing. Enter the default pin is “123456”, then press “Pair”. But before that let’s look at the options (3 dots) in the upper righthand side of the screen. And sadly, as I’m growing to expect no more information or instructions beyond what is intuitively given. Many of the options are informational licenses details, but the “CHANGE PROFILE” option allows you to change from the “beginner” to “expert” profile. Very helpful if you didn’t set expert mode at installation. “APPLICATION SOURCE CODE” is a link to the app source code on GitHub. I have no clue what “FORCE AUDIO SERVER” does. 8^(
That’s it! You’re connected!
But wait, there’s more. The app checked the STM website and detected that my STWIN.box firmware had an update available and asked if I wanted to download and update over-the-air. I answered yes and a couple moments later I had v2.0.0. NOTE: The firmware is now running out of Bank 2, the old firmware is still in bank 1 (for now).
And just before finishing this review, as I was connecting to the board, I received this message. No change list, but I still updated my box. Not visible changes.
The final “Connected Board” –
NOTE: The “greyed” icons are due to a combination of being in the “beginner” profile and having to log into STM’s website.
More about navigating the app pages later.
Part Vb - Software Installation – Windows Apps:
NOTE: My laptop is a Windows 11 Pro, 11th Gen Intel(R) Core (TM) i5-1135G7 @ 2.40GHz 2.42 GHz, 16 GB
The only software mentioned in the user manual is the STM32CubeProgrammer found in Section 3. The programmer uses the USB C port of the STWIN.box for updating and debugging the board. You can install the programmer software from the link shown in the “Useful Documents Links” section of this review.
For my laptop the install file is SetupSTM32CubeProgrammer_win64.exe and running the file produces the following 9 steps:
And finally …
Click on the STM32Cube Programmer Icon 
to launch the app. The first screen is a note of caution about your usage being shared but quickly transitions to the program’s “Memory & file editing” page. This seems to be the default home page with all the default setting.
The upper left-hand section in the app shows what functionality block the program is in.
Change the device interface to USB then press [Connect]
Wait what’s this
This is where the User manual does help, because the STWIN.box boots in operational mode and must be changed to Device Firmware Update (DFU) mode, as shown in the Device Manager.
NOTE: After switching to DFU mode the STM32CubeProgrammer must be restarted.
Now clicking on [Connect] will trigger a read of the STWIN.box current firmware memory bank:
But this is a programming tool, so what about downloading a different firmware. First you need a .hex or .bin file to download. Of course, you can use the STM32CubeIDE (or Visual Studio Code) to create and compile a program file, but STM has made it sort of easy to grab a set of demo programs from their FP-SNS-STBOX1 Function Pack (fp-sns-stbox1-main.zip). You just have to find the file on their GitHub website. Check the Useful Documents Links section.
Once you download the file, unzip it into a convenient directory. The demo apps can be found in the ../projects/STEVAL-STWINBX1/Applications directory. The factory installed default program for the STWIN.box is in the BLEDefaultFW directory. Along with the .bin file, the project’s application directory also contents the STM32CubeIDE project files.
Now back to the Programmer –
Once you made connection to the board, click on the [Erase and programming] icon on the left side of the screen, enter the file path to the .bin or .hex file, then press [Start Programming]. The process status is shown on the bar at the bottom of the screen.
To exit DFU mode and run the program, press the reset button on the STWIN.box.
Part VI – Testing the Apps and other observations -
With all the pieces in place, let’s see what we can try with the STWIN.box fully charged with default firmware (BLEDfFw) installed and the green connectivity LED flashing (i.e. waiting for pairing). Next, we start the ST BLE Sensor app on my Samsung Galaxy A15 5G smartphone (See “Part IVa - Software Installation – Android Apps”). The app should display your STWIN.box. Click on the box icon and complete the BLE pairing as instructed. The green LED should now be off and the ST BLE Sensor app should display as below. The gear icon in the upper righthand corner shows the options available in the “Connected Board” tab. As usual, no information or instructions beyond the intuitive is given. The “OPEN DEBUG CONSOLE” allows you to send a debug message, but to where is not clear. The “FIRMWARE UPDATE” asks you to select a file, but from where? If you don’t input a file, the app hangs and you must restart the app.
The subcomponents (i.e. Environmental, Plot Data, Board configuration, etc.) functionality is limited for many of the sensors included in the STWIN.box. For example, clicking the Environmental icon displays the temperature and pressure sensors real-time data, but the data logging feature (under the 3 dots Icon) doesn’t seem to work. And even through you can change the temperature units from Centigrade to Fahrenheit the change reverse back with the next icon click.
Under Plot Data, all 5 sensors options are displayed. Individual sensor readings can be selected by the drop-down menu. The [arrow] button starts the scan. The [tool box] drop-down gives you options for the duration of the scan & min/max/auto vertical scaling thru the Gearbox icon, a snapshot thru the [Camera] icon and the plot’s min/max reading (see lower right-hand corner) thru the [i] icon. Logging options are set under the 3 dots Icon.
Other Observations –
Logging is interesting because sometimes the app will record different numbers of plots while running a single sensor scan, but I’m still trying to figure it out. There is no option to review the log files on the ST BLE Sensor app, although under the “Clear Log” option the number of current log files is shown. If no data is available, you can still export the empty logs to your email.
Another unanswered question is the MicroSD card option. I read somewhere that you can log your data to an MicroSD card, but it’s not clear how to. Under the “Start Logging” option in the logging menu, it states the data will be sent to the “selected storage”, there no clear way to select another location/device. The default (and only) location is on the dev board itself. In addition, how large of log file will the board support?
And what about the onboard microphones. There doesn’t seem to be any reference designs apps or demos.
I noticed that the resolution of the temperature sensor’s data is 1 degree C. This seems to be a waste of the 16-bit temperature sensor. The sample time for most measurements is 50ms.
EXTRA #1-
I was able to load the BLEDefaultfw source code into the STM32Cube IDE and even compile it, but ran out of time on trying to wrap my head around the software functionality. The code comments varied greatly from segment to segment.
EXTRA #2-
Another option for compiling and downloading a program to the STWIN.box is thru an external debugger using the STM IDE. In the example below, I used the built-in STLink debugger on a STM32F401 Nucleo-64 dev board as shown in the user’s manual. The Nucleo board connects to my laptop running the STM32CubeIDE.
NOTE: I must admit, I’m still trying to get this to work 8^(
I started by installing STMCubeIDE, using the default settings, without an issue. My PC found the board through the Device manager.
Using the demo code found in the previous mentioned .zip file, I was able to successfully build the code but still working on downloading thru the Nucleo board. Still really curious!
What I didn’t try (much) and what’s next
* I didn’t get around to trying the external DIL24 adapter. I have a STEVAL-MKI228KA pressure sensor. Maybe soon.
* I didn’t make any current measurements because of the battery connector issues mentioned earlier.
* I didn’t try any other wireless interfaces other than BLE. I couldn’t find any demos.
* Is there a demo program that uses the onboard microphones?
* I wonder how this would work out on Visual Studio Code?
* Too many choices. My head is starting to hurt 8^).
Please let me know if I missed something in my review or if you have any questions. Also please pardon my typos.
Gordon Margulieux
Twin Falls, ID USA
