1
\$\begingroup\$

I have this infra-red oximeter and it is based on STM32F030C8T6 and its PCB has pin headers place labeled as RST,VCC,DIO,CLK,GND and RX0,TX0 as shown in photo.
Is it possible to grub the main code or any way to communicate with it , note I don't have ST-link. enter image description here

\$\endgroup\$
2
  • 2
    \$\begingroup\$ There is a slight change but you'd need an SWD adapter. And if you had the binary image, what next? For communication you might always luck out and find out it was outputting readings or debug messages containing them on a logic level serial port. That at least is worth probing with a scope or just trying a bunch of baud rates. \$\endgroup\$
    – Chris Stratton
    Commented May 21, 2020 at 6:11
  • 1
    \$\begingroup\$ and an stlink v2 clone costs literal single-digit euros, so get one. \$\endgroup\$
    – Marcus Müller
    Commented May 21, 2020 at 8:31

2 Answers 2

Reset to default
2
\$\begingroup\$

For sure the manufacturer has enabled readout-protection, so you're not getting their binary code by simply attaching an ST-Link to it. You could erase the chip but then you'd have a blank chip and that's not much good without a lot of knowledge, a schematic and so on.

There might be something useful on the serial port, with the aid of suitable tools you could see what, if anything, is coming out of it. Something like a USB-TTL module on RxD and TxD. It's possible it only spits out data in response to a query, in which case you might have more trouble getting anything out of it. With luck there's a boot message in something like 9600-n-1 (or maybe a higher baud rate) that at least lets you read some hello world thing and get the baud rate correct, then you could try sending it a or whatever and see if it responds.

The other clock and data, I'm guessing is SPI data to the display, but I could be wrong about that.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ STM32 RDP is broken. blog.zapb.de/stm32f1-exceptional-failure \$\endgroup\$
    – Jeroen3
    Commented May 28, 2020 at 7:27
  • \$\begingroup\$ @Jeroen3 Thanks. That's.. unfortunate- though most MCU code protection schemes are 100% breakable by experts with a bit of equipment. \$\endgroup\$
    – Spehro 'speff' Pefhany
    Commented May 28, 2020 at 21:43
0
\$\begingroup\$

There seem to be three (!) different serial buses exposed via the tinned but unpopulated pin header holes on the left. Start probing these with a logic analyzer. They are meant for communication, so chances are the firmware actually does do something with them.

Getting the firmware of the device wouldn't help you much with communicating with the device, otherwise: if the firmware doesn't communicate with anything, then that's it – your only chance would be to modify or reimplement the firmware, and I'm not quite convinced of the idea of modifying sensor firmware without knowing how to calibrate the device.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.