Sep 03, 2018
09:52 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 03, 2018
09:52 PM
Hello! I am using TLE5012B via SSC interface (bit bang mode, not hardware spi, connection according to the datasheet). I write to sensor command 0x8012 (read angle value) and then i get two words (angle value + safety word). For example: command word: 0x8012, response words: 0xCDAC and 0x1F0B.
My calculated CRC is 0xED. But the CRC part in safety word is 0x0B. I must note that angle value is CORRECT during the 360 degrees of magnet rotating. Tell me please what's the problem? P.S. In attachment you can see the example of transaction.
My calculated CRC is 0xED. But the CRC part in safety word is 0x0B. I must note that angle value is CORRECT during the 360 degrees of magnet rotating. Tell me please what's the problem? P.S. In attachment you can see the example of transaction.
- Tags:
- IFX
6 Replies
Sep 04, 2018
01:44 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 04, 2018
01:44 AM
Please try one of the C-code samples provided in section "5.2.4 Cyclic Redundancy Check (CRC)" of the user's manual?
Sep 04, 2018
04:06 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 04, 2018
04:06 AM
Thanks for request! I am using CRC calculaton from datasheet. I am also using two variants of CRC calculation (with table and without) so i get the similar results.
Sep 04, 2018
04:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sep 04, 2018
04:09 AM
A need to note that somewhere in datasheet CRC calculation takes safety word too and somewhere to calculate CRC only need coomand word and response word (without safety word). Maybe i dont understand the algorithm..
Jan 25, 2019
05:02 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 25, 2019
05:02 AM
Hello, I have the same problem.
I am using the generating table from the datasheet and the algorithm from the section 5.2.4.
I can also generate the right CRC for the example from that section: CRC for 0x5081, 0x0804 = 0x89.
But I get the CRC error for the packets transmitted from the real device. And some more irritating points. If I try to calculate checksums with my (or yours algorithm) for the examples from the section 6.1.2 (figure 6-8), I get this values:
0xd0e1, 0x4820 = 0xf4
0x50e1, 0x4830 = 0x0d
0xdoe1, 0x4830 = 0x38
But from the sample example I see following CRCs: 0xf5, 0x63, 0x40.
What am I doing wrong??? Has the datasheet wrong info??
I have also noticed, that it is possible to get the right checksums for the examples if you calculate also the upper byte of the response word. But it contradicts the datasheet (see the beginning of the section 5.2.4)!
And it also doesn't help with calculating the right checksum for the original post (0x8012, response words: 0xCDAC and 0x1F0B).
This undefined behavior of the chip is really annoying.
I am using the generating table from the datasheet and the algorithm from the section 5.2.4.
I can also generate the right CRC for the example from that section: CRC for 0x5081, 0x0804 = 0x89.
But I get the CRC error for the packets transmitted from the real device. And some more irritating points. If I try to calculate checksums with my (or yours algorithm) for the examples from the section 6.1.2 (figure 6-8), I get this values:
0xd0e1, 0x4820 = 0xf4
0x50e1, 0x4830 = 0x0d
0xdoe1, 0x4830 = 0x38
But from the sample example I see following CRCs: 0xf5, 0x63, 0x40.
What am I doing wrong??? Has the datasheet wrong info??
I have also noticed, that it is possible to get the right checksums for the examples if you calculate also the upper byte of the response word. But it contradicts the datasheet (see the beginning of the section 5.2.4)!
And it also doesn't help with calculating the right checksum for the original post (0x8012, response words: 0xCDAC and 0x1F0B).
This undefined behavior of the chip is really annoying.
Jan 28, 2019
11:01 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jan 28, 2019
11:01 PM
Feb 18, 2019
06:21 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Feb 18, 2019
06:21 AM
forix wrote:
There is a library source code for Arduino available on github supporting TLE5012B. Check the source code here.
Thank you, but I have already compared Infineon source codes with mine. I don't see any differences. But I have found the right sequence. The first example from the datasheet is right, but the communication examples are completely wrong.