Date   

TCP assert error logs

Vakul Garg <vakul.garg@...>
 

Hi

 

I have two threads on my system communicating using TCP over loopback interface.

I am getting following errors.

 

[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed}

[net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain TCP header

[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed}

[net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain TCP header

[net/tcp] [ERR] net_tcp_get_hdr: {assert: 'frag' failed}

[net/tcp] [ERR] net_tcp_send_pkt: Packet 0x20004664 does not contain TCP header

[net/buf] [ERR] net_buf_unref_debug: net_pkt_frag_unref():826: buf 0x200046a0 double free

[net/buf] [ERR] net_buf_unref_debug: net_pkt_frag_unref():826: buf 0x200046a0 double free

[net/buf] [ERR] net_buf_unref_debug: net_pkt_frag_unref():826: buf 0x20004830 double free

 

Can someone help?

 

Regards, Vakul


Re: Help with compiling for qemu ARM cortex m3

Vakul Garg <vakul.garg@...>
 

Hi Andrew

The suggested commands are very useful.
Thanks for your advice.

Regards, Vakul

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-bounces@lists.zephyrproject.org] On Behalf Of Boie, Andrew P
Sent: Thursday, September 07, 2017 9:39 PM
To: Kumar Gala <kumar.gala@linaro.org>; Priyanka Rawat <priyanka.rawat@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Help with compiling for qemu ARM cortex m3

However, I want to test with the same SRAM value as in real hardware
(e.g.,
eventually I want to test with KW41Z board). So instead of increasing
the current SRAM value, I would rather modify proj.conf.

Could someone please tell me what would be the right approach to
address
this issue of SRAM overflow for qemu ARM ?
"make ram_report" and "make rom_report" dump out some helpful information to see what in your code is using so much memory.

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


Re: Help with compiling for qemu ARM cortex m3

Boie, Andrew P
 

However, I want to test with the same SRAM value as in real hardware (e.g.,
eventually I want to test with KW41Z board). So instead of increasing the current
SRAM value, I would rather modify proj.conf.

Could someone please tell me what would be the right approach to address
this issue of SRAM overflow for qemu ARM ?
"make ram_report" and "make rom_report" dump out some helpful information to see what in your code is using so much memory.

Andrew


Re: Help with compiling for qemu ARM cortex m3

Kumar Gala
 

On Sep 7, 2017, at 4:37 AM, Priyanka Rawat <priyanka.rawat@nxp.com> wrote:

Hi

I tried to compile my sample application code for the target
BOARD ?= qemu_cortex_m3

It compiles for qemu_x86 however for qemu_cortex_m3 it gives me errors related to SRAM overflowed.

$zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/real-ld: zephyr_prebuilt.elf section `noinit' will not fit in region `SRAM'
$zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/real-ld: section .intList VMA [0000000020010000,0000000020010043] overlaps section noinit VMA [000000002000d5a0,000000002002413b]
$zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/real-ld: region `SRAM' overflowed by 82236 bytes
collect2: error: ld returned 1 exit status
$zephyr/Makefile:878: recipe for target 'zephyr_prebuilt.elf' failed


I test with the recent zephyr version (master branch).
In dts/arm/ti/lm3s6965.dtsi the SRAM for qemu_cortex_m3 defined is 64 KB.

I can manage to compile for qemu_cortex_m3 by increasing the value of SRAM from 64 KB to 128 KB in
dts/arm/ti/lm3s6965.dtsi

sram0: memory@20000000 {
device_type = "memory";
compatible = "mmio-sram";
reg = <0x20000000 (64*1024)>;
};

However, I want to test with the same SRAM value as in real hardware (e.g., eventually I want to test with KW41Z board). So instead of increasing the current SRAM value, I would rather modify proj.conf.

Could someone please tell me what would be the right approach to address this issue of SRAM overflow for qemu ARM ?

Thanks
Priyanka
I don’t believe there is a way to change the amount of memory in qemu. Even with switching to the KW41Z guess you are going to run into memory issues (as it has 128k). So are you building your own application or one of the samples/tests? You can try and remove config options to reduce memory, but if you are 82K overflowing than I’m guessing you need to look at how your application is utilizing memory and see if you can reduce that.

- k


Help with compiling for qemu ARM cortex m3

Priyanka
 

Hi 


I tried to compile my sample application code for the target
BOARD ?= qemu_cortex_m3

It compiles for qemu_x86 however for qemu_cortex_m3 it gives me errors related to SRAM overflowed.

$zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/real-ld: zephyr_prebuilt.elf section `noinit' will not fit in region `SRAM'
$zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/real-ld: section .intList VMA [0000000020010000,0000000020010043] overlaps section noinit VMA [000000002000d5a0,000000002002413b]
$zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-zephyr-eabi/gcc/arm-zephyr-eabi/6.2.0/real-ld: region `SRAM' overflowed by 82236 bytes
collect2: error: ld returned 1 exit status
$zephyr/Makefile:878: recipe for target 'zephyr_prebuilt.elf' failed


I test with the recent zephyr version (master branch).
In dts/arm/ti/lm3s6965.dtsi the SRAM for qemu_cortex_m3 defined is 64 KB.

I can manage to compile for qemu_cortex_m3  by increasing the value of SRAM from 64 KB to 128 KB in
dts/arm/ti/lm3s6965.dtsi

sram0: memory@20000000 {
        device_type = "memory";
        compatible = "mmio-sram";
        reg = <0x20000000 (64*1024)>;    
};

However, I want to test with the same
SRAM value as in real hardware (e.g., eventually I want to test with KW41Z board). So instead of increasing the current SRAM value, I would rather modify proj.conf.
 
Could someone please tell me what would be the right approach to address this issue of SRAM overflow for qemu ARM ?

Thanks
Priyanka



Re: qemu_x86 zephyr bluetooth beacon sample error

Priyanka
 

Hi Johan


Thanks for the reply.
The error is with the (recent) master branch of zephyr.
Yes, I did try restarting Qemu, but it didn't resolve the issue.

Just to give you a sense of how I test this sample with BlueZ emulator and tools (in case I am missing or doing something wrong here) :

I have following running in different terminals.

$ sudo ./btvirt -l2
Bluetooth emulator ver 5.46

$ sudo btmon
Bluetooth monitor ver 5.46

$ sudo tools/btproxy -u
Listening on /tmp/bt-server-bredr
Opening user channel for hci0
New client connected

# zephyr/samples/bluetooth/beacon$ make run

Starting Beacon Demo
[bt] [INF] show_dev_info: Identity: 00:aa:01:00:00:23 (public)
[bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0x003f
[bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0x0000
Bluetooth initialized
Beacon started
[bt] [ERR] read_payload: Not enough space in buffer
[bt] [WRN] hci_cmd_done: pool id 1 pool 0x00405098 != &hci_cmd_pool 0x00405078

I try this with the basic proj.conf  provided in the sample "beacon"

$ hciconfig -a

gives me the following
Can't read class of device on hci0: Connection timed out (110)


hci0: Type: BR/EDR Bus: VIRTUAL

BD Address: 00:AA:01:00:00:23 ACL MTU: 192:1 SCO MTU: 0:0

UP RUNNING

RX bytes:0 acl:0 sco:0 events:203 errors:0

TX bytes:7024 acl:0 sco:0 commands:636 errors:0

Features: 0xa4 0x08 0x08 0xc0 0x58 0x1e 0x7b 0x83

Packet type: DM1 DH1 HV1

Link policy: RSWITCH SNIFF

Link mode: SLAVE ACCEPT

Name: 'xxxxxx #1'

Can't read class of device on hci0: Connection timed out (110)


Thanks
Priyanka


From: Johan Hedberg <johan.hedberg@...>
Sent: Tuesday, September 5, 2017 2:45 PM
To: Priyanka Rawat
Cc: zephyr-users@...
Subject: Re: [Zephyr-users] qemu_x86 zephyr bluetooth beacon sample error
 
Hi Priyanka,

On Tue, Sep 05, 2017, Priyanka Rawat wrote:
> While running the bluetooth sample "beacon" for the target qemu_x86,
>
> I get the following error
>
> Starting Beacon Demo
>
> Bluetooth initialized
> Beacon started
> [bt] [ERR] read_payload: Not enough space in buffer
> [bt] [WRN] hci_cmd_done: pool id 1 pool 0x00405098 != &hci_cmd_pool 0x00405078
>
> Is this a known issue? Could someone please tell me the possible cause
> of this error and how to fix it possibly? Thanks.

What version of Zephyr is this with? I've noticed that sometimes there
seems to be some garbage data inserted to the virtual UART between
btproxy and qemu, and restarting qemu usually helps with that. I've at
least seen the first error when that happens.

Johan


Re: qemu_x86 zephyr bluetooth beacon sample error

Johan Hedberg
 

Hi Priyanka,

On Tue, Sep 05, 2017, Priyanka Rawat wrote:
While running the bluetooth sample "beacon" for the target qemu_x86,

I get the following error

Starting Beacon Demo

Bluetooth initialized
Beacon started
[bt] [ERR] read_payload: Not enough space in buffer
[bt] [WRN] hci_cmd_done: pool id 1 pool 0x00405098 != &hci_cmd_pool 0x00405078

Is this a known issue? Could someone please tell me the possible cause
of this error and how to fix it possibly? Thanks.
What version of Zephyr is this with? I've noticed that sometimes there
seems to be some garbage data inserted to the virtual UART between
btproxy and qemu, and restarting qemu usually helps with that. I've at
least seen the first error when that happens.

Johan


qemu_x86 zephyr bluetooth beacon sample error

Priyanka
 

Hi 


While running the bluetooth sample "beacon" for the target qemu_x86, 

I get the following error


Starting Beacon Demo


Bluetooth initialized
Beacon started
[bt] [ERR] read_payload: Not enough space in buffer
[bt] [WRN] hci_cmd_done: pool id 1 pool 0x00405098 != &hci_cmd_pool 0x00405078

Is this a known issue? Could someone please tell me the possible cause of this error and how to fix it possibly? Thanks.

Thanks
Priyanka



How to choice CONFIG_GPIO_QMSI_0_NAME and CONFIG_GPIO_QMSI_1_NAME?

kk <pinganddu90@...>
 

Hi 

When programming based on arduino 101, 
1. How to choice the gpio? 
2. What is the different between CONFIG_GPIO_QMSI_0_NAME and CONFIG_GPIO_QMSI_1_NAME?

Thanks


Re: Debugging NRF51822 (OpenOCD + GDB)

Carles Cufi
 

Hi Scott,

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-
bounces@lists.zephyrproject.org] On Behalf Of Scott Nelson
Sent: 28 August 2017 15:15
To: Chettimada, Vinayak Kariappa
<vinayak.kariappa.chettimada@nordicsemi.no>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Debugging NRF51822 (OpenOCD + GDB)

Updating the Zephyr code seemed to have resolved the issue entirely.
Thanks!
That's good news, we fixed this issue, which also affected the nRF52 ICs that Linaro use for their distributed testing, in preparation for the 1.9 release, and was hoping that this would be the same. Sorry for the initial confusion.

Carles


Re: Debugging NRF51822 (OpenOCD + GDB)

Scott Nelson <scott@...>
 

Updating the Zephyr code seemed to have resolved the issue entirely. Thanks!

-Scott

On Aug 25, 2017, at 10:28 AM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Ah… I see your revision is older than a controller regression fix done in cb90fbe56.
The symptom was the exact assert as you see, around ~8 mins interval from power up.

Please use latest revision and let me know if you still see assert.
But its weird you don’t get logs from your application.

On 25 Aug 2017, at 15:38, Scott Nelson <scott@scottnelson.co> wrote:

I’m using an unmodified master as of revision 2de5902. Here’s the full code for the project I’m working on: https://github.com/scttnlsn/bms

Thanks!

-Scott

On Aug 25, 2017, at 9:31 AM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

I forced an assert in radio_event_adv_prepare by setting
"_radio.tocker_id_prepare = 1”. All I see is:

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

No additional logging.
[vich]
Are you using the upstream master as-is? Or you have modified the default configurations?
BT_ERR message when ASSERTing should be printed out on UART by default for the peripheral sample.


Re: Debugging NRF51822 (OpenOCD + GDB)

Chettimada, Vinayak Kariappa
 

Ah… I see your revision is older than a controller regression fix done in cb90fbe56.
The symptom was the exact assert as you see, around ~8 mins interval from power up.

Please use latest revision and let me know if you still see assert.
But its weird you don’t get logs from your application.

On 25 Aug 2017, at 15:38, Scott Nelson <scott@scottnelson.co> wrote:

I’m using an unmodified master as of revision 2de5902. Here’s the full code for the project I’m working on: https://github.com/scttnlsn/bms

Thanks!

-Scott

On Aug 25, 2017, at 9:31 AM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

I forced an assert in radio_event_adv_prepare by setting
"_radio.tocker_id_prepare = 1”. All I see is:

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

No additional logging.
[vich]
Are you using the upstream master as-is? Or you have modified the default configurations?
BT_ERR message when ASSERTing should be printed out on UART by default for the peripheral sample.


Re: Debugging NRF51822 (OpenOCD + GDB)

Carles Cufi
 

Hi Scott,

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-
bounces@lists.zephyrproject.org] On Behalf Of Scott Nelson
Sent: 25 August 2017 15:38
To: Chettimada, Vinayak Kariappa
<vinayak.kariappa.chettimada@nordicsemi.no>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] Debugging NRF51822 (OpenOCD + GDB)

I’m using an unmodified master as of revision 2de5902. Here’s the full
code for the project I’m working on: https://github.com/scttnlsn/bms
Let's make this simple. Can you replace BT_ERR with printk in:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/bluetooth/common/log.h#L93

Thanks,

Carles


Re: Debugging NRF51822 (OpenOCD + GDB)

Scott Nelson <scott@...>
 

I’m using an unmodified master as of revision 2de5902. Here’s the full code for the project I’m working on: https://github.com/scttnlsn/bms

Thanks!

-Scott

On Aug 25, 2017, at 9:31 AM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

I forced an assert in radio_event_adv_prepare by setting
"_radio.tocker_id_prepare = 1”. All I see is:

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

No additional logging.
[vich]
Are you using the upstream master as-is? Or you have modified the default configurations?
BT_ERR message when ASSERTing should be printed out on UART by default for the peripheral sample.


Re: Debugging NRF51822 (OpenOCD + GDB)

Chettimada, Vinayak Kariappa
 

I forced an assert in radio_event_adv_prepare by setting
"_radio.tocker_id_prepare = 1”. All I see is:

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

No additional logging.
[vich]
Are you using the upstream master as-is? Or you have modified the default configurations?
BT_ERR message when ASSERTing should be printed out on UART by default for the peripheral sample.


Re: Debugging NRF51822 (OpenOCD + GDB)

Scott Nelson <scott@...>
 

I forced an assert in radio_event_adv_prepare by setting "_radio.tocker_id_prepare = 1”. All I see is:

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

No additional logging.

I tried setting the ISR stack size to 1024 and got the same result when explicitly triggering the assert. I’ll let it sit for a while during normal operation and see if I see the real error show up (it’s very intermittent).

-Scott

On Aug 24, 2017, at 11:55 PM, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:

Hi Scott,

On 25 Aug 2017, at 05:23, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:


On 24 Aug 2017, at 17:21, Scott Nelson <scott@scottnelson.co> 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
Nice! May I ask if there where any preceding console messages? usually, the assert condition is printed along with the function name.
If I where to force an assert (break the design), this is how I would get (for samples/bluetooth/peripheral on my local repo):

[bt] [INF] show_dev_info: Identity: da:d7:35:42:55:80 (random)
[2017-08-25 05:28:18.771] [bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0xffff
[2017-08-25 05:28:18.779] [bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[2017-08-25 05:28:18.785] [bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[2017-08-25 05:28:18.797] [bt] [WRN] irk_init: Using temporary IRK
[2017-08-25 05:28:18.802] Bluetooth initialized
[2017-08-25 05:28:18.806] Advertising successfully started
[2017-08-25 05:28:18.913] [bt] [ERR] radio_event_adv_prepare: assert: '!_radio.ticker_id_prepare' failed
[2017-08-25 05:28:18.920] ***** HARD FAULT *****
[2017-08-25 05:28:18.922] Executing thread ID (thread): 0x200021a4
[2017-08-25 05:28:18.926] Faulting instruction address: 0xf7be
[2017-08-25 05:28:18.930] Fatal fault in ISR! Spinning...


and,

arm-none-eabi-addr2line -afie samples/bluetooth/peripheral/outdir/nrf51_pca10028/zephyr.elf 0xf7be
0x0000f7be
radio_event_adv_prepare
/Users/hemal/workspace/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:5551

and the line in the source file:

5541
5542 void radio_event_adv_prepare(u32_t ticks_at_expire, u32_t remainder,
5543 u16_t lazy, void *context)
5544 {
5545 ARG_UNUSED(lazy);
5546 ARG_UNUSED(context);
5547
5548 DEBUG_RADIO_PREPARE_A(1);
5549
5550 LL_ASSERT(!_radio.ticker_id_prepare);
5551 _radio.ticker_id_prepare = RADIO_TICKER_ID_ADV;
5552


The faulting instruction address corresponds to the next program counter, hence the line number given is next line in c source code.


Could you please give details on how I can reproduce the hardfault, I do not have a ble_nano (16 KB RAM nRF51), but pca10028 boards should have a similar nRF51 (32 KB RAM).

Hmmmm…. I see Kconfig.defconfig.nrf51822_QFAA has:
15 config ISR_STACK_SIZE
16 default 640

Could you please use 1024 bytes, and give a try, if your observation is related to insufficient ISR call stack? (pong sample of the micro:bit uses 1024, maybe for a reason!).

-Vinayak

_______________________________________________
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 Scott,

On 25 Aug 2017, at 05:23, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@nordicsemi.no> wrote:


On 24 Aug 2017, at 17:21, Scott Nelson <scott@scottnelson.co> 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
Nice! May I ask if there where any preceding console messages? usually, the assert condition is printed along with the function name.
If I where to force an assert (break the design), this is how I would get (for samples/bluetooth/peripheral on my local repo):

[bt] [INF] show_dev_info: Identity: da:d7:35:42:55:80 (random)
[2017-08-25 05:28:18.771] [bt] [INF] show_dev_info: HCI: version 5.0 (0x09) revision 0x0000, manufacturer 0xffff
[2017-08-25 05:28:18.779] [bt] [INF] show_dev_info: LMP: version 5.0 (0x09) subver 0xffff
[2017-08-25 05:28:18.785] [bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[2017-08-25 05:28:18.797] [bt] [WRN] irk_init: Using temporary IRK
[2017-08-25 05:28:18.802] Bluetooth initialized
[2017-08-25 05:28:18.806] Advertising successfully started
[2017-08-25 05:28:18.913] [bt] [ERR] radio_event_adv_prepare: assert: '!_radio.ticker_id_prepare' failed
[2017-08-25 05:28:18.920] ***** HARD FAULT *****
[2017-08-25 05:28:18.922] Executing thread ID (thread): 0x200021a4
[2017-08-25 05:28:18.926] Faulting instruction address: 0xf7be
[2017-08-25 05:28:18.930] Fatal fault in ISR! Spinning...


and,

arm-none-eabi-addr2line -afie samples/bluetooth/peripheral/outdir/nrf51_pca10028/zephyr.elf 0xf7be
0x0000f7be
radio_event_adv_prepare
/Users/hemal/workspace/zephyr/subsys/bluetooth/controller/ll_sw/ctrl.c:5551

and the line in the source file:

5541
5542 void radio_event_adv_prepare(u32_t ticks_at_expire, u32_t remainder,
5543 u16_t lazy, void *context)
5544 {
5545 ARG_UNUSED(lazy);
5546 ARG_UNUSED(context);
5547
5548 DEBUG_RADIO_PREPARE_A(1);
5549
5550 LL_ASSERT(!_radio.ticker_id_prepare);
5551 _radio.ticker_id_prepare = RADIO_TICKER_ID_ADV;
5552


The faulting instruction address corresponds to the next program counter, hence the line number given is next line in c source code.


Could you please give details on how I can reproduce the hardfault, I do not have a ble_nano (16 KB RAM nRF51), but pca10028 boards should have a similar nRF51 (32 KB RAM).

Hmmmm…. I see Kconfig.defconfig.nrf51822_QFAA has:
15 config ISR_STACK_SIZE
16 default 640

Could you please use 1024 bytes, and give a try, if your observation is related to insufficient ISR call stack? (pong sample of the micro:bit uses 1024, maybe for a reason!).

-Vinayak

_______________________________________________
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
 

On 24 Aug 2017, at 17:21, Scott Nelson <scott@scottnelson.co> 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
Nice! May I ask if there where any preceding console messages? usually, the assert condition is printed along with the function name.

-Vinayak


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
 

2561 - 2580 of 2712