Thanks @dBC. Yes good point I will add voltage protection in to later designs. We do have that on the emontx v3 and emonpi. I need to do more reading on bias configuration. C1 is the 10uF capacitor I mentioned above, dont think its needed now as the buffer provides a low impedance source for the bias.
Cool. I was just playing around in the GUI with your selected CPU to double-check your pinout selection and it all looks good.
With regards the UARTs I notice you’re running the same UART signals to the RPi header as you are to the ST-LINK header. It might be useful to use all 3 UARTs, 1 for the OneWire stuff, one for energy reports to the RPi and one for debug printfs. I had a stab at adding that to your pinouts and it seems to work (see below). Which UART does the bootloader use for your fancy RPi programming stuff? Hopefully USART2?
Also I’m not sure about the 5V on the UART/ST-LINK header. Isn’t this all 3.3V? What do you plan plugging into that dual plug? I was assuming a snapped-off ST-LINK V2-1 programmer?
Thanks @dBC. Yes USART2 (PB4 & PB3), is there a reason it would not work on the others? I tried I UART1 and UART2 both worked ok.
I noted your comment on multiple USART’s before, it’s great having so many USART possibilities. I think I will explore that further on the next iteration.
The 5V on the 5 pin UART header goes to the voltage regulator, I guess its just an option to power the board from a USB to UART cable… 5V is also routed from the RPI headers through the 3.3V voltage regulator for board power rather than using the 3.3V RPI supply.
The plan is to be able to program with both the snapped off ST-LINK using the CLK and DIO pins (plus supply pins) and a standard USB to UART in the 5-pin header below.
Do you see any issue with the flash and sram size for the STM32F303CB? My back of the envelope calculation suggested 23.4 kBytes of SRAM use for the DMA arrays (2x 6000 entry long array’s of 2 byte unsigned integers). I’m assuming the rest of the memory use is relatively small.
Do I also understand correctly that a STM32 chip bought from say farnell will be ready for firmware upload with ST-LINK? Reading this suggests that that is the case: stm32 - Bootloader on STM32F303: built in from factory or externally programmed? - Stack Overflow
Actually, you’ve taken the lead on that aspect. I’ve only ever programmed these things via the ST-LINK. When you reported success on RPi programming a while back I assumed (obviously incorrectly) that the bootloader must have a hardcoded UART that it waits for an image to arrive on, but perhaps it monitors them all and uses whichever one starts talking?
If it does get tight you can always reduce those array sizes, they’re pretty arbitrary. I probably went large in the example code because we were running on a device that had heaps of RAM. Assuming a given sampling rate, the array size simply determines the interrupt frequency. If you were to halve their size say, then the interrupts would occur twice as often, but you’d have half as much work to do on each interrupt. If you were to make them ridiculously small then the ISR overhead might start to become a significant part of the load which wouldn’t be good, but I think we’re a long way from that happening.
Yes, exactly right. I think of those CLK and DIO lines as stm’s version of jtag… very low level and let you flash your image pretty much regardless of the current state of the device. Just make sure any image you build/flash also has those pins enabled: Sys->Debug->SerialWire in the panel on the left (see screenshot below). If the two pins are showing up as Green then you’re good to go.
I don’t know whether that’s the case for the serial programming technique you’ve discovered because I’ve never used it.
1 Like
Thanks for all the input @dBC much appreciated. Thanks for the pointers on the arrays and enabling the CLK and DIO lines. I will press go on the PCB order and feedback on testing once they arrive 
But wait! ;-).
I think you need NRST on that STLINK header too. Which signals did you hook up when you did your snapped-off-STLINK programming experiment a while back?
We run 8 signals to our programming header:
VCC, GND, NRST, SWCLK, SWD, SWDIO, STLINK_RX, STLINK_TX
I think VCC is so the programmer knows what voltage the target is running at. SWD I don’t use but I think it permits trace/debug stuff.
Here you go… you had five wires hooked up: https://community.openenergymonitor.org/t/stm32-hardware-development/7135/20?u=dbc
Good spot. I had a mental note in my head that I was getting around that by setting BOOT0 manually with a jumper, powering off and on the board and then its ready for STLINK upload. Double checked it now and it does work. But I’m not actually sure why I didn’t include a pin for NRST as that would of course be easier… I do have it routed to a pin on the RPI header so I can always test with that.
Yes, I guess if you’re using individual flying leads and pins it doesn’t matter too much. I think you do need to run Vcc as well (3.3V definitely NOT 5V) so that the programmer can see the target is powered (and see what voltage it runs at). I’m still a bit nervous about having 5V anywhere near that header… but so long as everyone knows what they’re doing it should be ok.
Thanks @dBC, I’ve modified the board to include NRST and routed 3.3V to the UART header for easy access. I’ve put the 3.3v line through a jumper as the UART 3.3v will otherwise potentially conflict with the 3.3v on the board from the VREG, not sure if that’s an issue or not.
I also realise I had left in a 3.3v track to the RPI header which was not needed now removed.
It shouldn’t be necessary, but I remember one user who did this found the op.amp. was taking off and oscillating, so don’t take anything for granted! You may well find a much smaller value or even a Zobel network might be needed - it all depends on what the centre rail looks like as a load on the op.amp.
1 Like
Thanks @Robert.Wall I will keep an eye on it. I though I had better include it on the design just in case.
Using the forum search tool uncovers Learn | OpenEnergyMonitor which you of course added and I’ve been reading through some of the older threads too.
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 
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
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, http://ragworm.eu/ 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:
https://github.com/openenergymonitor/STM32/tree/master/Hardware/5
and 3CT energy monitoring firmware for the STM32F303CBT6 chip:
https://github.com/openenergymonitor/STM32/tree/master/Emon3CT_CB
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
6 Likes
Hi Trystan
Do you have a BOM for the prototype board. I might give it ago as part of my continual learning curve.
Ian
Hello Ian, Great! I haven’t put a BOM together for this design yet. I ordered the stm32f303cbt6 from RS: https://uk.rs-online.com/web/p/microcontrollers/8107660 and this crystal https://uk.rs-online.com/web/p/crystal-units/8136031. 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