Re: I2c problem on 96b Carbon.


Mani Sadhasivam
 



On Thu, Aug 24, 2017 at 12:58 AM, Yannis Damigos <giannis.damigos@...> wrote:
Hi,

I just test I2C_1 using the latest master branch.
I am driving an oled display using I2C_1 on 96b_carbon just fine in both interrupt and polling modes.

Does interrupt mode works for you?


yikes... I was connecting to PB8/PB9 by looking at the pinout. But the default pinmux is configured for PB6/PB7 and it works
with the same.

It looks confusing with having two different I2C_1 labels in pinout. Anyway I can confirm that the communication works fine
with I2C_1 labelled at PB6/PB7.

Thanks,
Mani 
Yannis

On 08/23/2017 10:12 PM, Mani Sadhasivam wrote:
> Hello,
>
> I've observed the same issue on 96b_carbon while trying to communicate over I2C_1. In polling mode, it looks like carbon
> sends slave address and waits forever for the status of address sent in 'while (!LL_I2C_IsActiveFlag_ADDR(i2c)) {;}'


> I couldn't debug much because of the lack of debugger. However, I found that carbon supports I2C_2 on-board but it is not
> enabled properly. So, I have created a PR(https://github.com/zephyrproject-rtos/zephyr/pull/1235) for enabling that.
>
> With that PR I can use I2C_2 interface for communicating slave without any issues. After enabling CONFIG_I2C_2, I have 
> modified tmp112 sample application for tmp007 and read the temp values.
>
> I'm also planning to debug I2C_1 issue and I'll reply if I find more about it.
>
> Thanks,
> Mani
>
> On Fri, Aug 4, 2017 at 5:25 PM, Iñaki Malerba <inakimmalerba@... <mailto:inakimmalerba@gmail.com>> wrote:
>
>     I didn't check polling now, but it didnt work before. It talked a bit but then it recieved lots of zeros, as if it hangs on reading with the clock enabled.
>
>     The msg.flags things I talk about is this line:
>     https://github.com/ydamigos/zephyr/commit/9405d5555767d68553dfa19fcde6f41db39b383f#diff-9ff105b6f35c79a820c16955747b3685R99 <https://github.com/ydamigos/zephyr/commit/9405d5555767d68553dfa19fcde6f41db39b383f#diff-9ff105b6f35c79a820c16955747b3685R99>
>     (also in `handle_txe`).
>
>     If you have some minutes, we can chat or something.
>
>     Btw I tested the chip with an arduino and it worked perfectly.
>
>     __
>     Martin Iñaki Malerba
>     inakimmalerba@... <mailto:inakimmalerba@gmail.com> | +54 02945 15468443
>     inaki@... <mailto:inakimmalerba@gmail.com
>
>
>     On Fri, Aug 4, 2017 at 8:48 AM, Yannis Damigos <giannis.damigos@... <mailto:giannis.damigos@gmail.com>> wrote:
>
>         On Fri, Aug 4, 2017 at 2:20 PM, Iñaki Malerba <inakimmalerba@... <mailto:inakimmalerba@gmail.com>> wrote:
>         > Hi Yannis.
>         >
>         > Thanks for your answer.
>         >
>         > No luck.
>         >
>         > I found out yesterday it was looping on `handle_rxne` because i've commented
>         > a line.
>         >
>         > Now, cherrypicking that commit, gets looped on `handle_txe` as it doesnt
>         > generate the stop condition (`i2c_burst_read` adds the I2C_MSG_RESTART
>         > flag).
>
>         I don't think the problem is in i2c_burst_read. If you check the
>         driver code, STM32 I2C driver doesn't use msg.flags to generate a stop
>         condition.
>         I tested the I2C driver on olimexino_stm32 (stm32f103rb) and
>         96b_carbon (stm32f401re) boards, driving an oled display based on
>         ssd1306 chip at 400 kHz, using both interrupt and polling mode.
>
>         Did you also check polling mode?
>
>         I'll try to get an I2C slave device with read support to test it as
>         soon as possible.
>
>         Yannis
>
>         > __
>         > Martin Iñaki Malerba
>         > inakimmalerba@... <mailto:inakimmalerba@gmail.com> | +54 02945 15468443
>         > inaki@... <mailto:inaki@...>
>         >
>         >
>         > On Fri, Aug 4, 2017 at 3:53 AM, Yannis Damigos <giannis.damigos@... <mailto:giannis.damigos@gmail.com>>
>         > wrote:
>         >>
>         >> Hi,
>         >>
>         >> On Fri, Aug 4, 2017 at 12:27 AM, Iñaki Malerba <inakimmalerba@... <mailto:inakimmalerba@gmail.com>>
>         >> wrote:
>         >> > Hi everyone!
>         >> >
>         >> > I've been struggling with this problem for the last weeks. I cannot make
>         >> > it
>         >> > to comunicate my carbon board with an fxos8700 IMU.
>         >> >
>         >> > Enabling the interruptions mode on the i2c driver, I can see on the
>         >> > logic
>         >> > analyzer it sends the address of the byte to read, but it doesnt
>         >> > receives
>         >> > the answer.
>         >> > I tried my best to debug it with gdb and I get to the point where it
>         >> > gets
>         >> > looped on `handle_rxne` (drivers/i2c/i2c_ll_stm32_v1.c) with `data.len =
>         >> > 0`.
>         >> >
>         >> > I also have some doubts about some lines there. For example, how does it
>         >> > ack
>         >> > the message if it enters the first `if` with `data.len = 1` and then,
>         >> > when
>         >> > decreased, `data.len == 1` its false.
>         >>
>         >> You are right, the first `if` with `data.len = 1` should be nack and
>         >> not ack (probably I made a typo during driver development). In case a
>         >> single byte has to be received, the Acknowledge disable is made before
>         >> ADDR flag is cleared.
>         >>
>         >> Could you test the I2C read both in polling and interrupt mode with
>         >> the following branch? I only have a slave I2C display which supports
>         >> only write operations and I cannot test it myself.
>         >> https://github.com/ydamigos/zephyr/commits/i2c-read <https://github.com/ydamigos/zephyr/commits/i2c-read>
>         >>
>         >> If everything works fine, I will create a PR to fix it.
>         >>
>         >> > It doesnt  generate the stop bit either because the burst read sets
>         >> > `I2C_MESSAGE_RESTART` flag.
>         >> > Why does `i2c_reg_read_byte` uses burst read instead of normal read?
>         >> >
>         >> > Any help on this would be really apreciated, Im really stuck on here.
>         >> > __
>         >> > Martin Iñaki Malerba
>         >> > inakimmalerba@... <mailto:inakimmalerba@gmail.com> | +54 02945 15468443
>         >> > inaki@... <mailto:inaki@...>
>         >> >
>         >> >
>         >> > _______________________________________________
>         >> > Zephyr-users mailing list
>         >> > Zephyr-users@lists.zephyrproject.org <mailto:Zephyr-users@lists.zephyrproject.org>
>         >> > https://lists.zephyrproject.org/mailman/listinfo/zephyr-users <https://lists.zephyrproject.org/mailman/listinfo/zephyr-users>
>         >> >
>         >>
>         >> Yannis
>         >
>         >
>
>
>
>     _______________________________________________
>     Zephyr-users mailing list
>     Zephyr-users@lists.zephyrproject.org <mailto:Zephyr-users@lists.zephyrproject.org>
>     https://lists.zephyrproject.org/mailman/listinfo/zephyr-users <https://lists.zephyrproject.org/mailman/listinfo/zephyr-users>
>
>


Join users@lists.zephyrproject.org to automatically receive all group messages.