I2c problem on 96b Carbon.


Iñaki Malerba <inakimmalerba@...>
 

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.
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@... | +54 02945 15468443


Yannis Damigos
 

Hi,

On Fri, Aug 4, 2017 at 12:27 AM, Iñaki Malerba <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

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@gmail.com | +54 02945 15468443
inaki@satellogic.com


_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users
Yannis


Iñaki Malerba <inakimmalerba@...>
 

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).

__
Martin Iñaki Malerba
inakimmalerba@... | +54 02945 15468443


On Fri, Aug 4, 2017 at 3:53 AM, Yannis Damigos <giannis.damigos@...> wrote:
Hi,

On Fri, Aug 4, 2017 at 12:27 AM, Iñaki Malerba <inakimmalerba@...> 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

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@... | +54 02945 15468443
> inaki@...
>
>
> _______________________________________________
> Zephyr-users mailing list
> Zephyr-users@lists.zephyrproject.org
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-users
>

Yannis


Yannis Damigos
 

On Fri, Aug 4, 2017 at 2:20 PM, Iñaki Malerba <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@gmail.com | +54 02945 15468443
inaki@satellogic.com


On Fri, Aug 4, 2017 at 3:53 AM, Yannis Damigos <giannis.damigos@gmail.com>
wrote:

Hi,

On Fri, Aug 4, 2017 at 12:27 AM, Iñaki Malerba <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

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@gmail.com | +54 02945 15468443
inaki@satellogic.com


_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users
Yannis


Iñaki Malerba <inakimmalerba@...>
 

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
(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@... | +54 02945 15468443


On Fri, Aug 4, 2017 at 8:48 AM, Yannis Damigos <giannis.damigos@...> wrote:
On Fri, Aug 4, 2017 at 2:20 PM, Iñaki Malerba <inakimmalerba@...> 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@... | +54 02945 15468443
> inaki@...
>
>
> On Fri, Aug 4, 2017 at 3:53 AM, Yannis Damigos <giannis.damigos@...>
> wrote:
>>
>> Hi,
>>
>> On Fri, Aug 4, 2017 at 12:27 AM, Iñaki Malerba <inakimmalerba@...>
>> 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
>>
>> 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@... | +54 02945 15468443
>> > inaki@...
>> >
>> >
>> > _______________________________________________
>> > Zephyr-users mailing list
>> > Zephyr-users@lists.zephyrproject.org
>> > https://lists.zephyrproject.org/mailman/listinfo/zephyr-users
>> >
>>
>> Yannis
>
>


Mani Sadhasivam
 

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@...> 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
(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@... | +54 02945 15468443


On Fri, Aug 4, 2017 at 8:48 AM, Yannis Damigos <giannis.damigos@...> wrote:
On Fri, Aug 4, 2017 at 2:20 PM, Iñaki Malerba <inakimmalerba@...> 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@... | +54 02945 15468443
> inaki@...
>
>
> On Fri, Aug 4, 2017 at 3:53 AM, Yannis Damigos <giannis.damigos@...>
> wrote:
>>
>> Hi,
>>
>> On Fri, Aug 4, 2017 at 12:27 AM, Iñaki Malerba <inakimmalerba@...>
>> 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
>>
>> 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@... | +54 02945 15468443
>> > inaki@...
>> >
>> >
>> > _______________________________________________
>> > Zephyr-users mailing list
>> > Zephyr-users@...ct.org
>> > https://lists.zephyrproject.org/mailman/listinfo/zephyr-users
>> >
>>
>> Yannis
>
>


_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users



Yannis Damigos
 

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?

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@gmail.com <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@gmail.com <mailto:inakimmalerba@gmail.com> | +54 02945 15468443
inaki@satellogic.com <mailto:inakimmalerba@gmail.com> 


On Fri, Aug 4, 2017 at 8:48 AM, Yannis Damigos <giannis.damigos@gmail.com <mailto:giannis.damigos@gmail.com>> wrote:

On Fri, Aug 4, 2017 at 2:20 PM, Iñaki Malerba <inakimmalerba@gmail.com <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@gmail.com <mailto:inakimmalerba@gmail.com> | +54 02945 15468443
> inaki@satellogic.com <mailto:inaki@satellogic.com>
>
>
> On Fri, Aug 4, 2017 at 3:53 AM, Yannis Damigos <giannis.damigos@gmail.com <mailto:giannis.damigos@gmail.com>>
> wrote:
>>
>> Hi,
>>
>> On Fri, Aug 4, 2017 at 12:27 AM, Iñaki Malerba <inakimmalerba@gmail.com <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@gmail.com <mailto:inakimmalerba@gmail.com> | +54 02945 15468443
>> > inaki@satellogic.com <mailto:inaki@satellogic.com>
>> >
>> >
>> > _______________________________________________
>> > 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>


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>
>
>