Announcements

The EV market is bigger and better than ever. Join the EV Webinar to find out how you could best utiilize Smart Power Switches for EVs.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

Smart Power Switches Forum Discussions

bob-engineer
Level 1
Level 1
First solution authored 5 replies posted First reply posted

I have several high side drivers in an SPI daisy chain, including TLE75080.  When I send a message to the daisy chain, it seems to write correctly to the chips, as I can control turning channels on and off.  However the message I receive back from the daisy chain is the previous message that I sent the daisy chain.  So the read aspects of the daisy chain look like it's just one big shift register, sending back the previous inbound message.

Any ideas on what's going on here?  It's weird that write is working, but read isn't.

0 Likes
1 Solution
bob-engineer
Level 1
Level 1
First solution authored 5 replies posted First reply posted

Hi Xiangrui,

We've resolved the issue.  It looks like the key was adding some delays in the code to ensure the timing requirements relating to CSN were met, e.g. tCSN(td).

Thanks for your help on this - much appreciated.

Best regards,

bob-engineer.

View solution in original post

0 Likes
9 Replies
Xiangrui
Moderator
Moderator
Moderator
50 solutions authored First question asked 50 sign-ins

Hi,

the sequence of commands to “read” and “write” the content of a register looks as follows:

SPI.png

SPI communication will send back the previous content which has written in register after write and read process.

Best regards,

Xiangrui

0 Likes
Hi Xiangrui,

Thanks for your response.

To go into more detail about this issue, here's an example:

1. I send a "read OUT" command (0x4002), and as part of the transaction
of course I read and write the 16 bits.
2. Next transaction I send another command, but this time I expect to
receive the response to "read OUT" command. Instead, I receive 0x4002,
i.e. the command rather than the response.

I don't understand why this is happening.

Best regards bob-engineer
0 Likes

Hi,

Xiangrui_0-1673416813277.png

This is the SPI daisy chain capability. If you have multiple devices in daisy chain, there will be a delay for receiving the response of your command, because it is now in the previous device.

In the SPI block of each device, there is one shift register where each bit from SI line is shifted in each SCLK. The bit shifted out occurs at the SO pin.

So, try to read the next transaction and check if it is your expected response.

Best regards,

Xiangrui

0 Likes
bob-engineer
Level 1
Level 1
First solution authored 5 replies posted First reply posted

Hi Xiangrui,

Thanks for that.   I'm across how the daisy chain works.

The situation is that  I clock in a command, in the relevant bytes within the daisy chain.  Then, following the next transaction, I look at the relevant bytes within the daisy chain, and expect to see the response.  But what I see is the command.

Best regards, bob-engineer.

0 Likes

So, the question is how many slaves in your daisy chain? 

And is the next byte your response for the command?

BR

0 Likes
There are 4 devices, for a total daisy chain of 6 bytes.  The first device is the TLE75080.
 
So the 2 transactions look like:
 
TRANSACTION 1
Transmit: 0x40 0x02 (then 4 bytes relating to the other chips)
Receive: not relevant.
 
TRANSACTION 2
Transmit: 0x01 0x01 (then 4 bytes relating to the other chips)
Receive: 0x40 0x02 (then 4 bytes relating to the other chips)
 
BR
0 Likes

Hi,

Has the content been received in transaction 3?

BR,

Xiangrui

0 Likes
bob-engineer
Level 1
Level 1
First solution authored 5 replies posted First reply posted

Hi Xiangrui,

I have the code in a loop, sending alternately "0x00 0x01" (=read standard diagnosis) and "0x40 02" (=read OUT register).  What I see is:

Transaction 1

  • tx: (4 bytes relating to the other chips) 0x40 0x02
  • rx: (4 bytes relating to the other chips) 0x00 0x01

Transaction 2

  • tx: (4 bytes relating to the other chips) 0x00 0x01
  • rx: (4 bytes relating to the other chips) 0x40 0x02

Transaction 3

  • tx: (4 bytes relating to the other chips) 0x40 0x02
  • rx: (4 bytes relating to the other chips) 0x00 0x01

etc

I've tried various baud rates, but currently on 62.5kbit/s.

The board is a new version of an older design.  It worked in the last version of the board.  Changes we have made include a new micro.  Also the design has been changed to add all the protection resistors shown in section 11 of the datasheet.  Any chance these can cause an issue?

Best regards,

bob-engineer

 

 

0 Likes
bob-engineer
Level 1
Level 1
First solution authored 5 replies posted First reply posted

Hi Xiangrui,

We've resolved the issue.  It looks like the key was adding some delays in the code to ensure the timing requirements relating to CSN were met, e.g. tCSN(td).

Thanks for your help on this - much appreciated.

Best regards,

bob-engineer.

0 Likes