Flashing STM32 with USART over audio

[thesame]

Hello everyone. I bought Blue Pill dev board based on STM32F103 in order to do some experiments. Now I realized I have neither ST-LINK nor usb-to-serial converter and it would be very inconvenient to make a ride to the store to buy one. That's why I thought I could flash the board with just my laptop's audio jack. I was inspired by the people who already did similar things: https://davidawehr.com/blog/audioserial/ https://hackaday.io/project/4926-cheepit-sparrow-dev-boards-for-smartphones/details https://sudoroom.org/serial-over-webaudio/

I'm trying to design a schematic diagram of audio-to-usart converter for this project and I was hoping somebody could point me to errors.

I used a multimeter and measured AC voltage of laptop sound output. It gave me about 1.4 Volts and I make an assumption that peak-to-peak voltage would be +-2 Volts. More than enough for switching a transistor.
I also measured microphone input and it gave me 5 Volts of DC bias.

The board is connected (and powered by) to the laptop with USB cable. 3.3 Volts is generated on the board. RX and TX are connected to the STM32 board and MIC and SPK are connected to the laptop audio jack.

The general question is: what am I missing?

[thm_w]

You are going to want a USB->Serial or a STlink at some point, pony up the $2 for it and save the hassle.

Another option is if you have a standard RS232 port you could convert that into lower TTL voltage levels:
http://picprojects.org.uk/projects/simpleSIO/ssio.htm

[thesame]

That's a good point! But buying the adapter is much more boring option than building one. I think at first it's enough to be able to flash the chip and then connect to it with native usb.
I'd like to start with the audio flashing and if it fails go the adapter path. Do you think the schematic I drawn could burn laptop audio i/o or stm32?

[thm_w]

I assume you don't have an oscilloscope to check the output waveform right?
Do you have any arduino boards or anything with a USB/232 converter already built into it?

Not sure if that circuit would work or not.

[thesame]

If I had something with usb/serial converter this topic wouldn't exist. Unfortunately I have no oscilloscope either.

In the circuit I assume that the positive half-wave of the audio output saturates the transistor and pushes down the RX line to the ground giving 0. Negative half-wave on the other hand cuts off the transistor producing 1 to the RX. As far as I can tell 2400 or 9600 baud rate more or less fits the audio bandwidth.

TX line is just received by microphone input and processed by software DSP.

[aheid]

I mean you can easily test that it works by simply connecting TX with RX, and verify that what you send is whay you receive.

I'd write a small program in Python or whatever to send byte patterns and verify.

Without a scope or logic analyzer it'll be difficult to debug the circuit though.

[ebclr]

What's  the point ?

Waste a lot of your time, to reivent the well to save 2 bucks, and have a horrible performance ?

This is a total nonsense,  nothing is easier than buy < 2 USD converter , or even use one arduino,

[mark03]

No matter how good the audio-serial converter is, I strongly doubt it would be error free over the tens of thousands of bits in a typical small program.  It only takes a single bit error in your code to make it crash, right? so this seems like a bad idea.

[thesame]

I mean you can easily test that it works by simply connecting TX with RX, and verify that what you send is whay you receive.

I'd write a small program in Python or whatever to send byte patterns and verify.

Without a scope or logic analyzer it'll be difficult to debug the circuit though.

Indeed, I did this at the very beginning. I connected audio input and output with a loopback cable and tuned level controls to make sure no clipping happens. Then I synthesized digital signal at various baud rates with Jupyter and captured it back. This is what I got:

Synthesized signal at 9600 baud:


Recorded back signal:


To me it seems pretty legitimate digital signal.

[thesame]

What's  the point ?

Waste a lot of your time, to reivent the well to save 2 bucks, and have a horrible performance ?

Sort of. The primary point is to have the easiest option of flashing STM32. If it works it probably could help other people someday. Soldering a transistor and a couple of passive elements around 3.5mm jack might be easier than buying ftdi adapter in some circumstances.
The second point is having fun and gaining a little experience. This project seems interesting for me and I find it to be enough excuse for trying.

This is a total nonsense,  nothing is easier than buy < 2 USD converter , or even use one arduino,

It is, unless you have to take a permission for leaving your house under quarantine restrictions and drive for an hour to the nearest electronics supply store.

[thesame]

No matter how good the audio-serial converter is, I strongly doubt it would be error free over the tens of thousands of bits in a typical small program.  It only takes a single bit error in your code to make it crash, right? so this seems like a bad idea.

I can think two sources of errors, level errors and timing errors.

STM32 bootloader tolerates 2.5% of baud rate deviation and I believe audio output sampling rate is far more stable than this. So the timing errors are out of scope.

The level stability totally depends on how reliably the transistor gets open/cutoff. That's why I'm asking the forum for help. From my perspective audio output voltage is enough for driving it but I'd love to hear from somebody if I'm wrong/right.

[thesame]

I think I missed the base current limiting resistor. Could anyone give me a hint on how do I calculate R1 and R2? Schematic diagram is attached.

[gcewing]

That's not going to work very well as you've drawn it, because the DC level will drift off if you get a run of bytes with unequal numbers of ones and zeros.

You might be able to fix the output side by connecting a diode with its cathode to the right side of C2 and its anode to ground, so that the DC level gets reset whenever it tries to dip below ground.

You'll have a similar problem on the input side. You could try eliminating C1 and just drive the MIC input directly (or maybe through a resistor to protect against damaging something). But if there is AC coupling in the sound card that won't help. In that case you might need some smarts in your decoding software to cope with a slowly changing DC level.

[thesame]

That's not going to work very well as you've drawn it, because the DC level will drift off if you get a run of bytes with unequal numbers of ones and zeros.

I found this issue too after asking other people and running simulations. Now I have this version of the schematic:

You might be able to fix the output side by connecting a diode with its cathode to the right side of C2 and its anode to ground, so that the DC level gets reset whenever it tries to dip below ground.

Yeah, transistor base has bias of 0.5V by the divider R2:R3 now. I don't know if the diode could do any useful job here. I'd like to hear your opinion.

You'll have a similar problem on the input side. You could try eliminating C1 and just drive the MIC input directly (or maybe through a resistor to protect against damaging something). But if there is AC coupling in the sound card that won't help. In that case you might need some smarts in your decoding software to cope with a slowly changing DC level.

This is what bothers me now. MIC input is 5V biased from the laptop side and I'd like not to connect it to 3.3V output directly. I'm trying to decouple this bias by the capacitor but I think it still suffers from DC drift over time. How can I eliminate it?

[magic]

There is already AC coupling inside (almost?) every soundcard input, adding another AC coupling doesn't change much. The only solution to it is that your RX software has to ignore the DC level and look for rising and falling edges, wherever they are.

[thesame]

There is already AC coupling inside (almost?) every soundcard input, adding another AC coupling doesn't change much. The only solution to it is that your RX software has to ignore the DC level and look for rising and falling edges, wherever they are.

The thing is that the audio input provides 5V dc offset and I'm trying to block it from the STM32 output.

[magic]

So put a capacitor between them. There is already another capacitor in the soundcard between the 5V biased input and the ground-referenced ADC.

Because of that internal capacitor, the software has to be able to deal with AC coupling and DC drift anyway. That's all I said.