Date   

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


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

2541 - 2560 of 2662