- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
the sequence of commands to “read” and “write” the content of a register looks as follows:
SPI communication will send back the previous content which has written in register after write and read process.
Best regards,
Xiangrui
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, the question is how many slaves in your daisy chain?
And is the next byte your response for the command?
BR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Has the content been received in transaction 3?
BR,
Xiangrui
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.