STM32 Development

So you inspired me to look into how this serial programming stuff works, it all seemed just a bit too flexible to be true. As I mentioned before I’ve only ever used the SWD interface for flashing, so I’ve not tried any of this and it’s based solely on some quick research this morning.

I came across AN2606. Section 6 seems to be the relevant one for your device. The good news is it does indeed poll multiple UARTs for an incoming 0x7f and then uses that UART. The bad news is, it requires the UARTs to be mapped to known pins (PA9 and PA10 for UART1 and PA14 and PA15 for UART2).

In your experiment here, you used PA9 and PA10 (UART1). Are you sure when you tried UART2 you used PB3 and PB4, and not PA14 and PA15?

The schematic has the FTDI programmer header connected to PB3 and PB4. Once your f/w is up and running it can easily map those pins to UART2, but until then I think the bootloader will have UART2 mappped to PA14 and PA15 (at least according to AN2606).

And on the Vcc stuff…

I think this is the critical point I missed, and I agree it’s a great goal to be able to program it with your existing USB<->UART programmer.

I think you should be ok there. For both the ST-LINK programmers and the serial programmer the 3.3V pin is an output from the target and an input to the programmer (it’s not used to power the target).

In the case of the ST-LINK programmer, it’s pin 1 on CN4 in your schematic excerpt here. Although as you point out, on the ST-LINK strip programmer that pin is disabled (hence your n/a). On more advanced ST-LINK programmers, the programmer senses the voltage at that pin to know the target’s Vcc. I guess for the Nucleo strip programmer they can safely assume everything is running at 3.3V and it clearly works fine without it.

Checking the schematic of your shop-sold serial programmer here it looks like that 3.3V pin is how the programmer gets powered, i.e. the target board is powering the Vcc of the SILabs CP2101 via that pin.

Thanks for spotting and looking into it @dBC. I did not test PB3 and PB4 unfortunately but really appreciate you looking into it. I will test with the f303re I have here tomorrow. Il have to get some mini wire links on those small stm pins on the prototype to test :slight_smile: or send for another.

No problem. I’ll be interested to hear what you find, but it seems impossible for the UART to be plumbed to two sets of pins at once so I suspect PB3/PB4 won’t work, unless there’s a typo in AN2606.

The other thing I noticed in AN2606 is that the bootloader only polls two UARTs (UART1 and UART2), so if you ever do go the three UART approach I suggested above, be sure to use UART3 for something that you don’t plan booting over (OneWire or ST-LINK debug printfs).

[EDIT] - and the bootloader is burnt in at the factory and is un-erasable. So once you get the pin issue sorted, I think you should be able to use either method (ST-LINK Vs Serial) to program your virgin chips as they arrive from Farnell etc.

I’ve updated the design to use PA9 & PA10 for UART :slight_smile:
The DS18B20 has now been moved to UART3:PB10, the pulse counter to PB15 and LED to PB14

Ragworm have kindly allowed me to update the order that was in process.

1 Like

I’m happy to say everything worked with the first prototype PCB!
With special thanks to @danbates designer of emonDC for helping to assemble the board with his SMT soldering skills and @dBC for finding the issues fixed above that meant all of this worked.

So far we have tested:

  • Power supply
  • ST-LINK firmware upload
  • Serial firmware upload
  • RaspberryPi automated serial upload procedure
  • LED indicator
  • 8MHZ HSE oscillator
  • CT and ACAC power measurement
  • DS18B20 temperature sensing input
  • Pulse counting input
  • Datalogging to emoncms via raspberrypi serial and emonhub

All working well.

Here are a couple of pictures of the board, where very kind to update the order with the fixed design and then fit it on one of their black soldermask board runs which looks particularly nice:

Here’s the latest hardware schematic and board files:

and 3CT energy monitoring firmware for the STM32F303CBT6 chip:

The next step is to test the filter design in more detail and run the unit in parallel with an EmonTx. @danbates is looking into firmware libraries for RFM69 support and we will be revisiting the requirements of a fully featured board as discussed here STM32 Hardware Development.

Overall very happy with how this first prototype turned out :slight_smile:


Hi Trystan

Do you have a BOM for the prototype board. I might give it ago as part of my continual learning curve.


Hello Ian, Great! I haven’t put a BOM together for this design yet. I ordered the stm32f303cbt6 from RS: and this crystal The rest of the components were all in the office and we just read off the schematic.

I could order more PCB’s if there was interest? but we will be moving forward soon with additions :slight_smile:

A post was split to a new topic: DS18B20 reliability considerations

I’ve been helping @TrystanLea with the RFM69 side of things. I’ve made some good progress, with special thanks to @dBC for help over pm.

I’ve written a guide to the implementation which can be found here:

. STM32/ at master · openenergymonitor/STM32 · GitHub

This is compatible with LowPowerLab radio packets. I’ve looked at JeeLib packets and think I have a good understanding of the main differences, yet can’t quite get it working. So there’s something I’m missing there. For the ‘jeecompat’ project, I have a github branch here.

1 Like

I’ve brought together the emon3CT and RFM69 code here:

For the TxShield, it might be worthwhile developing a bit-banging SPI approach to accessing the RFM69 module.

If testing the emon3CT sketch on a TxShield, only CT2 and CT4 are available.

1 Like

Just a heads up to anyone who might have cloned my 1-wire uart off-load example above (@TrystanLea @danbates): you get better results if you enable “Single Sample” on the uart(s) involved:

When I get a chance I’ll write up a spiel on why - complete with scope traces, and I’ll freshen the tar file with that and a few other features.

I was reminded of this project by @Robert.Wall WiFi only EmonTX - #5 by Robert.Wall.

It seems this design is wedded to an RPi setup? What is the rationale for that design decision?

I’d like to see the option for a WiFi setup. Maybe a daughter board that could plug into the RPi header for a Wemos D1?

Hello all,

First post here.

Has an external voltage reference been considered for the VDDA supply on the STM32, e.g. LT6656?

It has five times lower ppm/deg C drift (20ppm vs 100ppm), with 0.1% accuracy, so should improve accuracy, at least related to the reference error. I guess if calibration is performed the 3% inherent accuracy of the STM32 internal reference will be overcome, but not everyone has access to an accurate multi-meter. Having an accurate external reference on the VDDA means the internal reference would not be needed to be used in any calculation of the supply voltage, and hence full scale value.

I’ve bought an STM32F303 Nucleo board and intend to get an energy monitor working using it. My background is RF engineering, I am not a programmer, although I do dabble, so I wont be able to help much with the software. I’d be happy to help with the hardware design if I can be of help with the project.

It looks like great progress has been made!

Best regards,


1 Like

Welcome Paul,

I’ve been sifting through the stm32 manuals and followed most of the design recommendations. This has ended up with my choosing a voltage reference, it’s 0.1% and 50ppm.

MCP1501T-33E.pdf (1.1 MB)

The decision for this one is made mostly on cost… I’ll check the one you posted now…

Seems no longer supplied by farnell! Seems the price is a fair bit higher too.

I’ve put a solder junction on the prototype to bring either 3.3V source into VDDA, so we can keep exploring the options.


On the case. Our large board has the footprint for an ESP12. When we go farther with the smaller basic board, we can look at getting a footprint or module header there also.

I think, overall, the rational for using rPi is clear, but we don’t want to ‘wed’, as you put it, the design to it either.

Contemplating the recurring question of NULL values in the emonCMS graphs, many of which appear to come down to an absence of synchronism between the data source (the emonTx usually) and emonCMS, I wondered how practical/desirable it would be to include a radio code clock in the STM32 sensor node - not necessarily for the purpose of providing an absolute time, but to provide a timebase for reporting that would be locked to World time - hence Internet time - that would not suffer from the drift that causes the database to have either null values or to receive values that get overwritten by the next one to arrive.

1 Like

Or could it be an issue with the emonhub - MQTT - emoncms interface? Even on the EmonPi there are 2 additional steps between the Serial output from an EmonTX and the Input of EmonCMS.

You could eliminate that with a direct link, via WiFi from the EmonTX to Emoncms via an API call and possibly timestamp that data at source. I’m still not clear why the default from emonhub was changed from the API to MQTT.

MQTT is very fast by comparison.

@Robert.Wall thanks for reminding of this. A related topic came up while discussing the new stm32config module. Whether to poll the stm32 for the data from a directly connected rPi or wait for the interval data (which could drift in time). Same issue could crop up with the Nulls in emonCMS. Apart from hacking emonCMS there are better solutions…

My feeling is firstly, to specify an accurate 32kHz crystal for stm32’s rtc.

And then to have a method which involves correction of the node/stm32. The hub/rPi would have to detect a delay or advance of the interval, then send a command. The node/stm32 would have to interpret this command and correct it’s time.

Cheaper than building an atomic clock ourselves.

I guess time-correction is how everything along-the-chain works, going as far back into the internet as I can imagine, there’s prpbably a computer somewhere reading an atomic clock, and ‘internet-time’ is periodically being adjusted to it… I’m guessing.

Good to think of this now.

1 Like

Does that speed assume the MQTT broker is on the same machine? If so that is an assumption (I run a separate broker).

The other issue is that MQTT does not buffer like the API call does. If for some reason emonhub does not make the connection, with MQTT the data is lost, with the API interfacer it buffers until the data can be sent.

Comes back to tying this to an RPi and emonhub I feel.