# WP8548 I2C bus lock up when read ADC2 and ADC3 **URL:** \ **Category:** mangOH Green\ **Created:** [December 13, 2018, 11:40am UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244 "2018-12-13T11:40:44Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![svaliente](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@svaliente](https://mangoh.discourse.group/u/svaliente)\ **Post date:** [December 13, 2018, 11:40am UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244/1 "2018-12-13T11:40:44Z")
Hello, I have this problem several months ago. In my program, the I2C lock up in a few minutes or hours. I use I2C bus to read two external chips and I need to read the four internal ADCs. In this document, they talk about this problem on page number 34: [https://source.sierrawireless.com/resources/airprime/software/release\_notes/wpx5xx-release-16,-d-,1-customer-release-notes/](https://source.sierrawireless.com/resources/airprime/software/release_notes/wpx5xx-release-16,-d-,1-customer-release-notes/) It says that the problem was solved in release 13, but I’m using de 16.1 release and I have de same problem. I have done a basic program in which only read the ADC2 and 3, and read an external i2C chip periodically. I run this program in Mangoh Green and the I2C bus lock up in about 10 minutes. Anyone had this problem? What can I do? Is Sierra going to fix this error? ---
**Author:** ![johnn](https://avatars.discourse-cdn.com/v4/letter/j/f0a364/32.png) [@johnn](https://mangoh.discourse.group/u/johnn)\ **Post date:** [January 11, 2019, 11:47am UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244/2 "2019-01-11T11:47:50Z")
Hi, I’m having the same problem you described using release 16.1, MCU 002.004. If I keep reading an external i2c address or I keep reading an adc in a loop, it take a long time before i2c hangs. If I don’t i2c hangs in roughly a few to 10 minutes. I have the exact same issue using WP7502 and WP7702! Did you find a solution? ---
**Author:** ![svaliente](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@svaliente](https://mangoh.discourse.group/u/svaliente)\ **Post date:** [January 11, 2019, 1:01pm UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244/3 "2019-01-11T13:01:30Z")
hello! No, I haven’t found a solution… I await Sierra’s answer. Do you hang it in a few minutes if you read in a timer? ---
**Author:** ![johnn](https://avatars.discourse-cdn.com/v4/letter/j/f0a364/32.png) [@johnn](https://mangoh.discourse.group/u/johnn)\ **Post date:** [January 11, 2019, 2:45pm UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244/4 "2019-01-11T14:45:48Z")
this is what i have found out so far. Running an application which reads out adc and an external accelerometer every 2 seconds and reads out the temperature every minute. Then the i2c bus hangs after roughly 10 minutes. Running an application which reads out adc every 2 seconds and reads out the temperature every minute. Then the i2c bus hangs after roughly 10 minutes. Running an application which reads out adc every 2 seconds and reads out the temperature every minute. And i have a loop at command line which continuously reads out something (cm adc read EXT\_ADC2 or an i2cget …) every second or faster. Then the i2c bus stays alive. Strange! If i don’t do anything with the i2c bus. Then the i2c bus stays alive. I am wondering if it has something to do with the powerdown/sleep of the MCU at address 0x3A. What I can measure is that the whole i2c protocol works as expected. However, when the bus fails. It fails with the error: qup\_i2c qup\_i2c.0: i2c\_scl: 1, i2c\_sda: 1 qup\_i2c qup\_i2c.0: Bus still busy, status 132100 qup\_i2c qup\_i2c.0: Transaction timed out, SL-AD = 0x3A qup\_i2c qup\_i2c.0: I2C Status: 132100 qup\_i2c qup\_i2c.0: QUP Status: 0 qup\_i2c qup\_i2c.0: OP Flags: 10 And if i measure the SCL and SDA line I can see that they are both high, SCL asserted low as start, but SDA also goes low. Then both immediatly return high. Meaning a bus busy condition which it cannot recover from. ---
**Author:** ![johnn](https://avatars.discourse-cdn.com/v4/letter/j/f0a364/32.png) [@johnn](https://mangoh.discourse.group/u/johnn)\ **Post date:** [January 11, 2019, 3:25pm UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244/5 "2019-01-11T15:25:48Z")
I don’t have time this weekend but I thing I am going to investigate some time in this topic: [https://community.nxp.com/thread/316813](https://community.nxp.com/thread/316813) ---
**Author:** ![svaliente](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@svaliente](https://mangoh.discourse.group/u/svaliente)\ **Post date:** [January 14, 2019, 11:46am UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244/6 "2019-01-14T11:46:01Z")
Yes… it looks that a I2C internal slave inside WP85 is hang up and the sistem can’t reset it. If you read the ADC 2 and ADC3 and a external I2C whit the address doesn’t exist, the bus too hang. I think that de problem is internal. Why does it hang? Is periodic, isn’t noise, isn’t external hardware. How do the internal I2C devices reset without restarting all the module? I don’t know… ---
**Author:** ![johnn](https://avatars.discourse-cdn.com/v4/letter/j/f0a364/32.png) [@johnn](https://mangoh.discourse.group/u/johnn)\ **Post date:** [January 14, 2019, 4:14pm UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244/7 "2019-01-14T16:14:26Z")
In order to find the cause of this problem I turned on more debug information using the yocto build. With menuconfig one can turn on “I2C Core debugging messages” and “I2C Bus debugging messages”. Strange enough, my program is running stable for over two hours now… The downside is that this uses extra processing time. The problem might be a timing issue in the driver? ---
**Author:** ![svaliente](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@svaliente](https://mangoh.discourse.group/u/svaliente)\ **Post date:** [January 15, 2019, 6:33am UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244/8 "2019-01-15T06:33:00Z")
> [@johnn](#): > > In order to find the cause of this problem I turned on more debug information using the yocto build. > With menuconfig one can turn on “I2C Core debugging messages” and “I2C Bus debugging messages”. > > Strange enough, my program is running stable for over two hours now… > The downside is that this uses extra processing time. > > The problem might be a timing issue in the driver? 30/5000 well, sooner or later it will fail. It’s a good idea. I didn’t know this. This will give us more information, but I don’t know if it will has solution or is a problem for Sierra. They don’t respond at the moment… it is a known problem for them. We’ll see what happens Greetings ---
**Author:** ![johnn](https://avatars.discourse-cdn.com/v4/letter/j/f0a364/32.png) [@johnn](https://mangoh.discourse.group/u/johnn)\ **Post date:** [January 15, 2019, 9:32am UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244/9 "2019-01-15T09:32:32Z")
Hi, Yes after 3 hours it failed. using the debug information I would guess it could be an IRQ issue in the driver. When I read and address from an i2c device using i2cget -y 0 0x19 0x31, I get the following dmesg output: When everything works good: [139.488264] i2c i2c-0: ioctl, cmd=0x705, arg=0xbe8b7ba4 [139.488325] i2c i2c-0: ioctl, cmd=0x703, arg=0x19 [139.488356] i2c i2c-0: ioctl, cmd=0x720, arg=0xbe8b7b80 [139.488386] i2c i2c-0: master\_xfer[0] W, addr=0x19, len=1 [139.488417] i2c i2c-0: master\_xfer[1] R, addr=0x19, len=1 [139.488478] qup\_i2c qup\_i2c.0: Polling for state:0x0, or valid-only:0 [139.488509] qup\_i2c qup\_i2c.0: Polling for state:0x10, or valid-only:0 [139.488539] qup\_i2c qup\_i2c.0: Qup config is :0x20f [139.488539] qup\_i2c qup\_i2c.0: Qup state is :0x1c [139.488570] qup\_i2c qup\_i2c.0: Qup mode is :0xa5 [139.488600] qup\_i2c qup\_i2c.0: Polling for state:0x0, or valid-only:1 [139.488631] qup\_i2c qup\_i2c.0: Polling for state:0x1, or valid-only:0 [139.488631] qup\_i2c qup\_i2c.0: Qup config is :0x20f [139.488661] qup\_i2c qup\_i2c.0: Qup state is :0x1d [139.488692] qup\_i2c qup\_i2c.0: Qup mode is :0xc0a5 [139.488722] qup\_i2c qup\_i2c.0: Polling for state:0x0, or valid-only:1 [139.488722] qup\_i2c qup\_i2c.0: Polling for state:0x3, or valid-only:0 [139.488753] qup\_i2c qup\_i2c.0: Qup config is :0x20f [139.488783] qup\_i2c qup\_i2c.0: Qup state is :0x1f [139.488783] qup\_i2c qup\_i2c.0: Qup mode is :0xc0a5 [139.488814] qup\_i2c qup\_i2c.0: WR:Wrote 0x2310132 to out\_ff:0xd004e110 [139.488844] qup\_i2c qup\_i2c.0: RD:Wrote 0x4010133 to out\_ff:0xd004e114 [139.488875] qup\_i2c qup\_i2c.0: Polling for state:0x0, or valid-only:1 [139.488905] qup\_i2c qup\_i2c.0: Polling for state:0x1, or valid-only:0 [139.488905] qup\_i2c qup\_i2c.0: idx:8, rem:1, num:2, mode:0 [139.488936] qup\_i2c qup\_i2c.0: Qup config is :0x20f [139.488966] qup\_i2c qup\_i2c.0: Qup state is :0x1d [139.488966] qup\_i2c qup\_i2c.0: Qup mode is :0xc0a5 [139.489302] qup\_i2c qup\_i2c.0: QUP intr= 187, i2c status=0x116300, qup status = 0x0 [139.489333] qup\_i2c qup\_i2c.0: Qup config is :0x20f [139.489333] qup\_i2c qup\_i2c.0: Qup state is :0x1d [139.489363] qup\_i2c qup\_i2c.0: Qup mode is :0xc0a5 [139.489424] qup\_i2c qup\_i2c.0: pos:1, len:1, cnt:0 [139.491774] qup\_i2c qup\_i2c.0: QUP\_Power: Inactivity based power management [139.491805] qup\_i2c qup\_i2c.0: Polling for state:0x0, or valid-only:1 [139.491835] qup\_i2c qup\_i2c.0: Polling for state:0x0, or valid-only:0 When the i2c bus fails: [67853.065458] i2c i2c-0: ioctl, cmd=0x705, arg=0xbeaedba4 [67853.065519] i2c i2c-0: ioctl, cmd=0x703, arg=0x19 [67853.065549] i2c i2c-0: ioctl, cmd=0x720, arg=0xbeaedb80 [67853.065580] i2c i2c-0: master\_xfer[0] W, addr=0x19, len=1 [67853.065610] i2c i2c-0: master\_xfer[1] R, addr=0x19, len=1 [67853.065671] qup\_i2c qup\_i2c.0: Polling for state:0x0, or valid-only:0 [67853.065702] qup\_i2c qup\_i2c.0: Polling for state:0x10, or valid-only:0 [67853.065732] qup\_i2c qup\_i2c.0: Qup config is :0x20f [67853.065763] qup\_i2c qup\_i2c.0: Qup state is :0x1c [67853.065763] qup\_i2c qup\_i2c.0: Qup mode is :0xa5 [67853.065793] qup\_i2c qup\_i2c.0: Polling for state:0x0, or valid-only:1 [67853.065824] qup\_i2c qup\_i2c.0: Polling for state:0x1, or valid-only:0 [67853.065855] qup\_i2c qup\_i2c.0: Qup config is :0x20f [67853.065855] qup\_i2c qup\_i2c.0: Qup state is :0x1d [67853.065885] qup\_i2c qup\_i2c.0: Qup mode is :0xc0a5 [67853.065916] qup\_i2c qup\_i2c.0: Polling for state:0x0, or valid-only:1 [67853.065946] qup\_i2c qup\_i2c.0: Polling for state:0x3, or valid-only:0 [67853.065946] qup\_i2c qup\_i2c.0: Qup config is :0x20f [67853.065977] qup\_i2c qup\_i2c.0: Qup state is :0x1f [67853.066007] qup\_i2c qup\_i2c.0: Qup mode is :0xc0a5 [67853.066038] qup\_i2c qup\_i2c.0: WR:Wrote 0x2310132 to out\_ff:0xd004e110 [67853.066038] qup\_i2c qup\_i2c.0: RD:Wrote 0x4010133 to out\_ff:0xd004e114 [67853.066068] qup\_i2c qup\_i2c.0: Polling for state:0x0, or valid-only:1 [67853.066099] qup\_i2c qup\_i2c.0: Polling for state:0x1, or valid-only:0 [67853.066129] qup\_i2c qup\_i2c.0: idx:8, rem:1, num:2, mode:0 [67853.066129] qup\_i2c qup\_i2c.0: Qup config is :0x20f [67853.066160] qup\_i2c qup\_i2c.0: Qup state is :0x1d [67853.066190] qup\_i2c qup\_i2c.0: Qup mode is :0xc0a5 [67853.103211] qup\_i2c qup\_i2c.0: i2c\_scl: 1, i2c\_sda: 1 [67853.107454] qup\_i2c qup\_i2c.0: Bus still busy, status 132100 [67853.113802] qup\_i2c qup\_i2c.0: Transaction timed out, SL-AD = 0x19 [67853.119509] qup\_i2c qup\_i2c.0: I2C Status: 132100 [67853.124576] qup\_i2c qup\_i2c.0: QUP Status: 0 [67853.128421] qup\_i2c qup\_i2c.0: OP Flags: 10 [67853.133182] qup\_i2c qup\_i2c.0: QUP\_Power: Inactivity based power management [67853.133213] qup\_i2c qup\_i2c.0: Polling for state:0x0, or valid-only:1 [67853.133244] qup\_i2c qup\_i2c.0: Polling for state:0x0, or valid-only:0 @svaliente did you create a bug report somewhere? How do you know sierra is aware of the problem? Greetings. ---
**Author:** ![svaliente](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@svaliente](https://mangoh.discourse.group/u/svaliente)\ **Post date:** [January 15, 2019, 12:25pm UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244/10 "2019-01-15T12:25:20Z")
Hello, In this document they talk about the same problem. [https://source.sierrawireless.com/resources/airprime/software/release\_notes/wpx5xx-release-16,-d-,1-customer-release-notes/](https://source.sierrawireless.com/resources/airprime/software/release_notes/wpx5xx-release-16,-d-,1-customer-release-notes/) ![Sin%20t%C3%ADtulo](https://us1.discourse-cdn.com/flex016/uploads/mangoh/original/1X/9d8a60b7569618a572a503bb9c2b309c52da11c7.jpeg) I have send this problem to my distributor and I’m waiting… ---
**Author:** ![svaliente](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@svaliente](https://mangoh.discourse.group/u/svaliente)\ **Post date:** [January 17, 2019, 6:46am UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244/11 "2019-01-17T06:46:30Z")
If I’ve news, I telly ou, of course! ---
**Author:** ![svaliente](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@svaliente](https://mangoh.discourse.group/u/svaliente)\ **Post date:** [January 28, 2019, 9:43am UTC](https://mangoh.discourse.group/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/2244/12 "2019-01-28T09:43:36Z")
Hi, johnn I received an answer in this forum: > **[WP8548 I2C bus lock up when read ADC2 and ADC3](https://forum.legato.io/t/wp8548-i2c-bus-lock-up-when-read-adc2-and-adc3/3942)** > > Hello, I have this problem several months ago. In my program, the I2C lock up in a few minutes or hours. I use I2C bus to read two external chips and I need to read the four internal ADCs. In this document, they talk about this problem on page... regards