Date   

Re: Debugging NRF51822 (OpenOCD + GDB)

Scott Nelson <scott@...>
 

Ahha! I found this in there:

0000bc70 <chan_set.part.23>:
LL_ASSERT(!_radio.ticker_id_prepare);
bc70: b662 cpsie i
bc72: 2004 movs r0, #4
bc74: df02 svc 2


I think the “…" is displayed when that address is just zeros?

When I look through the code that I’m running though I do not see "LL_ASSERT(!_radio.ticker_id_prepare);” inside “chan_set”. I do see calls to "LL_ASSERT(!_radio.ticker_id_prepare);” in “radio_event_adv_prepare” and “event_scan_prepare”. Here’s the version I’m running: https://github.com/zephyrproject-rtos/zephyr/blob/dd52b8ea02da44b58dd16b8304fec16a15b24648/subsys/bluetooth/controller/ll_sw/ctrl.c

-Scott

On Aug 24, 2017, at 6:38 PM, Marti Bolivar <marti.bolivar@linaro.org> wrote:

Hi Scott,

On 24 August 2017 at 18:24, Scott Nelson <scott@scottnelson.co> wrote:

I tried disassembling the object file that contains the radio_event_adv_prepare function:

$ arm-none-eabi-objdump -z -S outdir/nrf51_blenano/subsys/bluetooth/controller/ll_sw/ctrl.o

I didn’t see 0xbc76 in there though.

There should be an outdir/zephyr.lst file in your build directory. This contains a disassembly of the final executable. You may have better luck searching for that address in there.

Marti


Re: Debugging NRF51822 (OpenOCD + GDB)

Marti Bolivar <marti.bolivar@...>
 

Hi Scott,

On 24 August 2017 at 18:24, Scott Nelson <scott@...> wrote:

I tried disassembling the object file that contains the radio_event_adv_prepare function:

$ arm-none-eabi-objdump -z -S outdir/nrf51_blenano/subsys/bluetooth/controller/ll_sw/ctrl.o

I didn’t see 0xbc76 in there though. 

There should be an outdir/zephyr.lst file in your build directory. This contains a disassembly of the final executable. You may have better luck searching for that address in there.

Marti
 


Re: Debugging NRF51822 (OpenOCD + GDB)

Scott Nelson <scott@...>
 

Thanks everyone! Learning a lot here.

Here’s what I get:

$ arm-none-eabi-addr2line -f -e outdir/nrf51_blenano/zephyr.elf 0xbc76
radio_event_adv_prepare.part.31
errno.c:?

I tried disassembling the object file that contains the radio_event_adv_prepare function:

$ arm-none-eabi-objdump -z -S outdir/nrf51_blenano/subsys/bluetooth/controller/ll_sw/ctrl.o

I didn’t see 0xbc76 in there though. Here’s the output for that section:

00000000 <radio_event_adv_prepare>:
0: b57f push {r0, r1, r2, r3, r4, r5, r6, lr}
__ASM volatile ("sev");
2: 4c0b ldr r4, [pc, #44] ; (30 <radio_event_adv_prepare+0x30>)
__ASM volatile ("wfe");
4: 7b25 ldrb r5, [r4, #12]
6: b2ed uxtb r5, r5
*((u32_t volatile *)ops_context) = status;
8: 2d00 cmp r5, #0
}
a: d001 beq.n 10 <radio_event_adv_prepare+0x10>
if (status == 0) {
c: f7ff fffe bl 0 <radio_event_adv_prepare>
hdr->ticks_xtal_to_start |= ((u32_t)1 << 31);
10: 2605 movs r6, #5
12: 0023 movs r3, r4
14: 0022 movs r2, r4
16: 7326 strb r6, [r4, #12]
18: 9503 str r5, [sp, #12]
}
1a: 4d06 ldr r5, [pc, #24] ; (34 <radio_event_adv_prepare+0x34>)
if (status == 0) {
1c: 9601 str r6, [sp, #4]
1e: 9502 str r5, [sp, #8]
hdr->ticks_xtal_to_start &= ~((u32_t)1 << 31);
20: 69e4 ldr r4, [r4, #28]
22: 3318 adds r3, #24
24: 3214 adds r2, #20
26: 9400 str r4, [sp, #0]
}
28: f7ff fffe bl 0 <radio_event_adv_prepare>
{
2c: bd7f pop {r0, r1, r2, r3, r4, r5, r6, pc}
2e: 46c0 nop ; (mov r8, r8)
if (bite & 0x01) {
30: 00000000 .word 0x00000000
while (byte_count--) {
34: 00000000 .word 0x00000000

When I manually looked through the zephyr.map file I found this:

.text.event_scan_prepare.part.32
0x000000000000bc70 0x6 subsys/built-in.o
*fill* 0x000000000000bc76 0x2

It now seems clear to me that the fault is BLE related but I’m not sure how to find the exact line or cause. Thanks again for your ongoing help and patience!

-Scott

On Aug 24, 2017, at 12:25 PM, Boie, Andrew P <andrew.p.boie@intel.com> wrote:

OK, I finally was able to catch the fault while I had a serial console connected
and here’s what I saw:

***** HARD FAULT *****
Executing thread ID (thread): 0x20001908
Faulting instruction address: 0xbc76

What do I do with that info? Is there a way to determine what code
corresponds to that address?
Yes, the addr2line tool will show you this, if you run it on the zephyr.elf binary.
https://sourceware.org/binutils/docs/binutils/addr2line.html

Andrew


Re: Debugging NRF51822 (OpenOCD + GDB)

Boie, Andrew P
 

OK, I finally was able to catch the fault while I had a serial console connected
and here’s what I saw:

***** HARD FAULT *****
Executing thread ID (thread): 0x20001908
Faulting instruction address: 0xbc76

What do I do with that info? Is there a way to determine what code
corresponds to that address?
Yes, the addr2line tool will show you this, if you run it on the zephyr.elf binary.
https://sourceware.org/binutils/docs/binutils/addr2line.html

Andrew


Re: Debugging NRF51822 (OpenOCD + GDB)

Scott Nelson <scott@...>
 

OK, I finally was able to catch the fault while I had a serial console connected and here’s what I saw:

***** HARD FAULT *****
Executing thread ID (thread): 0x20001908
Faulting instruction address: 0xbc76

What do I do with that info? Is there a way to determine what code corresponds to that address?

Thanks!

-Scott

On Aug 22, 2017, at 3:27 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,


I wrote into the list about an issue I was having with an NRF51822 board a couple days ago. It’s occasionally ending up in _SysFatalErrorHandler but I’m still not sure why (though I suspect it may be something BLE related).
I can help you if its an issue with BLE, can you give details of the application you are using and the symptoms of the issue?

I’m trying to attach a debugger with the ultimate goal of printing a stack trace when the code ends up in the error handler. First I’m starting an OpenOCD server:

$ openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg

And then trying to connect GDB:

$ arm-none-eabi-gdb outdir/nrf51_blenano/zephyr.elf
(gdb) set verbose on
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading in symbols for /Users/scott/Code/bms/zephyr/lib/libc/minimal/source/stdout/fprintf.c...done.
fprintf (F=<optimized out>, Abort trap: 6

The OpenOCD logs show:

accepting 'gdb' connection on tcp/3333
dropped 'gdb' connection

Any idea why I’m getting this error? I’m new to OpenOCD and GDB so I’m not sure if this is an issue with my toolchain setup or if it is something related to Zephyr. Any help would be much appreciated!
I have no experience myself with OpenOCD, I always have used our DK boards with JLinkGDBServer or pyocd-gdbserver (mbed debugger host firmware).

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


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



Re: I2c problem on 96b Carbon.

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>


Re: I2c problem on 96b Carbon.

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



Re: Debugging NRF51822 (OpenOCD + GDB)

Scott Nelson <scott@...>
 

On Aug 22, 2017, at 3:27 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi,


I wrote into the list about an issue I was having with an NRF51822 board a couple days ago. It’s occasionally ending up in _SysFatalErrorHandler but I’m still not sure why (though I suspect it may be something BLE related).
I can help you if its an issue with BLE, can you give details of the application you are using and the symptoms of the issue?
My hunch that it’s BLE related is very anecdotal (I did not notice the issue before adding the BLE component). Probably not worth pursuing this hunch too far until I can figure out what code is causing the fatal error. My code configures a single BLE peripheral and periodically calls bt_gatt_notify.


I’m trying to attach a debugger with the ultimate goal of printing a stack trace when the code ends up in the error handler. First I’m starting an OpenOCD server:

$ openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg

And then trying to connect GDB:

$ arm-none-eabi-gdb outdir/nrf51_blenano/zephyr.elf
(gdb) set verbose on
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading in symbols for /Users/scott/Code/bms/zephyr/lib/libc/minimal/source/stdout/fprintf.c...done.
fprintf (F=<optimized out>, Abort trap: 6

The OpenOCD logs show:

accepting 'gdb' connection on tcp/3333
dropped 'gdb' connection

Any idea why I’m getting this error? I’m new to OpenOCD and GDB so I’m not sure if this is an issue with my toolchain setup or if it is something related to Zephyr. Any help would be much appreciated!
I have no experience myself with OpenOCD, I always have used our DK boards with JLinkGDBServer or pyocd-gdbserver (mbed debugger host firmware).

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


Re: Debugging NRF51822 (OpenOCD + GDB)

Scott Nelson <scott@...>
 

I’ve previously left it with a serial port connected but, oddly, it never ends up in the _SysFatalErrorHandler when I do that. I currently turn on an LED so I know when the code has entered _SysFatalErrorHandler and was hoping to connect the debugger after the fact. I’ll look into the RAM console. Thanks.

-Scott

On Aug 22, 2017, at 3:25 PM, Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:

Hi Scott,

I don’t know why you are getting the gdb error (here at Nordic we all use Segger debug ICs), but if the _SysFatalErrorHandler is getting called because of BLE then it’s highly likely that there is a preceding printk() statement giving the cause. I understand you don’t have a serial port connected, so could you try enabling the RAM console and dumping the memory with gdb once you hit the fatal error?

You should be able to do so with this option:
https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/console/Kconfig#L106

Regards,

Carles

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

Hello,

I wrote into the list about an issue I was having with an NRF51822 board a couple days ago. It’s occasionally ending up in _SysFatalErrorHandler but I’m still not sure why (though I suspect it may be something BLE related). I’m trying to attach a debugger with the ultimate goal of printing a stack trace when the code ends up in the error handler. First I’m starting an OpenOCD server:

$ openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg

And then trying to connect GDB:

$ arm-none-eabi-gdb outdir/nrf51_blenano/zephyr.elf
(gdb) set verbose on
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading in symbols for /Users/scott/Code/bms/zephyr/lib/libc/minimal/source/stdout/fprintf.c...done.
fprintf (F=<optimized out>, Abort trap: 6

The OpenOCD logs show:

accepting 'gdb' connection on tcp/3333
dropped 'gdb' connection

Any idea why I’m getting this error? I’m new to OpenOCD and GDB so I’m not sure if this is an issue with my toolchain setup or if it is something related to Zephyr. Any help would be much appreciated!

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


Re: Debugging NRF51822 (OpenOCD + GDB)

Chettimada, Vinayak Kariappa
 

Hi,


I wrote into the list about an issue I was having with an NRF51822 board a couple days ago. It’s occasionally ending up in _SysFatalErrorHandler but I’m still not sure why (though I suspect it may be something BLE related).
I can help you if its an issue with BLE, can you give details of the application you are using and the symptoms of the issue?

I’m trying to attach a debugger with the ultimate goal of printing a stack trace when the code ends up in the error handler. First I’m starting an OpenOCD server:

$ openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg

And then trying to connect GDB:

$ arm-none-eabi-gdb outdir/nrf51_blenano/zephyr.elf
(gdb) set verbose on
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading in symbols for /Users/scott/Code/bms/zephyr/lib/libc/minimal/source/stdout/fprintf.c...done.
fprintf (F=<optimized out>, Abort trap: 6

The OpenOCD logs show:

accepting 'gdb' connection on tcp/3333
dropped 'gdb' connection

Any idea why I’m getting this error? I’m new to OpenOCD and GDB so I’m not sure if this is an issue with my toolchain setup or if it is something related to Zephyr. Any help would be much appreciated!
I have no experience myself with OpenOCD, I always have used our DK boards with JLinkGDBServer or pyocd-gdbserver (mbed debugger host firmware).

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


Re: Debugging NRF51822 (OpenOCD + GDB)

Carles Cufi
 

Hi Scott,

I don’t know why you are getting the gdb error (here at Nordic we all use Segger debug ICs), but if the _SysFatalErrorHandler is getting called because of BLE then it’s highly likely that there is a preceding printk() statement giving the cause. I understand you don’t have a serial port connected, so could you try enabling the RAM console and dumping the memory with gdb once you hit the fatal error?

You should be able to do so with this option:
https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/console/Kconfig#L106

Regards,

Carles

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

Hello,

I wrote into the list about an issue I was having with an NRF51822 board a couple days ago. It’s occasionally ending up in _SysFatalErrorHandler but I’m still not sure why (though I suspect it may be something BLE related). I’m trying to attach a debugger with the ultimate goal of printing a stack trace when the code ends up in the error handler. First I’m starting an OpenOCD server:

$ openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg

And then trying to connect GDB:

$ arm-none-eabi-gdb outdir/nrf51_blenano/zephyr.elf
(gdb) set verbose on
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading in symbols for /Users/scott/Code/bms/zephyr/lib/libc/minimal/source/stdout/fprintf.c...done.
fprintf (F=<optimized out>, Abort trap: 6

The OpenOCD logs show:

accepting 'gdb' connection on tcp/3333
dropped 'gdb' connection

Any idea why I’m getting this error? I’m new to OpenOCD and GDB so I’m not sure if this is an issue with my toolchain setup or if it is something related to Zephyr. Any help would be much appreciated!

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


Debugging NRF51822 (OpenOCD + GDB)

Scott Nelson <scott@...>
 

Hello,

I wrote into the list about an issue I was having with an NRF51822 board a couple days ago. It’s occasionally ending up in _SysFatalErrorHandler but I’m still not sure why (though I suspect it may be something BLE related). I’m trying to attach a debugger with the ultimate goal of printing a stack trace when the code ends up in the error handler. First I’m starting an OpenOCD server:

$ openocd -f interface/stlink-v2.cfg -f target/nrf51.cfg

And then trying to connect GDB:

$ arm-none-eabi-gdb outdir/nrf51_blenano/zephyr.elf
(gdb) set verbose on
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
Reading in symbols for /Users/scott/Code/bms/zephyr/lib/libc/minimal/source/stdout/fprintf.c...done.
fprintf (F=<optimized out>, Abort trap: 6

The OpenOCD logs show:

accepting 'gdb' connection on tcp/3333
dropped 'gdb' connection

Any idea why I’m getting this error? I’m new to OpenOCD and GDB so I’m not sure if this is an issue with my toolchain setup or if it is something related to Zephyr. Any help would be much appreciated!

Thanks,
Scott


Re: nRF52832 hardware cycle count freezing at chip start

Thiago Silveira
 

Hi Vinayak,

> I assume, you mean, you are using nRF52832 chip and your custom board; and using a Zephyr build using the BOARD=nrf52_pca10040.
> Do you have the 32KHz crystal mounted in your custom PCB? If not, you will need to use the internal RC oscillator by enabling CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y.

Good question! I checked and yes, we have the 32KHz crystal mounted in our custom PCB. We also tested with the nRF52 DK (the physical nrf52_pca10040 board).
We do use the nrf52_pca10040 board to build for our custom PCB, with some modifications in our prj.conf to suit our board (mainly UART TX/RX).

> Currently there is no watchdog driver for nRF52 contributed yet to Zephyr. I am not an expert on this peripheral, but I do notice in your code, you enable interrupt from the watchdog peripheral, hope you have setup interrupt handler correctly, clear the events and kick the dog sufficiently, etc.
> If your application needs watchdog, I would advise you implement a watchdog driver following the Zephyr driver model (include/watchdog.h and in drivers/watchdog folder). We will be glad to review your driver and a simple sample application. 

We do kick the dog sufficiently, and the watchdog is working fine apart from this initial hiccup. I'm not so sure about the events (other than clearing the channel).
Following your suggestions, I'm going to explore a little further the watchdog in nRF52832 and implement a driver following the Zephyr driver model.
Hopefully I could merge this back into upstream for the 1.10 release (as 1.09 is feature frozen)?

> Please remember that nRF52 is a ultra low power chip and there is no functional ARM systick timer, the system timer is implemented using the NRF_RTC peripheral.
> The resolution of each tick is in 32KHz units. If you print in busywait, you will see lot of lines with same values until each 32KHz (*if* UART tx time is very much less than 30.517 us, which I doubt).
> Ok, you want to wait 100 microseconds and your printk inside the “for” loop in k_busy_wait consumes more time (I am certain) and the loop does not break out correctly.

> Could you please explain the symptoms of the problem without any of your debugging (printk influences the k_busy_wait) ?

The 100 microseconds sample is just a way to show that k_cycle_get_32() is frozen. The only purpose is to test the NRF_RTC peripheral, not to wait any specified amount of time.
The first time it repeats 211 thousand times, with k_cycle_get_32() returning zero, and the second time it repeats only a dozen times, with k_cycle_get_32() returning increasing values.
That is evidence enough of what is happening, even though the waiting time may not be exactly 100 microseconds. Because waiting is not the intention, I don't think the debug influences the output that much.

However, I think that is a moot point now. I think your advice about the watchdog interrupts and events is correct.
I'm going to explore that further and report back to you guys.

Thanks so much for the help,

Thiago

2017-08-19 2:00 GMT-03:00 Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>:

Hi Thiago,


2) We're building for the nrf52_pca10040. I think we are enabling it: CONFIG_CLOCK_CONTROL_NRF5_K32SRC_XTAL=y

I assume, you mean, you are using nRF52832 chip and your custom board; and using a Zephyr build using the BOARD=nrf52_pca10040.
Do you have the 32KHz crystal mounted in your custom PCB? If not, you will need to use the internal RC oscillator by enabling CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y.
 
3) TICKLESS_IDLE is enabled, but TICKLESS_KERNEL is disabled.
4) I'm sorry, I can't pinpoint it right now to you. I'm going to investigate further here and report back. We've started experiencing this problem at the start of this week, but we were at a two-week development hiatus before then.
The only thing we added as the watchdog. The watchdog code is as follows:

void wdt_init(uint32_t reload_ms) {
NRF_WDT->CONFIG = 0x01 | 0x08;
NRF_WDT->CRV = (reload_ms / 1000) * 32678;
        SYS_LOG_WRN("%d: %d or %u", reload_ms, NRF_WDT->CRV, NRF_WDT->CRV);
NRF_WDT->INTENSET = WDT_INTENSET_TIMEOUT_Msk;
NRF_WDT->TASKS_START = 1;
}

void wdt_reload(uint8_t channel) {
NRF_WDT->RR[channel] = NRF_WDT_RR_VALUE;
}

I attached our .config to the original gist, it is there at the end now: https://gist.github.com/durub/edda1fbf6a6c8f1c7f88960d26916ddf

I tried just now to reproduce the problem without any of our code (but using our .config), and the problem still persists. Our main is:
void main() {
k_busy_wait(100);
}


Currently there is no watchdog driver for nRF52 contributed yet to Zephyr. I am not an expert on this peripheral, but I do notice in your code, you enable interrupt from the watchdog peripheral, hope you have setup interrupt handler correctly, clear the events and kick the dog sufficiently, etc.
If your application needs watchdog, I would advise you implement a watchdog driver following the Zephyr driver model (include/watchdog.h and in drivers/watchdog folder). We will be glad to review your driver and a simple sample application. 

We've tested this main using nrf52_pca10040 and our PCB. Sample of the final of the faulty output:
0 0 3
0 0 3
(a lot of equal lines)
0 0 3
0 0 3
0 shell> 30 30 3
30 56 3

I must say that this problem is happening intermittently. Now, the simple main is always working (a lot of successive resets with nrfjprog --reset -f nrf52):
shell> 38 38 3
38 64 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 64 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 64 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 64 3
shell> 38 38 3
38 64 3

Please remember that nRF52 is a ultra low power chip and there is no functional ARM systick timer, the system timer is implemented using the NRF_RTC peripheral.
The resolution of each tick is in 32KHz units. If you print in busywait, you will see lot of lines with same values until each 32KHz (*if* UART tx time is very much less than 30.517 us, which I doubt).
Ok, you want to wait 100 microseconds and your printk inside the “for” loop in k_busy_wait consumes more time (I am certain) and the loop does not break out correctly.

Could you please explain the symptoms of the problem without any of your debugging (printk influences the k_busy_wait) ?

Regards,
Vinayak


Re: nRF52832 hardware cycle count freezing at chip start

Chettimada, Vinayak Kariappa
 

Hi Thiago,


2) We're building for the nrf52_pca10040. I think we are enabling it: CONFIG_CLOCK_CONTROL_NRF5_K32SRC_XTAL=y

I assume, you mean, you are using nRF52832 chip and your custom board; and using a Zephyr build using the BOARD=nrf52_pca10040.
Do you have the 32KHz crystal mounted in your custom PCB? If not, you will need to use the internal RC oscillator by enabling CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y.
 
3) TICKLESS_IDLE is enabled, but TICKLESS_KERNEL is disabled.
4) I'm sorry, I can't pinpoint it right now to you. I'm going to investigate further here and report back. We've started experiencing this problem at the start of this week, but we were at a two-week development hiatus before then.
The only thing we added as the watchdog. The watchdog code is as follows:

void wdt_init(uint32_t reload_ms) {
NRF_WDT->CONFIG = 0x01 | 0x08;
NRF_WDT->CRV = (reload_ms / 1000) * 32678;
        SYS_LOG_WRN("%d: %d or %u", reload_ms, NRF_WDT->CRV, NRF_WDT->CRV);
NRF_WDT->INTENSET = WDT_INTENSET_TIMEOUT_Msk;
NRF_WDT->TASKS_START = 1;
}

void wdt_reload(uint8_t channel) {
NRF_WDT->RR[channel] = NRF_WDT_RR_VALUE;
}

I attached our .config to the original gist, it is there at the end now: https://gist.github.com/durub/edda1fbf6a6c8f1c7f88960d26916ddf

I tried just now to reproduce the problem without any of our code (but using our .config), and the problem still persists. Our main is:
void main() {
k_busy_wait(100);
}


Currently there is no watchdog driver for nRF52 contributed yet to Zephyr. I am not an expert on this peripheral, but I do notice in your code, you enable interrupt from the watchdog peripheral, hope you have setup interrupt handler correctly, clear the events and kick the dog sufficiently, etc.
If your application needs watchdog, I would advise you implement a watchdog driver following the Zephyr driver model (include/watchdog.h and in drivers/watchdog folder). We will be glad to review your driver and a simple sample application. 

We've tested this main using nrf52_pca10040 and our PCB. Sample of the final of the faulty output:
0 0 3
0 0 3
(a lot of equal lines)
0 0 3
0 0 3
0 shell> 30 30 3
30 56 3

I must say that this problem is happening intermittently. Now, the simple main is always working (a lot of successive resets with nrfjprog --reset -f nrf52):
shell> 38 38 3
38 64 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 64 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 64 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 64 3
shell> 38 38 3
38 64 3

Please remember that nRF52 is a ultra low power chip and there is no functional ARM systick timer, the system timer is implemented using the NRF_RTC peripheral.
The resolution of each tick is in 32KHz units. If you print in busywait, you will see lot of lines with same values until each 32KHz (*if* UART tx time is very much less than 30.517 us, which I doubt).
Ok, you want to wait 100 microseconds and your printk inside the “for” loop in k_busy_wait consumes more time (I am certain) and the loop does not break out correctly.

Could you please explain the symptoms of the problem without any of your debugging (printk influences the k_busy_wait) ?

Regards,
Vinayak


Re: nRF52832 hardware cycle count freezing at chip start

Thiago Silveira
 

Hi,

I'm starting to suspect that this is a problem/weird interaction with the watchdog.
When the problem happens, it persists in resets, that's why the simple main was hanging too.
When we turn off the power to the development kit and we turn it on later, the problem never happens with the simple main.

Maybe we're configuring the watchdog wrong?

Thanks,

Thiago

2017-08-18 14:41 GMT-03:00 Thiago Silveira <thiago@...>:

Hi Carles,

Thanks for the quick response.

1) We're using the latest master.
2) We're building for the nrf52_pca10040. I think we are enabling it: CONFIG_CLOCK_CONTROL_NRF5_K32SRC_XTAL=y
3) TICKLESS_IDLE is enabled, but TICKLESS_KERNEL is disabled.
4) I'm sorry, I can't pinpoint it right now to you. I'm going to investigate further here and report back. We've started experiencing this problem at the start of this week, but we were at a two-week development hiatus before then.
The only thing we added as the watchdog. The watchdog code is as follows:

void wdt_init(uint32_t reload_ms) {
NRF_WDT->CONFIG = 0x01 | 0x08;
NRF_WDT->CRV = (reload_ms / 1000) * 32678;
        SYS_LOG_WRN("%d: %d or %u", reload_ms, NRF_WDT->CRV, NRF_WDT->CRV);
NRF_WDT->INTENSET = WDT_INTENSET_TIMEOUT_Msk;
NRF_WDT->TASKS_START = 1;
}

void wdt_reload(uint8_t channel) {
NRF_WDT->RR[channel] = NRF_WDT_RR_VALUE;
}

I attached our .config to the original gist, it is there at the end now: https://gist.github.com/durub/edda1fbf6a6c8f1c7f88960d26916ddf

I tried just now to reproduce the problem without any of our code (but using our .config), and the problem still persists. Our main is:
void main() {
k_busy_wait(100);
}

We've tested this main using nrf52_pca10040 and our PCB. Sample of the final of the faulty output:
0 0 3
0 0 3
(a lot of equal lines)
0 0 3
0 0 3
0 shell> 30 30 3
30 56 3

I must say that this problem is happening intermittently. Now, the simple main is always working (a lot of successive resets with nrfjprog --reset -f nrf52):
shell> 38 38 3
38 64 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 64 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 64 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 64 3
shell> 38 38 3
38 64 3

Thanks a lot,

Thiago

2017-08-18 13:37 GMT-03:00 Cufi, Carles <Carles.Cufi@...>:
Hi Thiago,

> -----Original Message-----
> Subject: [Zephyr-users] nRF52832 hardware cycle count freezing at chip
> start
>
> 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.

Interesting, we haven't heard of this problem before, although there have been some issues with the nRF5x timer driver that we thought we had addressed.

So can you please expand on the following basic info before I try to reproduce:

1) Are you using the latest master or an older release?
2) What board are you building for does it have a 32Khz crystal, and do you enable the 32KHz timer in your .config?
3) Are you enabling TICKLESS_IDLE or TICKLESS_KERNEL? In fact, could you provide your .config file?
4) When did this problem appear if you're using master? There was a commit merged recently that added TICKLESS_KERNEL support for the nrf RTC driver, I wonder if it broke then.

Thanks,

Carles



Re: nRF52832 hardware cycle count freezing at chip start

Thiago Silveira
 

Hi Carles,

Thanks for the quick response.

1) We're using the latest master.
2) We're building for the nrf52_pca10040. I think we are enabling it: CONFIG_CLOCK_CONTROL_NRF5_K32SRC_XTAL=y
3) TICKLESS_IDLE is enabled, but TICKLESS_KERNEL is disabled.
4) I'm sorry, I can't pinpoint it right now to you. I'm going to investigate further here and report back. We've started experiencing this problem at the start of this week, but we were at a two-week development hiatus before then.
The only thing we added as the watchdog. The watchdog code is as follows:

void wdt_init(uint32_t reload_ms) {
NRF_WDT->CONFIG = 0x01 | 0x08;
NRF_WDT->CRV = (reload_ms / 1000) * 32678;
        SYS_LOG_WRN("%d: %d or %u", reload_ms, NRF_WDT->CRV, NRF_WDT->CRV);
NRF_WDT->INTENSET = WDT_INTENSET_TIMEOUT_Msk;
NRF_WDT->TASKS_START = 1;
}

void wdt_reload(uint8_t channel) {
NRF_WDT->RR[channel] = NRF_WDT_RR_VALUE;
}

I attached our .config to the original gist, it is there at the end now: https://gist.github.com/durub/edda1fbf6a6c8f1c7f88960d26916ddf

I tried just now to reproduce the problem without any of our code (but using our .config), and the problem still persists. Our main is:
void main() {
k_busy_wait(100);
}

We've tested this main using nrf52_pca10040 and our PCB. Sample of the final of the faulty output:
0 0 3
0 0 3
(a lot of equal lines)
0 0 3
0 0 3
0 shell> 30 30 3
30 56 3

I must say that this problem is happening intermittently. Now, the simple main is always working (a lot of successive resets with nrfjprog --reset -f nrf52):
shell> 38 38 3
38 64 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 64 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 64 3
shell> 38 38 3
38 65 3
shell> 38 38 3
38 64 3
shell> 38 38 3
38 64 3

Thanks a lot,

Thiago

2017-08-18 13:37 GMT-03:00 Cufi, Carles <Carles.Cufi@...>:

Hi Thiago,

> -----Original Message-----
> Subject: [Zephyr-users] nRF52832 hardware cycle count freezing at chip
> start
>
> 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.

Interesting, we haven't heard of this problem before, although there have been some issues with the nRF5x timer driver that we thought we had addressed.

So can you please expand on the following basic info before I try to reproduce:

1) Are you using the latest master or an older release?
2) What board are you building for does it have a 32Khz crystal, and do you enable the 32KHz timer in your .config?
3) Are you enabling TICKLESS_IDLE or TICKLESS_KERNEL? In fact, could you provide your .config file?
4) When did this problem appear if you're using master? There was a commit merged recently that added TICKLESS_KERNEL support for the nrf RTC driver, I wonder if it broke then.

Thanks,

Carles


Re: nRF52832 hardware cycle count freezing at chip start

Carles Cufi
 

Hi Thiago,

-----Original Message-----
Subject: [Zephyr-users] nRF52832 hardware cycle count freezing at chip
start

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.
Interesting, we haven't heard of this problem before, although there have been some issues with the nRF5x timer driver that we thought we had addressed.

So can you please expand on the following basic info before I try to reproduce:

1) Are you using the latest master or an older release?
2) What board are you building for does it have a 32Khz crystal, and do you enable the 32KHz timer in your .config?
3) Are you enabling TICKLESS_IDLE or TICKLESS_KERNEL? In fact, could you provide your .config file?
4) When did this problem appear if you're using master? There was a commit merged recently that added TICKLESS_KERNEL support for the nrf RTC driver, I wonder if it broke then.

Thanks,

Carles


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

2521 - 2540 of 2654