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 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 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 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?

:)

[Manu Abraham]

Posted on April 05, 2018 at 12:03

Raiskila.Kalle wrote:

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.'

Attached EVM schematic. I do not see any 10k pullup on the SDO line in there.

It could be possible that TI had added a pullup resistor on the EVM board seeing the SDO line issue.

Raiskila.Kalle wrote:

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

Assumed a 10k pullup. I am not sure about the pullup value, that person was referring to,

nor is a pullup mentioned in any one of the documents from TI.

You can see the 10k pullup in my setup, in the attached picture.

I have posted the query on this aspect on the TI forum, no reply yet though.

https://e2e.ti.com/support/applications/motor_drivers/f/38/t/677844

The 10k pullup improved the rise speed/slope on the SDO line. Also the logic level seems to be around 1.9V

One important aspect to note is that the READ's are consistent right now;

ie, whether the scope is connected, or when the Prescaler is switched back from 256 to 2.

But still, the Read's are not consistent with the expected default values as defined in the datasheet.

The logs and waveform snapshots are within the PDF document.

________________ Attachments : DRV8305_SPI_Debugging_SCLK-SDO-10k-Pullup.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxq6&d=%2Fa%2F0X0000000b1E%2FYdI9uelZPJwUKPzWx.AybdAP2E0ZrCsYMlrV8TyCcJw&asPdf=falseDRV8305-Q1EVM_SCH.PDF : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxop&d=%2Fa%2F0X0000000b1G%2Fy_dEIWxAUwy.vZZQ.V10wKzVTQcopoI6uz05VUnna9I&asPdf=false20180405_151158.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxpm&d=%2Fa%2F0X0000000b1C%2FGjk2uYK765W4aorTipBdN6CU2XUH6lPLDUVD.NTNu48&asPdf=false20180405_151059.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxpw&d=%2Fa%2F0X0000000b1D%2F_jQmtKtrkxR2sA8feD1pRhoSajNrXSuqfrr0J_Zw9tg&asPdf=false

[Manu Abraham]

Posted on April 05, 2018 at 14:10

One minor issue in the code: The data length is 11bits long not 10 bits, as a result the mask should've been 0x7ff and not 0x3ff in the spi_read() and spi_write() routines.

But still no joy, after fixing this.

[T J]

Posted on April 05, 2018 at 14:40

with long or heavy wires, SDI likes a pullup.

at 50cm, our LCD was responding correctly without a pullup.

did you set the IO pin clock to high speed ?

you can have a closer look at these lines in your code...   

printf('RD REG:0x%02x=0x%02x\r', reg, (SPI1->DR & 0x3ff));

SPI1->DR = DRV8305_RD | (reg << 11);

I am a novice in C but I cant see that you have specifically type cast  SPI1->DR this to 8 or 16bits.

page 13 of the data sheet shows specifically 8 bit transfers.

[Manu Abraham]

Posted on April 05, 2018 at 15:25

The wires are about 15 - 20cm utmost maximum long, not more than that.

I tried your suggestion to set GPIO speed to 50MHz, but no visible effect at all.

    __GPIOA_CLK_ENABLE();                /* GPIOA Clk            */

    pio.GPIO_Pin        = PIN_4 | PIN_5 | PIN_6 | PIN_7;/* NSS:A.4, SCK:A.5, MISO:A.6, MOSI:A.7    */

    pio.GPIO_Mode        = GPIO_Mode_AF;    pio.GPIO_Speed        = GPIO_Speed_50MHz;    GPIO_Init(GPIOA, &pio);

But my thought on this aspect: When using the Alternate Function (AF) to select the hardware SPI peripheral, does the GPIO Clock setting have any effect on the SPI peripheral I/O lines ?

I did try casting the Control Word written out to the SPI data Register:

    SPI1->DR = ((DRV8305_RD | ((reg & 0x1f) << 11)) & 0xffff);

The Reads still do remain the same:

Read Reg1-12

--------------------------------RD REG:0x01=0x01RD REG:0x02=0x01RD REG:0x03=0x01RD REG:0x04=0x01RD REG:0x05=0x301RD REG:0x06=0x301RD REG:0x07=0x201RD REG:0x08=0x01RD REG:0x09=0x01RD REG:0x0a=0x01RD REG:0x0b=0x101RD REG:0x0c=0x201

I am slightly confused when you mentioned that the DRV8305 expects 8 bit transfers. If you look at 7.5.1.2 SPI Format Figure: 17 SPI Slave Mode Timing Diagram on Page 34, it describes a 16 bit SPI transfer doesn't it ? Or maybe I misunderstood ?

Additionally, the comments say:

The SPI input data (SDI) word consists of a 16-bit

word with a 5-bit command and 11 bits of data. The SPI output data (SDO) word consists of 11 bits of registerdata with the first 5 bits (MSB) as don't cares.

and

• Full 16 SCLK cycles.

argh! my head has got into an indefinite loop.