What communication is this? Uart or I2C? Or something else?

[LooseJunkHater]

This is a post related to this project.

I'm trying to figure out the type of communication-style being used for the 1st generation Awair air quality monitor, between the LED display (using an STM32F103 64-pin, to drive an array of LED's) and the main MCU (STM32F103 100-pin). To view images of what these boards look like, click here. The 100p STM32 main MCU board is on page 2 & 3, while the 64p STM32 board is on page 6.

The 100p STM32 is transmitting data on the PB10 pin (pin 47, which also supports I2C2_SCL , USART3_TX , TIM2_CH3), while the 64p STM32 is receiving data on the PA3 pin (which also supports USART2_RX , TIM5_CH4 , ADC123_IN3 , TIM2_CH4). Attached are various photos of what the data looks like.

All captured packets = image 14-16
Packet 1 = images 17-23.

____________________________________________________________________________________________

I tried using a FTDI UART board to read the data, using BAUD rates 9600, 115200, 19200, 38400, 57500, 57600, 230400, but nothing was human-readable when using PUTTY.

[LooseJunkHater]

Just a few more images, in case they're helpful at all.

One last image of packet 1: image 24
Packet 2 (very similar to packet 1): image 25
Packet 3: images 26-33

[inse]

Two questions in return:
- is there only one communication line between the two micros? If yes, it can be only UART as the HW pinout implicates already (unless anyone would implement it‘s own interface).
- why do you expect the communication to be human readable?
Posting screenshots makes little sense as we would not have any context…
P.S. 115200 bps gives ~8,7us bit timing

[LooseJunkHater]

Two questions in return:
- is there only one communication line between the two micros? If yes, it can be only UART as the HW pinout implicates already (unless anyone would implement it‘s own interface).
- why do you expect the communication to be human readable?
Posting screenshots makes little sense as we would not have any context…

I expected the communication to be human readable because there's actually another UART connection on the board (first image attached, green points at it). With my FTDI UART adapter, I can actually send/receive (basic) commands & information (second image). All it can seemingly do is control a single multi-coloured LED on the board. I don't think the UART connection has any role in controlling the LED display, because it doesn't actually connect to the primary 100p STM32F MCU.

P.S. 115200 bps gives ~8,7us bit timing

How did you determine that? Which screenshot helped with that? Additionally, knowing the BAUD rate, is there any way that I can decrypt/interpret the data or communication protocol? I'd love to be able to send my own custom commands to the LED display via an ESP32/arduino.

[StrayElectrons]

I2C is two pin communication type in general.    Clock on one pin and serial data on another pin.

If more than that, that's not I2C.   IIRC.

Cheers,

[inse]

You confuse me:
„between the LED display (using an STM32F103 64-pin, to drive an array of LED's) and the main MCU (STM32F103 100-pin)“
„I don't think the UART connection has any role in controlling the LED display, because it doesn't actually connect to the primary 100p STM32F MCU.“

I‘d say it depends on the implementation or the used framework or simply the efficiency whether it is plain text or pure bitstream.
I work in automotive electronics development and have to deal with communication from high level down to bit shoving.

You measured the bit duration several times, eg 5th screen shot, I did the math 1/115200

To decode the protocol you would need to analyze which packet causes which reaction on the display.
I wish you a lot of fun doing so and keep asking if it’s really worth it.

[LooseJunkHater]

You confuse me:
„between the LED display (using an STM32F103 64-pin, to drive an array of LED's) and the main MCU (STM32F103 100-pin)“
„I don't think the UART connection has any role in controlling the LED display, because it doesn't actually connect to the primary 100p STM32F MCU.“

There's actually multiple communication lines going to that LED display PCB, which is kinda hard to see in the image, but are labelled in red, on the 10pin connector.

- 2x pins for UART (Tx/Rx); those are the pads that I showed in the previous image with a green arrow. While they do go to the 10pin connector, there are unpopulated resistors on the main MCU board, therefore, do not have any role in communication with the main MCU
- SDA + SCL for the temp/humidity sensor
- 2x pins (which are the ones in regards to this post), which I'm assuming at UART TX/RX, but I'm not 100% sure, hence this whole post. I guess I could hook up my scope to *both* of these pins and see whether there's data on both pins, or just one?

Then there's 2x pins for 3.3v/ground, one pin which connects to "NRST" (Pin 7) of the 64-pin STM32 MCU, and then a final pin which connects to an unknown I.C on the board.

I‘d say it depends on the implementation or the used framework or simply the efficiency whether it is plain text or pure bitstream.

How can I determine whether it's plain text or "pure bitstream" (whatever this means?). I'd assume there's probably a YouTube video on this, or maybe a post on the EEVBlog? I'm just not 100% sure what I'd need to search up.

I work in automotive electronics development and have to deal with communication from high level down to bit shoving.

You measured the bit duration several times, eg 5th screen shot, I did the math 1/115200

To decode the protocol you would need to analyze which packet causes which reaction on the display.
I wish you a lot of fun doing so and keep asking if it’s really worth it.

Is decoding the protocol + packet analyzation something that is generally difficult to do? Would I be able to use an ESP32/Arduino to simply send an identical packet (as I recorded with my oscilloscope) to see what happens?

Additionally on my Siglent oscilloscope, it gives the options for me to specify "Data length" (values between 5-8), "Parity check" (none, odd, even, mark, space), "Stop bit" (1, 1.5, 2), "Idle level" (low, high), and "Bit Order" (LSB, MSB). I have no idea what any of these are, but are they easy to determine based on the images I have provided. Further, will knowing these aspects of UART be required if I were to send data with an ESP32/Arduino?

[pcprogrammer]

Is decoding the protocol + packet analyzation something that is generally difficult to do?

It depends on a lot of factors. When it is pure binary it becomes more difficult. You have to figure out what every bit means, determine packet length, see if it repeats regularly, etc.

Would I be able to use an ESP32/Arduino to simply send an identical packet (as I recorded with my oscilloscope) to see what happens?

What you can do is record the bit stream as is and play that back, like an audio sampler would do, but in this case sampling digital data. This way you don't have to think about UART settings.

Additionally on my Siglent oscilloscope, it gives the options for me to specify "Data length" (values between 5-8), "Parity check" (none, odd, even, mark, space), "Stop bit" (1, 1.5, 2), "Idle level" (low, high), and "Bit Order" (LSB, MSB). I have no idea what any of these are, but are they easy to determine based on the images I have provided.

Based on this my advice is to first look into serial communication. Here is a link to a simple explanation: https://learn.sparkfun.com/tutorials/serial-communication/wiring-and-hardware

Further, will knowing these aspects of UART be required if I were to send data with an ESP32/Arduino?

Yes you need to know about those aspects to program the UART in the ESP32 correctly. Chances are that the programmer of your device just used the basic high idle, lsb first, 8 bit, no parity, one stop bit setup. It depends on the specific UART if the idle level and bit order can even be set. The STM32F103 only supports 8 or 9 bit data length.

See the STM32F103 reference manual for details on this: https://www.st.com/resource/en/reference_manual/rm0008-stm32f101xx-stm32f102xx-stm32f103xx-stm32f105xx-and-stm32f107xx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

[mikerj]

I can almost guarantee this will not be an ASCII protocol. For low speed data transmission between two micros within a device, a binary protocol is easier and more efficient (i.e. less overhead).  Reverse engineering these protocols is time consuming, you will need to log numerous different data packet as well as the value it produces on the LED display and find the link between them.  There may well be a checksum/CRC of some kind in the packet which you'd also need to reverse engineer.

[inse]

As the others agree as well and you are posting your question in the beginners section: it’s maybe a little too complicated for a beginner.
In contrast to the Dymo hack, there is also probably no widespread interest in supporting this project.
If you want to pursue on your own: best of luck

[LooseJunkHater]

I ended up using my oscilloscope on both the 100P STM32 TX --> 64P STM32 RX, as well as the 100P STM32 RX --> 64P STM32 TX pins (the ones that DID NOT have UARD human-readable data). Oddly, they both had the exact same data (which I don't think is expected from UART?). All of the 1's and 0's lined up perfectly between the TX + RX pins. This leads me to believe that the communication between the 100P STM32 + 64P STM32 is not I2C, so I guess that answers the main question of this thread.

In regards to the actual communication between those two MCU's, I'd imagine that the data stream is telling the LED display to flash a blue LED, as well as to display the word "PAIR" on the LED display and move it horizontally, because when simply providing 3.3v + GND to the LED display, this does not occur. 

Based on the comments in this thread, as well as the reading on UART that I've done, it does seem like this may be too difficult for me to complete, so I think I'll probably be ending it here sadly. I think I'd be needing a proper logic analyzer to go much further, to more-easily capture + process the data stream. It seems like there's various commands that can be sent to this LED display (such as to move words horizontally, instead of statically keeping words on the display), which would make this very difficult for me to try to reverse-engineer, as a beginner.

_______________________________________________________________________

Unless someone smarter than me actually sees the word "PAIR" (in binary, hex, ASCI, whatever) within any of the 3 data packets I posted earlier, this is the end. I personally did not see it, but again, I'm only just learning about UART.

[pcprogrammer]

Maybe a somewhat easier way to find what you want to know is to see if it is possible to read the FLASH of the two STM32F103 MCU's. Check if there is a way to connect SWD (from a ST link v2 clone) and use openocd to read the code.

The code can be examined with Ghidra.

[LooseJunkHater]

Maybe a somewhat easier way to find what you want to know is to see if it is possible to read the FLASH of the two STM32F103 MCU's. Check if there is a way to connect SWD (from a ST link v2 clone) and use openocd to read the code.

The code can be examined with Ghidra.

The idea of reading the flash of both STM32's was briefly brought up in this thread of mine, related to this same project. Both STM32's have internal flash storage, and I was under the impression that it's likely that the information stored within is unlikely to be human-readable?

How would I dump the STM32F103 firmware? Doing some research, there appears to be a way to do it if it's marked as "protected" using the STLink tool, but I'm wondering if there's other ways to do it, such as using an FTDI adapter or XGecu T48 universal programmer?


__________________________________________________________________

Edit:

Looks like I sadly do need the STLink. Guess I may end up getting a logic analyzer + an ST Link........

[pcprogrammer]

The idea of reading the flash of both STM32's was briefly brought up in this thread of mine, related to this same project. Both STM32's have internal flash storage, and I was under the impression that it's likely that the information stored within is unlikely to be human-readable?

The code in the FLASH is in binary, but with a disassembler like Ghidra it can be turned into readable assembler, and even better readable psuedo C code. But it takes some experience to figure out how things work within the code. But starting from the reset vector gets you a long way.

How would I dump the STM32F103 firmware? Doing some research, there appears to be a way to do it if it's marked as "protected" using the STLink tool, but I'm wondering if there's other ways to do it, such as using an FTDI adapter or XGecu T48 universal programmer?

Not sure if the code can be read with an USB to serial adapter, when booted into system memory. (Boot 0 pin active) It can be used to program it for sure.

If it is protected things get more difficult and I have no experience with it, but others on the forum do.

With a ST Link and openocd it is a question of starting openocd with a STM32F103 config file and dump the memory.
https://openocd.org/doc-release/html/Flash-Commands.html
https://openocd.org/doc-release/html/General-Commands.html#memoryaccess

Attached is a config file for a STM32F103C8T6. ".txt" is added to allow it to be attached here. Change the chip name in the file to what your target is and start openocd. Below command is what I use on Linux Mint, but assume it is more or less the same on Windows.

Code: [Select]

openocd -f STM32F103C8T6.cfg


Looks like I sadly do need the STLink. Guess I may end up getting a logic analyzer + an ST Link........

You can get cheap clones that work perfectly fine on Aliexpres:
https://www.aliexpress.com/item/1005006160511992.html
https://www.aliexpress.com/item/1005007112122595.html

I have multiples of the ST Link from Aliexpress and have not had problems with them yet.

Also have a clone logic analyzer, and that also works fine. Signals up to ~12MHz can be checked.

[mwb1100]

If you can get openocd (or whatever debugger) to read the flash, you should be able to get the debugger to read out the UART registers - that will at least tell you exactly how it is configured.

Then you can make sure your oscilloscope or logic analyzer is set up to decode properly.  Then you can reverse engineer whatever protocol is being used using either the technique mentioned earlier by @mikerj or possibly by groveling through a Ghidra disassembly (or C-pseudo code generation).  Or using a combination of those techniques.

[LooseJunkHater]

I guess this thread isn't completely over yet. I'll be ordering the STLink clone + either buying a cheap $10 20MHz logic analyzer, or follow this project, with accompanying video, to make this "400MHz" logic analyzer, based on the Raspberry Pi Pico2.

I'll update this thread when I have more information. Thank you all for the help!

[abeyer]

I'll update this thread when I have more information. Thank you all for the help!

That's the trick, just keep providing updates, answering questions, and performing experiments suggested... it won't matter your level of experience, as you'll nerd snipe someone here into solving it with you. 

[LooseJunkHater]

Small update, I now have the STLink V2 in-hand. It's one which have the pins "RST", "SWCLK", "SWIM", and "SWDIO" available (alongside GND, 3.3v, 5v).

I tried looking into the datasheets of both the STLink V2 and STM32F103, as well as Googling around, but I'm not entirely sure how to wire/connect them both together. I'm wondering if someone who has experience with using the STLink and programming STM32's knows?

Thanks!

[mikerj]

SWIM is an ST proprietary single wire interface, it's not available on the F103.

For a 64 pin F103:
SWDIO Pin 34 (PA13)
SWCLK Pin 37 (PA14)
NRST    Pin 7
The "VAPP" pin on the ST-Link should be connected to the micro VDD supply rail (typically 3.3v).  This doesn't power the micro, it sense the voltage to set the logic levels on the signal pins.

[LooseJunkHater]

SWIM is an ST proprietary single wire interface, it's not available on the F103.

For a 64 pin F103:
SWDIO Pin 34 (PA13)
SWCLK Pin 37 (PA14)
NRST    Pin 7
The "VAPP" pin on the ST-Link should be connected to the micro VDD supply rail (typically 3.3v).  This doesn't power the micro, it sense the voltage to set the logic levels on the signal pins.

Maybe I'm looking at a different STM32F103 datasheet, but for the 64pin STM32F103, I thought PA13 = pin 46, and then PA14 = pin 49?

Additionally, this is the STLink V2 that I have, and I don't see a "VAPP" pin? Did I maybe buy the wrong ST Link?

[pcprogrammer]

What you bought is a clone. Should work just fine though. I have several of these, and have not had problems with them so far.

On a blue pill with a STM32F103, I only connect the GND,  SWCLK and SWDIO, and use openocd to do the programming. Without the reset line connected it does mean that at times I need to reset the mcu after openocd had an error after erasing the flash and run the programming again. Not a big deal and has to do with the mcu being in an interrupt state.

The pins 34 and 37 are used on the 48 pin devices, 46 and 49 are on the 64 pin devices. But on the blue pill there is a separate 4 pin header for the connections.

When you also connect the 3.3V to the target it will supply the MCU, and in this case make sure not to connect the USB port of the blue pill to a computer or power supply.

[LooseJunkHater]

Here is a folder with various BIN's of the STM32F103 "64p" (64 pin) and "100p" (100 pin) variants.

In the folder, you'll find two files called "100p Firmware Dump". Those are just straight dumps using the default settings of the STLink, but I think the dumps are actually incomplete. My naming scheme afterward changed.

Within STLink, I noticed that both MCU's have the addresses "0x08000000" and "0x00000000" that show, so I downloaded the firmware for both. Additionally, it seems like the default "size" (memory size?) within STLink was incomplete, so I included multiple different sizes, as listed.

_______________________________________________________

Also, I accidentally fed 12v into the VCC 3.3v line of the ST32F103 64p. I know I killed the 64p STM32, but I probably also killed the temp/humidity sensor as it's also connected to 3.3v. I *think* the 100p STM32 and other devices lived.

I'm now need to try to find an STM32F103 64p variant in my spare parts bin, and see if I can somehow flash it with the extracted firmware.

Hopefully the extracted firmwares can help others to extract the API key or understand how the 100p STM32 is sending commands to the 64p STM32 to text to the LED display.

[pcprogrammer]

Within STLink, I noticed that both MCU's have the addresses "0x08000000" and "0x00000000" that show, so I downloaded the firmware for both. Additionally, it seems like the default "size" (memory size?) within STLink was incomplete, so I included multiple different sizes, as listed.

The FLASH is located at 0x0800000, but is aliased to address 0x00000000 because that is where the core starts from. Depending on the boot pin settings address 0x00000000 represents either the FLASH or the system memory. You just need the data from address 0x08000000.

Also, I accidentally fed 12v into the VCC 3.3v line of the ST32F103 64p. I know I killed the 64p STM32, but I probably also killed the temp/humidity sensor as it's also connected to 3.3v. I *think* the 100p STM32 and other devices lived.

I'm now need to try to find an STM32F103 64p variant in my spare parts bin, and see if I can somehow flash it with the extracted firmware.

Ouch, that is a bummer. 

[DavidAlfa]

Seems definitely uart, I had a peek in Ghidra and it's using it.