Our device was built on Colibry PXA320 module with WinCE 5.0, image 3.8. Customers reported a (rare) problem of flashdisk corruption during poweroff. So we decided to upgrade to newer OS images. After sorting out some small incompatiblities of our software with WinCE 6.0 we stuck with malfunction of I2C bus.
Experiments showed that even examples from Toradex CE Libraries pack do not work properly with Win CE images 4.0 and newer. I have downloaded the last “old API” library set ToradexCeLibraries_2.0b4147-20171026 and played with I2cLibDemo. With images 3.8 and 3.9 it succefully reads registers of our custom RTC chip. (It is M41T0-mimicing so RTCsync.exe of image 3.8 works properly). But with 4.0+ images the same program fails to read or write anything from 0x68 address. Disabling the built-in RTCsync.exe via Launch48 key and hard rebooting doesn’t help at all.
Did we miss something important in upgrading process?
Tested on WinCE 6.0 ver 4.2. Built-in RTCSync.exe works as expected (so our RTC hardware is functioning correctly). But all versions of i2cLibDemo (old and new API) and CustomRTCsync project fail at I2C_init(*) function with exception or “Handle cannot be created” error.
Dear @Alexander
I’m afraid I cannot reproduce the problem.
I just downloaded the latest downloadable legacy libraries wincelib_v2_0bis_2868.zip, built the I2cLibDemo in VS2008, and let the executable run on a Colibri PXA320 V2.0B / Evalboard V3.2A. I attached the generated executable to this post:
I2C worked as expected: The initial writes didn’t produce any error, and the following bus scan detected the M41T0 at address 0x68.
I regenerated ToradexCeLibraries_2.0b4147-20171026 from source code (because I didn’t know where you found this download link) and repeated my test from above with an identical result - it was working fine.
So let’s focus on searching the difference in your configuration:
- Did you do all tests with the same module and carrier board
- Does the system with the non-working V4.x image possible use a differene hardware and/or software configuration?
– Different registry entries
– Different config block settings
– Another carrier board
– The module’s i2c pins broken
- Did you do a full power cycle (including backup battery) between the tests? The following situation could happen: If a system reset is done during an ongoing i2c read, the i2c slave which is then driving the SDA signal does not get clocked anymore and does not see the system reset, so it continues to pull the SDA signal low, basically blocking the bus. It needs a full power cycle or a special i2c recovery protocol to unblock this situation.
Regards, Andy
About library binaries: before writting here I had searched your community site thoroughly, downloaded all the libraries from i2c-related answers. So now I have a bunch of libraries sets and standalone i2cdemo projects - all of them give the same result (old images work, new images fail). I just forgot what was the latest official release to use it in last experiments before applying here.
Anyway, I did another series of tests with your I2cLibDemo.exe. All in the same way:
flashing the OS image (with clearing registry), flashing the e-boot image (to match your screenshot), total powering off, powering on, booting, copying the I2cLibDemo.exe to "", executing it. Attaching the results:
[upload|6ELPXWg3ojonY6OKbVJI1LE5dBs=] [upload|NJfXTm2PwLIagT6MCdpjBLHDoio=]
In 3.8 image the startup RTCSync.exe worked (see the tray clock!) and your I2cLibDemo.exe found our custom RTC and I/O contrloller. In 4.5 image both of them failed (note that in your own screenshot the tray clock also wasn’t updated, by the way).
I made the same experiment with the 4.2 image:
[upload|GjtVSxA1vaDXhQS1BznVIHFR8/I=]
Here the RTCSync.exe worked(!) but your I2cLibDemo.exe failed.
All this tests was done on the same hardware: Colibri PXA 320 on our custom carrier board (inside our device in fact). We made a lot of experiments beforehand - the effect is stable and depends only on OS image version. Our hardware developer reported that he observed the same behavior (failed RTCSync) with Colibry placed inside Orchide carier board but I will be able to check it myself only in Monday. He also said that with 4.3 (and newer) images oscilloscope shows I2C transmission choking after a handful of bytes (but in very different time points in consecutive runs).
I am also attaching the debug logs from 4.5 and 4.2 tests, but they do not add anything new:
link text
I have to mention - we also tested with changed pull-up resistors (to 10k and 1k) - it doesn’t make any differrence.
Dear @Alexander
I’m running out of ideas.
Can you send me the oscilloscope measurements? Maybe this helps us to understand what is happening.
If you send only the “choking” part, it would b good to know what it is related to (e.g. what was the last valid communication before i2c went mad).
(side note: the RTC in my tests is not updated, because I don’t have a backup battery connected, so my RTC contains an invalid time)
Regards, Andy
It looks like we have found some weird thing. With WinCE 6.0 ver. 4.5 (RTCSync disabled) we see the following signals when stepping over I2CInit() function in debugger:
Here top line is DATA, bottom is CLOCK.
So your I2C driver first issues STOP combination, then START combination with no following data. It looks like our slave I2C controller waits infinitely for the rest of this transmission and behave strangely when the real transmission begins. If we physically disconnect our controller from the bus before the I2CInit() function executes and connect it afterwards - all other transactions run smoothly.
In version 3.8 the same I2CInit() function behave differently - it issues STOP combination only if some of lines is in low state. Is there any way to avoid issuing START combination?
I still can see the picture, nevertheless added another copy of it to that comment. So now I see two similar images there.
Dear @Alexander
We’re getting closer to find and solve the error.
I agree with you
-
I see an almost identical sequence in my system (PXA320 V2.0B, CE6 V4.5) while RtcSync.exe is executed the first time, either during normal startup, or after booting with disabled RtcSync.exe, then starting RtcSync.exe manually.
In my case the final rising edges are swapped - SCL rises just before SDA. This is another STOP condition, but with timings out of spec.
CH1: SDA, CH2:SCL
-
This is obviously the source of errors.
The signals are generated by an i2c bus recovery algorithm in the initialization code of the i2c library, to always bring the i2c slaves into a known state after a reset.
I don’t agree with you:
- If I disable
RtcSync.exe ( [HKLM\Init] Launch48="xxxrtcsync.exe"), save the registry and reboot, I don’t see any activity neither on SCL nor on SDA. Both signals stay high for the full boot period.
This is true for both the V3.8 and V4.5 images.
Next Steps
-
Please identify which executables on your system use the i2c library, and thus generate the wrong signal pattern. I assume there is some program in an AutoRun folder or similar, which initializes the i2c even if RtcSync.exe is disabled.
-
We need to update all identified applications (or at least the one which gets executed last).
As I already found the problematic code, it should not be a big deal for me to update our libraries.
The integration of the updated library into your own executables will be your part.
Regards, Andy
- I can confirm - there is no activity on I2C bus if RTCSync is disabled (never stated the otherwise).
Last screenshot was made during step-by-step debugging of I2CLibDemo application. (RTCSync was disabled and it was the first run of I2CLibDemo.) Those strange signals was a result of calling the I2CInit() library function. The problem is that starting from ver 4.3 onwards RTCSync internally uses the similar bus reset procedure, it drives our I2C-controller out of sync and it can not respond properly.
- The I2C bus will be used by two applications:
-
RTCSync.exe (at startup and during manual time setting changes). Our I2C slave RTC is more or less M41T0-compatitable, at least it worked flawlessly with ver. 3.8 - 4.2 images.
-
Our main application (normally started with Autorun but now also disabled). It is easy to us to integrate the updated i2cLib, I have done this dozens of times in last two weeks. Actually I have tested almost all versions of the library and versions of OS image from your website.
Dear @Alexander
I modified the library to do a proper initialization - Only a STOP condition is generated. I also rebuilt the RTCSync.exe tool with this library.
You can find the download links below.
The measurements on my side look good now.
CH1: SDA, CH2:SCL
Please let me know whether this fixes your problems.
Regards, Andy
We have rebuild our application with updated libraries and tested on two our devices - both updated RTCsync and our application work as expected, thank you.
