STM32 and STPM33 weird SPI behaviour

[holcsik]

Posted on November 22, 2016 at 20:52

Hello,

I'm building a multi phase power meter with 6 pcs of STPM33 ICs and an STM32. The STPM33 chips are on the same SPI bus, with separate chip selects (SCS) for each meter. The MCU can control all of the control signals (SYN, ENABLE, SCS etc.. ). The meters are daisy chained together by the 16 MHz clock line, as the datasheet recommendation. The ''first'' meter has a 16 MHZ crystal, and using the internal oscillator. Now only the ''first'' chip is soldered to the board, just for testing purpose...I followed  the recommended startup procedure for setting the SPI mode for the meter. The meters works with no problem, I can read out meaningful data. The problem:When I deselect the meter chip (SCS->H), the MISO line doesn't go to High Z state, still pulling the MISO line strongly. I connected the MISO line to the half supply voltage by a resistor divider to see on an oscillopscope if it's letting go the line, but no. I couldn't find any errata from the chip, now I have ran out of ideas, after hours of troubleshooting.According to this evalboard, STPM33, 34 can be connected to a single SPI bus. http://www.st.com/en/evaluation-tools/evalstpm3x-3ph.htmlI have a screenshot from a logic analyser from the startup sequence. I think it's like the recommended sequence. The SCS is low before the ENABLE pin goes high, and then there is the 3 SYN pulse, and finally the SCS pulse. There are enough delays for each state.What could be the problem? This is a very-very basic hw function...(Sorry if I'm not in the right topic, but couldn't find a better place) #stpm33

[James Brunner]

Posted on June 22, 2017 at 18:46

Although I realize this is a fairly old post, I wanted to chime in our experience with the issue as well since this discussion board has very little content regarding the STPM3x chips.

We are currently using two STPM34 in a multipoint AC sensor PCB and interfacing to them using SPI bus.  We've gone through a successful prototype design and things were looking quite nice.  However in our pilot production round, the circuits is no longer working and we've isolated the problem down to (we think) SPI bus contention between the parallel STPM34's MISO lines.

As in the OP above, we have the two sensor chips clocks daisy chained with the crystal on the first and the output clock driving the second.  Each chip has independent chip select lines, and we have confirmed that we can drive each chip select properly to address one or the other sensor.

Also as in the OP above, we find that the MISO line isn't able to achieve a reasonable high state when deselecting one of the sensor chips.  I.e., it appears that the MISO is not set to high-Z state when SCS goes high.  Our current design is using no pull resistors, but we see that the STPM34EVAL design does use pull-ups on the SPI data lines, so we've tried both weak (100k ohm) and strong (330 ohm) pull-ups to patch the issue without luck.  The weak pull-up had no effect, and the strong pull-up still did not meet the full level logic high (3.3 V) while it pulled the logic low level up half a volt.

The most frustrating thing is that this designed looked pretty solid in our prototype, but is now failing in the same fashion across an entire group of boards manufactured to the same prototype design.

[waclawek.jan]

Posted on June 22, 2017 at 19:24

I don't see in STPM33/34 where it says that MISO goes Hi-Z upon SCS going high.

JW

[James Brunner]

Posted on June 22, 2017 at 19:27

Perhaps it's not explicit in the datasheets, but I would expect a well-behaved SPI peripheral to let go of the slave output line when not selected.

[waclawek.jan]

Posted on June 23, 2017 at 13:14

I understand and I would expect the same, but the datasheet is there to bring out expectations in line with the reality.

I feel your pain especially since the prototype worked (marginally, probably) and you have boards out in the wild, but I see no other solution than a hardware fix... :(

JW

[James Brunner]

Posted on June 28, 2017 at 17:08

(I've opened a support ticket with ST on this issue and we've provided the following test results...)

SUMMARY

We removed the STPM34 chips from older prototype boards that worked fine and replaced the STPM34 chips on the pilot boards with those from the prototypes.  The pilot boards began working properly after the chips were swapped.

CHIP MARKINGS

The

working

, prototype STPM34 chips had the following markings that differed from the pilot board chips:

GMFMB VG

CHN 619

The

non-working

, pilot STPM34 chips had these markings that differed from the pilot board chips:

GMZHD VG

CHN 424

In light of these results, it seems the root cause of our issue may be related to some fundamental characteristic of the STPM34 chips themselves.

[Martin Kocik]

Posted on January 11, 2018 at 21:51

Hello everybody,

I didn`t sleep for 3 nights facing same issue. We have working prototypes with chip marking 635 series, and now we produced series with 425 chip marking and we found same problem, that MISO line doesn`t go to Hi-z state. We have four STPM34 on single SPI bus, with separate EN, SCS, SYN signals. I am very disappointed, because everything was perfect on prototypes and now we have non-working series. We are thinking about to add 3-state logic gate to each MISO line controlled by SCS signal to fix this issue, but we need to redesign board again

:(

Is there some official bug report from ST, or this is the feature of this chip for future? ________________ Attachments : IMG_5256.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyCH&d=%2Fa%2F0X0000000b4U%2FUgGR7jD44TK8HpoI1Y1RVz9IWRQQZa3a915qp0G7YI4&asPdf=falseIMG_5257.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyBy&d=%2Fa%2F0X0000000b4T%2FM5nOrMDegCi51zHIBK5Px6Unh6yHC8o2KNyOAuIZrPg&asPdf=false