Hi Krzysztof On Fri, 29 Sept 2023 at 11:53, Krzysztof Hałasa <khalasa@xxxxxxx> wrote: > > Hi, > > I am debugging certain IMX290 and IMX462 I2C failures on an NXP > i.MX6MP based board and there seem to be interesting "feature" here: > Sony IMX290 and IMX462 image sensors apparently terminate I2C transfers > after 2^18 of their master clock cycles. For example, with a typical > 37.125 MHz clock oscillator, this means about 7 ms. In practice, I'm > barely able to read a block of 128 registers (at I2C 400 kHz clock > rate). > > I think the sensors simply disconnect from the bus after 2^18 clock > cycles (starting from the first START condition, the repeated STARTs > don't reset the timeout). This means, in case of a READ operation, the > data read by the CPU after the timeout contains all bits set to 1. > i.MX8MP detects arbitration losses, so if the SDA change to 1 happens on > high clock value (but not on ACK bit), the whole transfer is aborted. > Otherwise, the ending bytes are simply set to FF (and the last non-FF > may be corrupted partially). > > The problem is 7 ms is a short time and on a non-real time system even > a simple non-DMA I2C register writes can take as much time. This causes > driver failures. What's your requirement to be able to read back so many registers at once? Whilst potentially useful during development, most sensor drivers write specific registers but never read anything other than potentially a model ID register during probe. Large block writes are generally not possible as at least the IMX290 datasheet does state "Do not perform communication to addresses not listed in the Register Map", and there are numerous reserved blocks throughout the map. As far as I know there's no OTP on these sensors which would be about the only reason I can think of for needing to read large blocks. I currently can't see a reason for a sensor driver to be needing to do these big reads, so how can it cause a driver failure? Scanning the IMX290 datasheet further, there is a slightly worrying paragraph in "Register Communication Timing (I2C)": "In I2C communication system, communication can be performed excluding during the period when communication is prohibited from the falling edge of XVS to 6H after (1H period)." and the diagram shows a 1 line period 6 lines after XVS which is marked "communication prohibited period". Ouch! I've never experienced issues with I2C comms to these modules, but is it possible that you're hitting this period with your longer I2C transactions? A logic analyser looking at XVS, XHS, and the I2C might give you some clues. Or are you not streaming when you're doing these transactions? IMX462 appears to list a similar restriction. Dave > Needless to say, the datasheets know nothing about the feature. > > Any thoughts? > -- > Krzysztof "Chris" Hałasa > > Sieć Badawcza Łukasiewicz > Przemysłowy Instytut Automatyki i Pomiarów PIAP > Al. Jerozolimskie 202, 02-486 Warszawa
