Date   

nRF52832 hardware cycle count freezing at chip start

Thiago Silveira
 

Hi everyone,

We've been having some strange problem lately. When nRF52832 powers up, our code starts running, but the hardware cycle count (calling k_cycle_get_32(), for example) remains static at zero for some time (one to two minutes).
Therefore, when we call k_sleep or k_busy_wait, the code stops there and hangs in the k_busy_wait while loop, as the hardware cycle count is not counting.
After a while, the chip restarts by itself (watchdog wasn't configured by this point), and this second time the code runs normally.

To debug this problem, we added a printk inside k_busy_wait's while loop: printk("%d %d %d\n", start_cycles, current_cycles, cycles_to_wait);
Adding this printk lead us to the evidence above:
1) that the hardware cycle count is not running the first time;
2) that, after a restart (by whom?), the hardware cycle count is normal and the code runs just fine.

The serial output and modified k_busy_wait code is here: https://gist.github.com/durub/edda1fbf6a6c8f1c7f88960d26916ddf
The first line of the chip's output is "[exati-watchdog] [DBG] watchdog_init: [34m-------------=============Watchdog thread scheduled (...)".
The code hangs just after "Protocol initialized.", where we call k_busy_wait.

Can somebody shed some light on this problem? My teammate and I have been struggling with it for the last couple days, but no progress so far.

Additional info:

The watchdog thread was scheduled to initialize 10 seconds after the k_thread_create call, but it never happens (-------------=============Watchdog thread created=============-------------),
as the hardware cycle count is frozen. Because of this, watchdog is not running the first time, but the chip stills restart by itself after some time.

Best regards,
Thiago


Re: NRF51822 hanging

Carles Cufi
 

-----Original Message-----
From: Boie, Andrew P [mailto:andrew.p.boie@intel.com]
Sent: 14 August 2017 21:03
To: Scott Nelson <scott@scottnelson.co>; Cufi, Carles
<Carles.Cufi@nordicsemi.no>
Cc: zephyr-users@lists.zephyrproject.org

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org
[mailto:zephyr-users- bounces@lists.zephyrproject.org] On Behalf Of
Scott Nelson
Sent: Monday, August 14, 2017 11:06 AM

The board is one of these:
http://www.waveshare.com/nrf51822-eval-kit.htm I have been flashing
it with STLink + OpenOCD and I’m trying to figure out how I can debug
the chip with that setup + GDB. I am not using the Nordic dev kit.
Let me know if there’s any additional info I can provide and thanks for
you help!

Is there a way I can override the Zephyr fault hander so that I could,
for example, flash an LED or repeatedly log something to the serial
output?

Yes. _SysFatalErrorHandler is declared __weak just for this purpose.

In your application, implement:

void _SysFatalErrorHandler(unsigned int reason, const NANO_ESF *pEsf)

And implement whatever policy you would like for fatal errors.
The default implementation for ARM is in
arch/arm/core/sys_fatal_error_handler.c
Thanks for the clarification Andrew, I actually always set the breakpoint in _NanoFatalErrorHandler() but it's really good to know that there's the user version declared weak.

Carles


Re: NRF51822 hanging

Boie, Andrew P
 

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-
bounces@lists.zephyrproject.org] On Behalf Of Scott Nelson
Sent: Monday, August 14, 2017 11:06 AM

The board is one of these: http://www.waveshare.com/nrf51822-eval-kit.htm I
have been flashing it with STLink + OpenOCD and I’m trying to figure out how I
can debug the chip with that setup + GDB. I am not using the Nordic dev kit. Let
me know if there’s any additional info I can provide and thanks for you help!

Is there a way I can override the Zephyr fault hander so that I could, for
example, flash an LED or repeatedly log something to the serial output?
Yes. _SysFatalErrorHandler is declared __weak just for this purpose.

In your application, implement:

void _SysFatalErrorHandler(unsigned int reason, const NANO_ESF *pEsf)

And implement whatever policy you would like for fatal errors.
The default implementation for ARM is in arch/arm/core/sys_fatal_error_handler.c

Andrew


Re: NRF51822 hanging

Scott Nelson <scott@...>
 

Just upgraded to the latest master version and overrode the _SysFatalErrorHandler. Thanks! Very helpful info.

-Scott

On Aug 14, 2017, at 2:30 PM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Scott,

-----Original Message-----
From: Scott Nelson [mailto:scott@scottnelson.co]
Sent: 14 August 2017 20:06
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] NRF51822 hanging

The board is one of these: http://www.waveshare.com/nrf51822-eval-
kit.htm I have been flashing it with STLink + OpenOCD and I’m trying to
figure out how I can debug the chip with that setup + GDB. I am not
using the Nordic dev kit. Let me know if there’s any additional info I
can provide and thanks for you help!

Is there a way I can override the Zephyr fault hander so that I could,
for example, flash an LED or repeatedly log something to the serial
output?
Yes, since you are using the BLE controller this could be a controller assert (which leads to panic). Assuming you are using the latest master (and you should if you are not, since there have been many fixes to the BLE controller recently) then you can override it here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/arch/arm/core/fatal.c#L45

A CPU fault and a BLE controller assert should all end up there.

Regards,

Carles


Re: NRF51822 hanging

Carles Cufi
 

Hi Scott,

-----Original Message-----
From: Scott Nelson [mailto:scott@scottnelson.co]
Sent: 14 August 2017 20:06
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] NRF51822 hanging

The board is one of these: http://www.waveshare.com/nrf51822-eval-
kit.htm I have been flashing it with STLink + OpenOCD and I’m trying to
figure out how I can debug the chip with that setup + GDB. I am not
using the Nordic dev kit. Let me know if there’s any additional info I
can provide and thanks for you help!

Is there a way I can override the Zephyr fault hander so that I could,
for example, flash an LED or repeatedly log something to the serial
output?
Yes, since you are using the BLE controller this could be a controller assert (which leads to panic). Assuming you are using the latest master (and you should if you are not, since there have been many fixes to the BLE controller recently) then you can override it here:

https://github.com/zephyrproject-rtos/zephyr/blob/master/arch/arm/core/fatal.c#L45

A CPU fault and a BLE controller assert should all end up there.

Regards,

Carles


Re: NRF51822 hanging

Scott Nelson <scott@...>
 

The board is one of these: http://www.waveshare.com/nrf51822-eval-kit.htm I have been flashing it with STLink + OpenOCD and I’m trying to figure out how I can debug the chip with that setup + GDB. I am not using the Nordic dev kit. Let me know if there’s any additional info I can provide and thanks for you help!

Is there a way I can override the Zephyr fault hander so that I could, for example, flash an LED or repeatedly log something to the serial output?

-Scott

On Aug 14, 2017, at 1:51 PM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Scott,

Can you tell us a bit more about the board itself and whether you can debug post-mortem by plugging it and attaching to the executing code? Are you using a Nordic development kit and if not, are you using a Segger debugger chip?

Thanks,

Carles

On 14/08/2017, 19:46, "zephyr-users-bounces@lists.zephyrproject.org on behalf of Scott Nelson" <zephyr-users-bounces@lists.zephyrproject.org on behalf of scott@scottnelson.co> wrote:

I’m running the Zephyr RTOS on an NRF51822 board. Occasionally I notice that the code execution is hung up for some reason (I have a status LED that stops flashing and I can no longer connect via BLE). I’m assuming there’s some kind of fault and I’ve tried debugging this by capturing the serial output (Zephyr logs faults, etc.). Oddly though, the issue never seems to arise when I have a little USB-to-serial board plugged in. How do you recommend I get to the bottom of this?

Thanks!

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


Re: NRF51822 hanging

Carles Cufi
 

Hi Scott,

Can you tell us a bit more about the board itself and whether you can debug post-mortem by plugging it and attaching to the executing code? Are you using a Nordic development kit and if not, are you using a Segger debugger chip?

Thanks,

Carles

On 14/08/2017, 19:46, "zephyr-users-bounces@lists.zephyrproject.org on behalf of Scott Nelson" <zephyr-users-bounces@lists.zephyrproject.org on behalf of scott@scottnelson.co> wrote:

I’m running the Zephyr RTOS on an NRF51822 board. Occasionally I notice that the code execution is hung up for some reason (I have a status LED that stops flashing and I can no longer connect via BLE). I’m assuming there’s some kind of fault and I’ve tried debugging this by capturing the serial output (Zephyr logs faults, etc.). Oddly though, the issue never seems to arise when I have a little USB-to-serial board plugged in. How do you recommend I get to the bottom of this?

Thanks!

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


NRF51822 hanging

Scott Nelson <scott@...>
 

I’m running the Zephyr RTOS on an NRF51822 board. Occasionally I notice that the code execution is hung up for some reason (I have a status LED that stops flashing and I can no longer connect via BLE). I’m assuming there’s some kind of fault and I’ve tried debugging this by capturing the serial output (Zephyr logs faults, etc.). Oddly though, the issue never seems to arise when I have a little USB-to-serial board plugged in. How do you recommend I get to the bottom of this?

Thanks!

-Scott


Re: TCP connection problem

Vakul Garg <vakul.garg@...>
 

The issue seems fixed in latest code base.

Thanks,
Vakul

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@linaro.org]
Sent: Tuesday, August 08, 2017 2:08 AM
To: Vakul Garg <vakul.garg@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] TCP connection problem

Hello Vakul,

What do you mean by "in my application running under zephyr ... TCP POSIX sockets" below? What version of Zephyr do you use?

To shorten communication loops, I'd recommend you to try the latest Zephyr master (now 1.9-pre), and if the problem persists, open a ticket at http://jira.zephyrproject.org/ with the minimal testcase (source
code) to reproduce it.


On Fri, 4 Aug 2017 14:00:34 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

Hi

In my application running under zephyr, I open multiple TCP POSIX
sockets and connect them with a TCP server on linux host. The first
client socket connects with TCP server gracefully. The second client
socket chooses the same local port as the first one. This causes the
TCP connection for second client socket to fail.

On executing 'conn' command on zephyr shell, it reveal that the two of
the connections use same local & remote port. It seems that the
connect() call is not choosing a free port for the socket.

Regards

Vakul
net> conn
Context Iface Flags Local Remote
[ 1] 0x0040c200 0x004051a0 4ST 0.0.0.0:9238 0.0.0.0:0
[ 2] 0x0040c258 0x004051a0 4ST 192.0.2.1:9238
192.0.2.2:52589 [ 3] 0x0040c2b0 0x004051a0 4DU
0.0.0.0:4433 192.0.2.1:4434 [ 4] 0x0040c308 0x004051a0
4ST 0.0.0.0:16384 192.0.2.2:9239 [ 5] 0x0040c360
0x004051a0 4ST 192.0.2.1:9238 192.0.2.2:52590 [ 6]
0x0040c3b8 0x004051a0 4DU 0.0.0.0:4434 192.0.2.1:4433
[ 7] 0x0040c410 0x004051a0 4ST 0.0.0.0:16384 192.0.2.2:9239

TCP Src port Dst port Send-Seq Send-Ack MSS State
0x0040dba0 9238 52589 1234687429 1974441142 1460
ESTABLISHED 0x0040dc60 9238 52590 2778482509 379001672
1460 ESTABLISHED 0x0040dd20 16384 9239 1326661533
1311733184 1460 ESTABLISHED 0x0040dde0 9238 0
2778482508 379001612 1460 LISTEN 0x0040dea0 16384 9239
2832855501 0 1460 SYN_SENT


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: TCP connection problem

Paul Sokolovsky
 

Hello Vakul,

What do you mean by "in my application running under zephyr ... TCP
POSIX sockets" below? What version of Zephyr do you use?

To shorten communication loops, I'd recommend you to try the latest
Zephyr master (now 1.9-pre), and if the problem persists, open a ticket
at http://jira.zephyrproject.org/ with the minimal testcase (source
code) to reproduce it.


On Fri, 4 Aug 2017 14:00:34 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

Hi

In my application running under zephyr, I open multiple TCP POSIX
sockets and connect them with a TCP server on linux host. The first
client socket connects with TCP server gracefully. The second client
socket chooses the same local port as the first one. This causes the
TCP connection for second client socket to fail.

On executing 'conn' command on zephyr shell, it reveal that the two
of the connections use same local & remote port. It seems that the
connect() call is not choosing a free port for the socket.

Regards

Vakul
net> conn
Context Iface Flags Local Remote
[ 1] 0x0040c200 0x004051a0 4ST 0.0.0.0:9238 0.0.0.0:0
[ 2] 0x0040c258 0x004051a0 4ST 192.0.2.1:9238
192.0.2.2:52589 [ 3] 0x0040c2b0 0x004051a0 4DU
0.0.0.0:4433 192.0.2.1:4434 [ 4] 0x0040c308 0x004051a0
4ST 0.0.0.0:16384 192.0.2.2:9239 [ 5] 0x0040c360
0x004051a0 4ST 192.0.2.1:9238 192.0.2.2:52590 [ 6]
0x0040c3b8 0x004051a0 4DU 0.0.0.0:4434 192.0.2.1:4433
[ 7] 0x0040c410 0x004051a0 4ST 0.0.0.0:16384 192.0.2.2:9239

TCP Src port Dst port Send-Seq Send-Ack MSS State
0x0040dba0 9238 52589 1234687429 1974441142 1460
ESTABLISHED 0x0040dc60 9238 52590 2778482509 379001672
1460 ESTABLISHED 0x0040dd20 16384 9239 1326661533
1311733184 1460 ESTABLISHED 0x0040dde0 9238 0
2778482508 379001612 1460 LISTEN 0x0040dea0 16384 9239
2832855501 0 1460 SYN_SENT


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


TCP connection problem

Vakul Garg <vakul.garg@...>
 

Hi

 

In my application running under zephyr, I open multiple TCP POSIX sockets and connect them with a TCP server on linux host.

The first client socket connects with TCP server gracefully. The second client socket chooses the same local port as the first one.

This causes the TCP connection for second client socket to fail.

 

On executing ‘conn’ command on zephyr shell, it reveal that the two of the connections use same local & remote port.

It seems that the connect() call is not choosing a free port for the socket.

 

Regards

 

Vakul

net> conn

     Context    Iface         Flags Local               Remote

[ 1] 0x0040c200 0x004051a0    4ST   0.0.0.0:9238        0.0.0.0:0

[ 2] 0x0040c258 0x004051a0    4ST   192.0.2.1:9238      192.0.2.2:52589

[ 3] 0x0040c2b0 0x004051a0    4DU   0.0.0.0:4433        192.0.2.1:4434

[ 4] 0x0040c308 0x004051a0    4ST   0.0.0.0:16384       192.0.2.2:9239

[ 5] 0x0040c360 0x004051a0    4ST   192.0.2.1:9238      192.0.2.2:52590

[ 6] 0x0040c3b8 0x004051a0    4DU   0.0.0.0:4434        192.0.2.1:4433

[ 7] 0x0040c410 0x004051a0    4ST   0.0.0.0:16384       192.0.2.2:9239

 

TCP        Src port  Dst port   Send-Seq   Send-Ack  MSS    State

0x0040dba0     9238     52589 1234687429 1974441142  1460   ESTABLISHED

0x0040dc60     9238     52590 2778482509  379001672  1460   ESTABLISHED

0x0040dd20    16384      9239 1326661533 1311733184  1460   ESTABLISHED

0x0040dde0     9238         0 2778482508  379001612  1460   LISTEN

0x0040dea0    16384      9239 2832855501          0  1460   SYN_SENT


Re: I2c problem on 96b Carbon.

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


Re: I2c problem on 96b Carbon.

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


Re: I2c problem on 96b Carbon.

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


Re: I2c problem on 96b Carbon.

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


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


Re: Help needed for Zephyr compilation

Carles Cufi
 

Hi there,

Note that the Getting Started guides have been updated to use a requirements.txt instead of manually installing a set of Python modules. If you run pip against that .txt file it should install all required deps.

Thanks,

Carles

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-
bounces@lists.zephyrproject.org] On Behalf Of Vakul Garg
Sent: 02 August 2017 10:07
To: massimiliano cialdi <massimiliano.cialdi@powersoft.it>; zephyr-
users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Help needed for Zephyr compilation

Thanks, it worked for me too.

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-
bounces@lists.zephyrproject.org] On Behalf Of massimiliano cialdi
Sent: Tuesday, August 01, 2017 5:49 PM
To: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Help needed for Zephyr compilation

I had the same problem, and I solved it installing pyelftool 0.24

pip3 install pyelftools==0.24

best regards
Max
On 01/08/2017 12:43, Vakul Garg wrote:

Hi

I am newbie to Zephyr and compiling source from HEAD of master branch
for target qemu_x86.

I am getting following error.

Traceback (most recent call last):

File "/home/b16394/zephyr/zephyr-git/scripts/gen_offset_header.py",
line 8, in <module>

from elftools.elf.elffile import ELFFile

ImportError: No module named 'elftools'

make[3]: *** [include/generated/offsets.h] Error 1

make[2]: *** [prepare] Error 2

make[1]: *** [sub-make] Error 2

Can someone please help?

I could compile from below mentioned commit, but compiling latest code
fails with above error.

commit bc2454fa9e966ab31db6b78439389f9066f840b3

Regards

Vakul



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


Re: Help needed for Zephyr compilation

Vakul Garg <vakul.garg@...>
 

Thanks, it worked for me too.

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-bounces@lists.zephyrproject.org] On Behalf Of massimiliano cialdi
Sent: Tuesday, August 01, 2017 5:49 PM
To: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Help needed for Zephyr compilation

I had the same problem, and I solved it installing pyelftool 0.24

pip3 install pyelftools==0.24

best regards
Max
On 01/08/2017 12:43, Vakul Garg wrote:

Hi

I am newbie to Zephyr and compiling source from HEAD of master branch
for target qemu_x86.

I am getting following error.

Traceback (most recent call last):

File "/home/b16394/zephyr/zephyr-git/scripts/gen_offset_header.py",
line 8, in <module>

from elftools.elf.elffile import ELFFile

ImportError: No module named 'elftools'

make[3]: *** [include/generated/offsets.h] Error 1

make[2]: *** [prepare] Error 2

make[1]: *** [sub-make] Error 2

Can someone please help?

I could compile from below mentioned commit, but compiling latest code
fails with above error.

commit bc2454fa9e966ab31db6b78439389f9066f840b3

Regards

Vakul



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


Re: Help needed for Zephyr compilation

Massimiliano Cialdi
 

I had the same problem, and I solved it installing pyelftool 0.24

pip3 install pyelftools==0.24

best regards
Max

On 01/08/2017 12:43, Vakul Garg wrote:

Hi

I am newbie to Zephyr and compiling source from HEAD of master branch for target qemu_x86.

I am getting following error.

Traceback (most recent call last):

File "/home/b16394/zephyr/zephyr-git/scripts/gen_offset_header.py", line 8, in <module>

from elftools.elf.elffile import ELFFile

ImportError: No module named 'elftools'

make[3]: *** [include/generated/offsets.h] Error 1

make[2]: *** [prepare] Error 2

make[1]: *** [sub-make] Error 2

Can someone please help?

I could compile from below mentioned commit, but compiling latest code fails with above error.

commit bc2454fa9e966ab31db6b78439389f9066f840b3

Regards

Vakul



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


Re: Help needed for Zephyr compilation

Adam Podogrocki
 

Seems that the Python module named 'elftools' is missing. Please install the mentioned packed and try again.

Cheers,
Adam

On 1 August 2017 at 12:43, Vakul Garg <vakul.garg@...> wrote:

Hi

 

I am newbie to Zephyr and compiling source from HEAD of master branch for target qemu_x86.

I am getting following error.

 

Traceback (most recent call last):

  File "/home/b16394/zephyr/zephyr-git/scripts/gen_offset_header.py", line 8, in <module>

    from elftools.elf.elffile import ELFFile

ImportError: No module named 'elftools'

make[3]: *** [include/generated/offsets.h] Error 1

make[2]: *** [prepare] Error 2

make[1]: *** [sub-make] Error 2

 

Can someone please help?

I could compile from below mentioned commit, but compiling latest code fails with above error.

 

commit bc2454fa9e966ab31db6b78439389f9066f840b3

 

Regards

 

Vakul

 

 


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


2461 - 2480 of 2576