STM32 Hardware Development

So I pinched PA6 and PA7 from the CT input scan on the emonTxShield demo (they weren’t being driven anyway) and used them for OPAMP2 in follower mode. So my pinout now looks like:

Then I hooked up the signal generator to PA7 with a rail-to-rail triangle signal (Yellow trace) and also probed the output PA6 (Green trace). The datasheet says the opamps are good for 0.5 mA so I loaded up PA6 with a 6k R to GND. The Pink trace is Green minus Yellow (i…e. output - input).

The results are pretty good. Green is so identical to Yellow you can’t really see it. Pink shows about a 20mV offset between the two. I tried with the factory trimming and the user trimming but I couldn’t notice any difference to the ~20mV offset. BTW, if you do want to do a user trimming and self calibration, you can do all of that from the GUI under Configuration->OPAMP2. It’ll then generate the call to HAL_OPAMP_SelfCalibrate() for you, from within MX_OPAMP2_Init(), after it’s called HAL_OPAMP_Init().

[EDIT] - actually I see the exact same 20mV even when I connect both probes to PA6 so I think it’s just a scope measuring limitation rather than an indication of an offset out of the opamp.

Fantastic, Opamp2 on PA6/PA7 works!! :slight_smile: I’ve got a 10uF capacitor across my 470k:470k voltage divider, with an LED on the output you can see brightness change as I switch the top resistor to 150k, great!

1 Like

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.

http://mustcalculate.com/electronics/capacitorchargeanddischarge.php?vfrom=3.3&vto=1.65&vs=0&c=3&r=1269230.7692

“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 :slight_smile:

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 :scream:

Is there an alternative?

1 Like

Fantastic progress @danbates! :slight_smile:

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!

08

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

Looking good @danbates!

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…