STPM34 smart metering chip returns wrong values after long working time

[DominykasS]

Hello, I am using STPM34 smart metering chip to read 230 VAC voltages and currents. I am using 3 chips on 1 board:

First 2 STPM34 measure 3 phases of 230 VAC voltages and currents, 3 STPM34 measures 16 multiplexed current channels and no voltage.

I am communicating with all chips via SPI interface, I use CRC to verify communication. I also use auto Latch function on all chips and 2x current gain on all channels, these are all the settings I change every time it powers on. The problem I face is after long working time, from a few days to a week, I start to get wrong values from some chips. Sometimes I get wrong voltages, sometimes wrong currents. Currently I am getting 428 V on voltage channel that is measuring 250 VAC on a device that runs for 12 days. Previously I was getting 0 A on a current channels of a device that was running for 5 days. It depends on device that I use. I have 5 PCBs with assembled devices, currently testing 2 on long run and both return wrong values after some time. Could this be error in chip design ? What is the solution for this problem? I am highly speculating that this is a chip flaw because I check CRC after each communication frame. 

[Didier HERROUIN]

Hello,

Did you follow the initialization procedure during power-on sequence, with SYN and SCS pulse to reset the chipset  after each power off/on ?
It is described in the starting guide attached.

Moreover, I strongly recommend you to open a case at: (https://www.st.com/content/st_com/en/support/support-home.html#), you ticket should be re-directed to me and I will be able to support you directly.

[DaneSlattery]

Hi Didier

I am facing the exact same issue, with a single STPM32 in UART mode. I have created a case (#00252353), but Ted Thompson, the employee assigned to the case, suggested I open a new forum post. Seeing as this post describes my exact problem, I would like to jump on to follow up.

Did you follow the initialization procedure during power-on sequence, with SYN and SCS pulse to reset the chipset  after each power off/on ?

---

No, and connecting them to our microcontroller now would require a board revision. We are pulling SYN and SCS up as per the schematic from the datasheet.

We reset using the EN pin, and then write our full config over UART. This has been validated on the support case:

Regarding your question about SCS and SYN: the STPM32 does not require SCS and SYN to be connected to the microcontroller in order to perform a remote reset. A hardware reset can be done via EN, and a “soft” or remote reset can be triggered through the UART by writing to the appropriate control registers. SCS is used for the SPI interface chip select, and SYN is used for synchronization in multi‑device or line‑synchronization applications; simply pulling them high is acceptable if SPI and external synchronization are not used.

---

Note that we using software latching, given that SYN and SCS are not connected to the microcontroller.

After some run time, or during a switching event (there is a relay downstream of this circuit), the device resets. We detect this as a timeout over UART, seeing as our runtime baud rate is 115200, and the default for the STPM32 is 9600. 

---

---

Please advise! I can post more information as required.

[Didier HERROUIN]

Dear DaneSlattery,

I have just seen your case #00252353, I will be able to answer you directly after it is correctly re-assigned to me.

Coming back to the reset sequence, the reset pulses on SYN and SCS described in the starting guide attached are mandatory after each power-on. I am sorry that you got a wrong information previously.

If you want to save 1 opto-coupler, in UART mode, it is possible to generate the SCS signal from SYN + TXD signals using 2 diodes (I will provide you the HW workaround + a FW example in the case). 

If you connect SCS and SYN, driving EN signal is not mandatory, it can be pulled-up (so you would not need any additional opto-coupler compared to your actual design).
And as a protection against pulses (like the ones generated by a relay), we recommend adding the RC filtering (100nF+150pF+100ohms+22K) as in our eval kit : STPM32V2
Another recommendation is to place the relay as far as possible from the STPM32 and to carefully design a good ground plane.

[DaneSlattery]

Hi Didier

Thank you for the reply. For the sake of future users, I will post my follow up here:

What I am struggling to understand is why this is necessary.

I understand that the datasheet recommends it, but from all of our testing across various iterations (including the STPM32 evaluation board), the STPM32 seems to work just fine with `EN` toggling and SW latching, up to some random time. Perhaps the datasheet should be revised to note that it is required.

1. How does a SYN reset change how this intermittent failure may occur, when compared to an `EN` reset? 

I am happy to do a hardware revision including your changes for driving SCS and SYN, allowing me to disconnect the `EN` signal (We will add the additional RC filtering to EN, SYN and SCS and try to move the STPM32). I would appreciate your firmware revision for the reset process, but:

2. Will I be able to do hardware latching through the SYN line, given that `TX` will toggle SCS to prevent an "accidental" reset? Too many `SYN` pulses would of course reset the device.

[Didier HERROUIN]

Dear DaneSlattery,

I agree that the reset sequence should be described in the datasheet as mandatory.

The reset based on SYN + SCS pulses will ensure a correct reset of the DSP, preventing from calculating wrong values . But you are right, it the chipset is submitted to a "failure event" (a high noise generated by a relay), you have to detect this failure and apply a new reset sequence. So layout is important to avoid this case.

You will find a basic metrology code example including the reset sequence on st.com : STSW-STPM002 | Product - STMicroelectronics

Concerning SYN, if you apply the proposal to save an opto-coupler, using SYN signal for HW latching requires to reset the pulses counter after each latch with 1 SCS pulse as you guessed it (see starting guide). 
If you do not use HW latching, SCS can stay high after the reset sequence (use case here is UART mode).