TLV493-A1B6 lockup crash bug and TLE493-A2B6 MOD2 problems

Announcements

Measure CO2 When It Matters - Infineon’s XENSIV™ PAS CO2 now comes in SparkFun Red. Check it now!

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

cross mob
RobNZ
Level 1
Level 1
5 replies posted 5 sign-ins First like given
Yashraj, thanks for your reply to my earlier question.
 
I don't want to be a grumpy bum, but I have spent a lot of time and effort and cash trying to get the TLE493D-A2B6 working, and I would like to say the following.
 
1. The datasheet could be improved a lot.
2. Simple example code would help a lot.
3. The reset code on your Github page is not finished !!!

4. But worst of all is the seemingly inconsistent behavior of the device. Let me explain.

On power up I reset the device by sending 0xFF 0xFF 0x00 0x00 with the start and stop conditions. (This is very badly explained in the datasheet imo btw.)

Next I configure the registers CONFIG and MOD1. I leave MOD2 alone as it has just one bit to change, and I can leave it at default.

The device is now working... I can read data from it, get the VERsion data etc.

However, if I add to my setup code a modification to MOD2, any subsequent reading of the device fails, except for one case that I have found.

If I set bit 7 (write 0x80) ---> subsequent reads fail.

If I send 0xFF, 0xE0, 0xC0, 0x00, these all cause read failure.

The only exceptions I can find is if I send 0x01 or nothing to MOD2. In these cases the device seems to work fine.

Now, perhaps I am doing something silly in my code, or perhaps MOD2 is broken, which would not surprise given how the poor design of the A1B6 device whose ADC randomly locked up requiring reset.

Very unhappy customer here.

So what exactly is hidden in MOD2 that would cause writes to it to break reads from the device?

0 Likes
1 Solution
Yashraj_P
Moderator
Moderator
Moderator
10 likes given 250 sign-ins 25 likes received

Hi @RobNZ ,

  1. MOD2 register has only 7th bit PRD available to configure, other bits are reserved for factory settings as mentioned in User Manual Section 1.2.4.
  2. PRD bit is only configured when the sensor is in Low Power Mode, set in MOD1 register 1:0 bits. Other modes you need not configure MOD2 register.
  3. The last thing you need to check is the odd parity of MOD1(0x11) and MOD2(0x13) register and set/reset the FP (7th bit of MOD1 register) accordingly.

Could you share the sample code you are using, or how are you setting up the registers.
Note: You don't need to initiate the Reset Sequence every time you power up.

Thanks & regards,
Yashraj

View solution in original post

0 Likes
5 Replies
RobNZ
Level 1
Level 1
5 replies posted 5 sign-ins First like given

In addition to the above, any idea why I have/INT turned off, yet still appear to see interrupt pulses appearing on SCL when collision avoidance is disabled? I think this happens after I write to MOD2.

0 Likes
Yashraj_P
Moderator
Moderator
Moderator
10 likes given 250 sign-ins 25 likes received

Hi @RobNZ ,

Could you share the register values of CONFIG, MOD1, and MOD2, that you are writing?
Also if you have access to oscilloscope/logic analyzer could you share the waveforms?

Thanks & Regards,
Yashraj

0 Likes
Yashraj_P
Moderator
Moderator
Moderator
10 likes given 250 sign-ins 25 likes received

Hi @RobNZ ,

  1. MOD2 register has only 7th bit PRD available to configure, other bits are reserved for factory settings as mentioned in User Manual Section 1.2.4.
  2. PRD bit is only configured when the sensor is in Low Power Mode, set in MOD1 register 1:0 bits. Other modes you need not configure MOD2 register.
  3. The last thing you need to check is the odd parity of MOD1(0x11) and MOD2(0x13) register and set/reset the FP (7th bit of MOD1 register) accordingly.

Could you share the sample code you are using, or how are you setting up the registers.
Note: You don't need to initiate the Reset Sequence every time you power up.

Thanks & regards,
Yashraj

0 Likes
RobNZ
Level 1
Level 1
5 replies posted 5 sign-ins First like given

Yashraj, thanks again for your replies.

The following is slightly off topic and comes from a Sensirion (another company) datasheet. It relates to i2c reset General Call command (0x00 0x06). Is this implemented in the TLE device? If not, then is Infineon following the i2c standards? What happens to the TLE device is it is on the same bus as the Sensirion device?

Reset through General Call

Additionally, a reset of the sensor can also be generated using the “general call” mode according to I2C-bus
specification. This generates a reset which is functionally identical to using the nReset pin. It is important to understand that a reset generated in this way is not device specific. All devices on the same I2C bus that support the general call mode will perform a reset. Additionally, this command only works when the sensor is able to process I2C commands."

0 Likes
Yashraj_P
Moderator
Moderator
Moderator
10 likes given 250 sign-ins 25 likes received

Hi @RobNZ ,

First of all sorry for the delay.

1. The TLE493D-A2B6, does not respond to General Call (0x00 0x06). 
2. Thus, won't be reset even if its on the same bus with other device. 

Additional info: This behavior will be true vice-versa, that means if you are resetting the TLE493D-A2B6 using the reset sequence Start 0xFF Stop, Start 0xFF Stop, Start 0x00 Stop, Start 0x00 Stop ), it shouldn't interfere with other devices on the same bus.

Thanks and regards,
Yashraj

0 Likes