Yes they are both open, thanks for the tip, much appreciated!
I neatened up my USB DFU (right) and Opamp testing (left) circuits this morning, ordered a USB mini adapter rather than having flying leads on the end of a USB socket with the risk of shorting the connections. Still same error on USB, I still need to look into the BOOT1 bit question.
Ken Boak introduced me to small energy monitoring development board with a supercap and FRAM on it a while back. I’ve done a quick calc to see if the RTC can be powered from a supercap instead of a coincell, which would be good in principal.
Typical current draw at VBAT is 0.5uA, 1uA max., according to STM guide.
I’m assuming the RTC uses the internal high speed clock and assuming the guide’s figure is based on using the internal clock.
The leakage current of this 1F cap is about 2.1uA, worked out from the discharge over time graph, 100h charge time.
“Resistance” at above site worked out as 3.3V / 0.0000031A.
614 hours or 25 days.
With a 50% drop in performance, seems usable for most contexts…
EDIT: I guess my main question on supercap vs battery is whether or not the time will be set during programming before shipping, would a short shelf life for an RTC be an issue for the OEM crew? Or does the module get time from an ESP or other internet connected MCU?
Doing a bit of a review of my local CVS respository, I noticed I had outstanding changes on the emontxshield project that related to enabling the opamp as described above. I figure that’s probably worth capturing the in the tar file series (and @pb66’s github repository) just to show how it’s done. While I was there I also included the opamp output in the ADC scan so have included that as well. The plot below is graphical representation of the DUMPING output you get if you dump that “channel”, you can see it matches the scope traces of the triangle wave above and has no trouble going rail-to-rail.
I’ll post a new version of the tarfile in the main thread to keep them all together.
Thanks @dBC for the advice on adding the RX and TX lines to the ST-LINK connector in the PM, thought I would move the discussion here for everyone’s benefit, is there a recommended standard pin order/connector for ST-Link with rx/tx lines?
Im wondering if something like this would work, a combined UART & ST-Link 8 pin header. First 6 pins would program using one of our standard UART to USB adapters, SWDIO and SWCLK added on top to provide ST-Link option:
Here are a few photos of our new dev board.
below: with solder paste.
a beautiful 100-pin stm32f303
Notes on design to follow in a separate post.
Trys and I are keen to develop the smaller board in parallel. 1VT and 3CT sat on top of an rPi. Something we need to cost out. I think there’s a post somewhere showing this?
Yes: STM32 Development - #280 by TrystanLea
1 Like
Wow! You guys have been busy. Well done! I gotta’ ask… what does CLMP stand for?
1 Like
CLAMP!
I like the look and feel of these:
. 1822765 Phoenix Contact | Mouser United Kingdom
P.S. Thank you 
Despite having a poor camera on my phone I had to share. Got Blink working on the virgin chip!
It involved using ST-Util on Windows 
Is there an alternative?
1 Like
Fantastic progress @danbates!
Could you upload using method documented here?:
STM32/Blink.md at master · openenergymonitor/STM32 · GitHub
Yes, once the first flash is made the copy-to-volume method we’ve used before works fine.
I’ve added a note on the readme and a doco page.
. https://github.com/danbates2/STM32/tree/db#hardware
Doh! I’ve got Tx and Rx on UART2 swapped, so the FTDI header is out of action.
UART1 debug out is working fine.
Got it!
RST pin needs the 100nF cap, I had to bend it out of the way for the chip to run.
Pics of the rPi ontop here…
Some details not easily seen in the photographs:
- CT and VT ADC inputs routed to allow synchronous sampling. (4 ADCs available on our chip) Expansion module 6 CTs planned should also be fine with synchronous sampling.
- RJ45 connector included following combined pinout for optical sensor and temperature sensor compat.
- Lots of solder jumpers placed to play with either SPI or UART data transfer between the rPi, STM32, and ESP8266 module.
- DIP switches on CTs 1,2 and 3 to switch out burden resistor.
A few notes from convos with Trys:
- We’re looking for an all rounder 3-phase native board with rPi mount, which doesn’t cost the earth.
- Case design as custom injection molded case. Clean, simple, white, rounded corners. Screwless with a pop-off inset lid ideally.
- Replacing the esp8266 based module with an esp32. Without rPi, this gives great standalone features.
- USB-C will be the power-input connector.
- clamp connectors to be versatile, a mix of I/O and analog. Expansion module has similar thinking around it, with provision for at least 6 more CTs, do we need extra VTs?
A few notes of my own:
- USB DFU enabled chip seems possible. CubeMX auto clock config has shown it’s possible… so far not got it work. Anyone here with experience in this?
- microSD and supercapacitor footprints, for local logging of large volumes of data, and maintenance of the RTC in case of power-outage.
- Undecided on best way to route the wire-clamps, at the moment each triplet has 5v pwr, 5v tolerant in/ 3.3V out, and gnd. Could be nice to go for a triplets of: 5V 5V 5V. 3V3 3V3 3V3. Signal Signal Signal. Signal Signal Signal. GND GND GND.
Many thanks.
2 Likes
This looks great.
Do you mean include the header holes to connect directly? If so, great. Unless this board is used as an EmonPi type all in one, the reduced cost of something like a D1 v a Pi is significant especially as more and more, folk will already have a Pi doing other things as well.
For the SW for a an ESP module, why not just create a custom component on EspHome?
Quick update from a session earlier with Trys.
UART flashing was not working because only specific Rx/Tx pins are to be used in boot mode.
So even though I’d connected to an Rx compatible pin, it was not a boot mode Rx pin. Easy when you know how.
DFU wise, seems the programming manual has a clear Windows direction… So I’ll load up the VM again and go through a Windows process of getting DFU working, seems to require a specific driver install.
Also, I found the Linux/Mac/Windows cross platform method for the flash of the fresh chip. Using this:
. STM32CubeProg - STM32CubeProgrammer software for all STM32 - STMicroelectronics
It’s near identical to STLINK-UTIL for Windows.
1 Like
Just came across this after I read the twitter post that you are now also using STM32. That’s great, I’m also using STM32 for all my boards. Don’t like the CubeMX stuff though, so I used mbed and I am now trying out Zephyr OS.
For USB DFU under Linux, the following guide might help (Linux command at the very end): https://libre.solar/docs/flashing/
2 Likes
Good to hear.
would you mind posting a few pros and cons to cubemx vs mbed?
You see, I tried mbed, and didn’t like it. I like the idea of what they’re doing…
The cubemx code initializer is very useful…
Well, this might be a bit subjective, but here are my reasons:
- I prefer to use a proper web-based documentation and a git code repository with good examples over a tool that I have to install (and that was originally not even running on Linux without tricks).
- The different layers CMSIS, LL and “HAL” confuse me. For simple tasks like sending data over a UART, the STM HAL does not really abstract the hardware enough. And if I want to use special features of the microcontroller I can just take the reference manual and set the registers directly. Otherwise I need to read about the features in the reference manual and afterwards find out in some other documents how to actually implement these features using HAL functions.
- mbed or other generic frameworks allow to write more portable code, that does not run only on STM MCUs.
- mbed syntax as easy to understand as Arduino, or even better, as PWM signals are not named analog (!) outputs.
However, mbed also caused some headaches. For example, several times the firmware that worked before suddenly stopped working after an update of the mbed version. But you can prevent PlatformIO from updating mbed and then it’s fine (if you use PlatformIO aswell).
Unfortunately, the definition of custom boards is a pain in mbed. I failed to set up a board with the STM32L452, which is not officially supported by mbed. That’s one of the reasons I’m now also trying out Zephyr. In the long term, I’d love to use Risc-V microcontrollers once they become available for the low-end segment. And mbed will of course never support them. Zephyr is not limited to ARM micros and supports also ESP32 for example.
3 Likes
Having discovered RISC-V only about a month ago, I really like the idea of it being more available at good prices, it could be really great.
I have the ESP12 module working now. Had to cut tracks to swap the tx and rx again
I need to connect the NRST of the STM32 to the RST of the ESP too.
I think at the last meeting we settled on an esp32 module anyway. Yesterday I found mouser supply them with 16MB of flash, cheap.
1 Like