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,

 

Why am I no longer able to view the previous replies?

 

Aymen

[Peter BENSCH]

Because the community was switched to another platform this morning, and all content from the last about 28 days still need to be migrated. This should be completed over the next few days.

See announcement for details.

Regards
/Peter

[Mohamed Aymen]

Thanks Peter, for your response, I'll wait for the migration to be completed

 

Aymen

[Karl Yamashita]

In some devices the MISO may be an open collector output and not push-pull design, so you may need a pull-up resistor on the MISO line. You can quickly verify using the STM32 internal pull-up on the other device that you didn’t solder wires to. If it works, then you should add some external pull-ups especially if running at a high bus speed..

[Didier HERROUIN]

Dear Mohamed Aymen,

My previous answer seems lost during the migration…

Please share your schematics, and help me to understand how you manage SCS at power-up.

If SCS is not low before EN, VCC and clock, the chipset will be locked to UART mode instead of SPI.

Best regards,

Didier Herrouin

 

[Didier HERROUIN]

Dear Aymen,

Here are my comments I had posted on former ST community thread :
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.

 

Have you been able to investigate these points ?