STM32F334 SPI TI Mode

[Manu Abraham]

Posted on April 04, 2018 at 12:42

Hi,

Trying to establish SPI communications from a STM32F334 with a DRV8305 from TI using SPI, after a bit of struggling thoughts and struggles to establish valid communication with the slave; arrived at the thoughts that TI mode is necessary for establishing SPI communications with the Slave.

The STM32F334 is connected to the DRV8305 with the following schema:

NSS --> nSCS

SCK --> SCLK

MISO --> SDO

MOSI --> SDI

I am getting weird register reads, which is not expected according to the DRV8305 datasheet

http://www.ti.com/lit/gpn/drv8305

I am reading all the 12 registers (default values of registers 5, 6, 7 seem to be incorrect from the reads), writing default value (0x344 to registers 5, 6, 7) and reading back all the 12 registers again. Somehow, it appears that the writes are not even going to the corresponding registers, nor the reads are reading back the expected written values. Sigh!

My first thought was that, the TI mode was necessary for the SPI Frame format and that NSS needs to asserted High for at least 500nS in between frames. As such I chose to use NSS to be hardware controlled and to use the NSS pulse mode. But that helped in reading something from the Slave, but the read values do not seem to be relevant either.

Tried connecting a scope to the SPI pins, but after connecting the scope, all my reads are then '0''s.

Looking for the bug in the SPI read/write functions and feeling a bit lost; I wonder whether someone has any pointers to identify the issue.

Thanks in advance,

Manu

#ti-mode #spi #stm32f334

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[kraiskil]

Posted on April 04, 2018 at 14:24

Tried connecting a scope to the SPI pins, but after connecting the scope, all my reads are then '0''s.

This is clearly incorrect.

Either you have connected the scope in some really strange way, or the slave isn't powered or something equally silly.

I suggest you start by debugging your hardware setup till you can decode the SPI traffic on your scope, and then compare the SPI data visible on the scope against what you wanted to write/read from the slave device. Only then does it make sense to start looking at the software (IMHO).

[Manu Abraham]

Posted on April 04, 2018 at 15:31

The software generates the SPI waveform, because the waveform is not correct the read/write is incorrect. If the waveform needs to be correct, to generate the proper functioning of the code, then there is no need to check the code in the first place itself. I don't see any reasoning for your statement though. Well, something wrong with my scope. I need to check with another one.

[Manu Abraham]

Posted on April 04, 2018 at 16:59

To clear Kalle's doubts:

The SPI slave is powered, no doubt about it. It has an internal 3.3V regulator, the STM32F334 is powered from that regulator itself.

Got a different scope, connected it to SCLK and SDI:

I had to change the SPI BaudRatePrescaler from 2 to 256 to see the waveform a bit more clearly.

spi.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_256;

The read back values were different from the earlier situation.

The new values and waveform screenshot's in the attached PDF

Changing the Prescaler back to 2, results in the very first log.

It's slightly confusing though why the change in the prescaler causes the change in the read back values, in addition to the earlier issues of incorrect reads ?

________________

Attachments :

DRV8305_SPI_Debugging_SCLK-SDI.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxqQ&d=%2Fa%2F0X0000000b1I%2FV__7rTcM2v_D5KH5rcyrIn1uj2k.cVm6XPyBCm0TQQk&asPdf=false

[Manu Abraham]

Posted on April 04, 2018 at 18:59

Did some more debugging with the SCLK and the SDO lines.

It becomes slightly more clear, why the Reads are behaving weirdly.

The SDO output does not seem to rise fast enough and up to the Logic HIGH.

But at some points in the waveform, the SDO does rise up to Logic High and fast enough.

I do find it quite an odd behaviour of the SDO line.

Attached SCL - SDO waveforms

Did a google search on the SDO issue.. .. came up on this thread

https://e2e.ti.com/support/applications/motor_drivers/f/38/p/549122/2004854

Does that indicate a broken SPI slave implementation on the DRV8305 ?

How does a simple pullup address that issue ?

Another strange issue is that, I do not see the pullup mentioned neither in the datasheet or the EVM schematic.

Any thoughts ?

Thanks !

________________

Attachments :

DRV8305_SPI_Debugging_SCLK-SDO.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxqL&d=%2Fa%2F0X0000000b1H%2Fah1CagBSgHQXC6bLghT2LWBMnH_tVWb5I5j4atppRjY&asPdf=false

[kraiskil]

Posted on April 05, 2018 at 09:33

I don't see any reasoning for your statement though.

None intended, just a gut feeling I had. Looks like it was correct

The SDO output does not seem to rise fast enough and up to the Logic HIGH.

But at some points in the waveform, the SDO does rise up to Logic High and fast enough.

Sounds indeed like a problem with the slave peripheral.

How does a simple pullup address that issue ?

If the peripheral has problems driving up the SDO, then pull-up gives the peripheral a boost with this.

   Another strange issue is that, I do not see the pullup mentioned neither in the datasheet or the EVM schematic.

Are you sure? In the link you posted it says 'EVM SDO pin is pulled up, ours is not.'

But the main question is - did the pull-up fix it?

:)