STPM34 SPI Communication Issue at Startup – Measurements Stuck at Zero Until Board Restart

[Mohamed Aymen]

Hello Team,

We are currently investigating an issue related to the SPI communication between the STPM34 sensor and the STM32F4 microcontroller.

At system startup, all values measured by the STPM34 remain stuck at zero. Even when voltage and current are injected using an OMICRON test bench, no measurement values are received or displayed.

Several tests were performed:

• If we power up the system and confirm that the issue is present, then electrically restart only the board containing the STPM34, the communication recovers correctly and the measured values are no longer stuck at zero.
• We also soldered wires on one of the SPI buses (SPI1). Since there are two STPM34 devices on the board, two SPI instances are used to communicate with each sensor. The purpose was to verify whether the communication between the sensor and the STM32 was correctly established.
  • Interestingly, simply soldering wires on this SPI bus makes the issue disappear for this instance. However, on the second SPI instance, which was not modified, the issue is still present.

After reviewing the STPM34 datasheet, we noticed that in section 5 – Typical Application Example, resistors and capacitors are recommended on the communication lines. Currently, these components are not implemented on this board.

Could the absence of these recommended resistors/capacitors on the SPI lines explain this startup communication issue or unstable behavior with the STPM34?

Thanks,

Aymen

[Mohamed Aymen]

 Hello,

@Imen.Dcould you please comment on this post or forward it to the appropriate team/person responsible for this topic?

Thanks,

Aymen

[Didier HERROUIN]

Dear Aymen,

The capacitors on SPI lines are recommended for immunity against noise, but they can not be the root cause of a defective SPI communication. The resistors should not be mandatory if the SPI lines are correctly driven by your MCU.
For SPI link selection, you must ensure at power-up that SCS signal is set low before VCC and EN rise. SCS must be kept low until a couple of clock period (16 MHz) reaches the device. The device is locked in SPI mode until a reset by EN pulse or a new power-on sequence is performed.

Do not forget to apply the reset sequence (based on pulse on SYN and SCS signal) during power-up sequence, as defined in the User Manual UM2066 (even if I don't think it is the reason of the problem you observe).

If you can probe the SPI signals, it would be very useful to find the root cause.

And do not hesitate to share your schematics, I can review them.

Best regards,

Didier

[Mohamed Aymen]

Thank you Didier for your response.

>If you can probe the SPI signals, it would be very useful to find the root cause.

Regarding this, whenever I probe the SPI signals the issue disappears and does not occur again. This is why I asked about the recommended capacitors and resistors mentioned in the datasheet, as I suspect they may influence signal integrity or noise immunity.

What makes me think this could be related is that to probe the SPI lines I had to solder wires onto them, after doing so the issue no longer occurred, which suggests that the additional parasitic capacitance, resistance or loading introduced by the probing setup may be affecting the behavior of the SPI communication

Aymen

[Didier HERROUIN]

Dear Aymen,

It would be surprising that the SPI lines are so sensitive to capacitive changes. Nevertheless, adding some parasitic capacitance/inductance on the signals (especially on SCS) could impact the rising time of the signals. As explained in my previous message, SCS must be low when EN and power supplies rise : maybe the probe help keeping SCS low at start-up ? You could check that SPI is correctly selected (instead of UART) by forcing manually SCS to low at power-on and try a SPI communication again.

I take the opportunity to attach a device limitation about several STPM3x sharing the same SPI bus in case you missed it on st.com

Best regards,

Didier

[Andrew Neil]

---

@Mohamed Aymen wrote:

whenever I probe the SPI signals the issue disappears

---

How, exactly, do you have the STPM34 sensor connected to the STM32F4 microcontroller?

PCB? Breadboard? Other...?

Some good, clear photos of your setup might help.

And your schematic.

Could there be an earthing problem - which gets fixed by your probing ... ?

[Mohamed Aymen]

Thank you all for your assistance.

Attached are the schematic connections between the STPM34 energy metering IC and the STM32 microcontroller used on my board

With kind regards,

Aymen

[Didier HERROUIN]

Dear Aymen,

In your schematics, I can not see the anti-aliasing filters to be placed at each ADC input.

And we recommend also some filtering on the SPI lines and on EN signal to improve immunity against EFT (Electrical Fast Transients). You can refer to the eval kit schematics as an example.

Concerning your issue, there is no pull-down on SCS: it means that at power-on, it will be floating during your MCU init phase. Nevertheless, as the EN signal is driven by your MCU, you can keep EN low (=STPM34 reset ) until the init phase is achieved (SCS must be set low to select SPI mode), then EN can be set high and you can start normally the init sequence of the STPM34 described in the starting guide.

Best regards,

[Mohamed Aymen]

Hello @Didier HERROUIN ,

Thank you for your feedback. I will investigate and test the reported behavior and will get back to you with the results

Best Regards,

Aymen