Date   

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
 


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>

2461 - 2480 of 2607