New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TLE493D getting stuck (maybe defective) #6
Comments
Hello @bluetiger9 , It seems you are experience similar issue to me, reported here. After some experimenting I have found that it has nothing to do with XMC for Arduino Core, now I am trying to read the sensor from Arduino Zero and I got TLE493D_BUS_ERROR I am noticing the BUS error is because the address command after the I2C start returns NACK, then the rest of the I2C command don't show up. Also my sensor works since I can see the /INT signal on SCL line going low, Because I cannot even communicate with this sensor I cannot modify the /INT behavior. Notice that thou the library seems to fail in the address command, I have been able to detect the address of my sensor (A1 = 0x22) using the I2C_scanner code such as I have other two different sensors on my board. I am using a custom board with TLE493D_W2B6A1 sensor. |
Just checked and I have these interrupt(?) signals on the CLK line too: Additionally, I see normal I2C clock signals too: But the sensor just returns ZERO-s. It may be some issue with the initialization. I'm not sure if the @Infineon, could this interrupt signals mess up the I2C communication? Is there is know workaround for this problem? We would really need help on this. Thanks, |
It might happen that the Interrupt /INT signal screw up the I2C communication but in this case you would see it in the scope, for example look here for clock stretching and collision avoidance. Have you examine the SDA line ? You should see at least the start and address waveform. This is what begins does
The function setAccessMode set or clear some bits such CA and /INT depending on your setting. The problem is that is not taken effect since the sensor is responding with NACK. Could you check if your sensor respond with NACK too? |
Having had some time to read the TLE493D-W2B6 User Manual I would suggest looking at page 28 Loss of VDD impact on I2C bus and if you are seeing NACKs then device is not responding and no further data should be sent from a microcontroller or read from the sensor as per I2C specification, the whole point of the NACK on the address stage is to signify the device is not there or not responding. Returning zeros and no error code is not helpful and more likely returning zeros as not been updated with values as the unit does not respond I suggest looking at least at Section 2.3 (Page 25 of the manual) *Sensor reset by I2C", how to reset the sensor when the sensor gets confused.. Possibly always doing this some time after startup with a small delay before doing a begin Word of warning you have to hard code toggling of GPIO lines to achieve this, and not use the I2C functions to force the clock and data to behave as needed ignoring NACKs and address/data types to proceed. |
Brief look at the code shows that the inbuilt reset sensor function does NOTHING , perhaps this should be implemented by someone.
|
Perhaps is because there is some issue for this sensor during reset as reported #4 I haven't tried myself the commented code since recently is when I got my sensor to respond the address The reset command is actually called before anything so it might be a reason.
the tle493d::readOut(&mInterface); instruction above respond the address with ACK but I don't see the default values for the registers, actually the readOut command called that way read the 23 registers of the device, here a scope view of the 23 transactions A closer look (not all the 23 ) The first two It seems they all return FF, but I can clearly see the ACK=0 at the end of each register read. I am not sure but perhaps the read is to have a copy of the registers values and any further modification will use those values accordingly. |
Hi @techpaul, @mhanuel26, First of all, please ignore the part with @mhanuel26, the SDA line seems to be fine. Here is an example: @techpaul, @mhanuel26 I tried to implement an I2C reset, but does not seems to have too much effect:
I tried to call this on start and on Any idea on how to continue the investigation? Thanks, |
I found on my arduino Zero, a problem while trying to write to a specific register address,
produces even if the register address 11h was responded with ACK, the data value and stop command is missing. I found that some people is using twice the library begin function, which sound like dummy but actually in some cases it might work, the logic is the begin function always try to set 1 byte command mode by using setRegBits(tle493d::PR, oneByteRead); Then other MOD1 flags are set as well, read here if in doubt In my case of arduino zero, the problem might be because the write register command never goes thru. But the begin calling twice logic is that as pointed documentation, the PR bit is set in 2 byte mode by default, and because the first time the begin is called it tries to read from address 0 the 23 registers such if it is in one byte mode. I have a hard time to test the library on the XMC S2Go device, the I2C is somehow "buggy", for example the Scan command never get to read my device with address 0x22. The library fails to build on a Atmel device such atmega 328. |
Nice. Does that code gets stuck somewhere or it returns? I see that the SCL line is not released, but I think it should be released by I tried to call I tried the I2C scan too at a moment. As I remember, the device was sometimes detected, sometimes not. |
First of all some I2C Basics (the I2C spec is available here, which is the latest one I personally have dealt with I2C for many years from bit-banging through using bus controllers as separate chips to hardware implementations of controllers and devices in FPGAs up to 3.4 Mb speeds. I actually still have a printed copy of the original application note by Mullard dated 1980 on my shelves I2C has various clock speeds and the main constraints on timing are
At 100kHz the minimum Clock times are
Longer timings are allowed which just makes the bus slightly slower as 100 kHz is the max speed for that type of setting. The Clock Low time is the same as time bewteen STOP and START and RESTART. Yes you can run I2C at very slow speeds like 1Hz or slower. If in doubt use 5 us for total clock high or low times when bit banging. At a start condition ALL devices on I2C bus should go into a state of recognising the bus is BUSY then clock in address, then for 9th Clock period ACK if the address matches the device, and is not busy internally. The only reason changing bits in the internal registers of a device should affect ACK/NACK is because it is Personally the reset the sensor sequence should have used the Software Reset function on write to address 0 (which is a RESERVED address for general call) (see Section 3.1.12 onwards in the spec) and address byte of 0xFF is Read to Device ID functions address (see Section 3.1.17). For a stuck bus (SDA or SCL stuck low and not in clock stretching, this is covered in Section 3.1.16 Bus Clear. I will have a look at the I2Creset code put up later which appears to have wrong timings and need to check the library functions available for what else is needed as after any device reset you need to do a begin again to set up parameters, probaly need a device.end to free up resources before reset as well. |
Hi can you try the newest code again? The solution is proposed here (tested with A2B6): TLE493D-3DMagnetic-Sensor/src/Tle493d.cpp Line 79 in 2c6aeaf
To avoid the glitch just write out the register twice. |
If you have any problems with the aforementioned workaround, please reopen or send a PR |
Hi,
I have some problems with a TLE493D / this library acting very strange. I'm not sure if the sensor is defective or it's a software problem.
Not sure which variant of the TLE493D it is, but here is a closeup:
https://hackster.imgix.net/uploads/attachments/500027/20180610_094241_8VdXg5Id29.jpg?auto=compress%2Cformat&w=1280&h=960&fit=max
So, sometimes the TLE493D / library works fine, but sometimes the sensor just gets stuck and nothing helps. Neither a complete power off on both the sensor and the micro-controller.
When the sensor is stuck the symptoms are one of the following:
.updateData()
returnsTle493d_Error::TLE493D_BUS_ERROR
.updateData()
returns withTle493d_Error::TLE493D_NO_ERROR
, but.getX()
,.getY()
,.getZ()
all returns ZERO-sWhen it works fine
.updateData()
returnTLE493D_NO_ERROR
and I have correct sensor values.Currently, I'm using the TLE493D connected directly to a nRF51, but I had this problem Sensor2Go board too.
I would need some help investigating this issue.
Thanks,
Attila
The text was updated successfully, but these errors were encountered: