Date   

Re: request of information

Boie, Andrew P
 

Thread level memory protection is a feature that is currently under development. We are targeting the MMU on x86 and ARM MPUs first. We expect to have this fully working and documented for the LTS release in Q1 2018.

 

Andrew

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Novello Giampiero
Sent: Thursday, September 28, 2017 7:06 AM
To: Zephyr-users@...
Subject: [Zephyr-users] request of information

 

Sorry i'm new.

May I know if is possible to make 2 simple task static task   in the same cpu ,

and this 2 task are protected by MPU of an cortex M4 processor? 

Those 2 task can comunicate only using a queue?

How can do that in zephyr ? is possible or not ? There is an application note?

 

 

Best Regards

Novello G.


request of information

novello
 

Sorry i'm new.
May I know if is possible to make 2 simple task static task   in the same cpu ,
and this 2 task are protected by MPU of an cortex M4 processor? 
Those 2 task can comunicate only using a queue?
How can do that in zephyr ? is possible or not ? There is an application note?


Best Regards
Novello G.


Re: nRF52832 hardware cycle count freezing at chip start

Chettimada, Vinayak Kariappa
 

Commented in the PR. We can discuss further there. Thank you for your analysis.

 

-Vinayak

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Thiago Silveira
Sent: Thursday, September 28, 2017 11:25 AM
To: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Cc: zephyr-users@...
Subject: Re: [Zephyr-users] nRF52832 hardware cycle count freezing at chip start

 

Hi everyone,

It's been a little over a month now, but I promised I would explore this issue further and report back. :-)
Turns out the problem is caused by activating the watchdog, but the watchdog itself is not the issue.

At first I thought it was related to this errata: http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.EngB.errata%2Fanomaly_832_20.html
And, turns out, it kind of is. However, this issue is already fixed when activating the LFCLK in _k32src_start. So, why the RTC isn't running properly?

To spare you my whole journey, I'll say that the relevant code is here, right at the start. The TODO and 'if' says it all:

(...)

static int _k32src_start(struct device *dev, clock_control_subsys_t sub_system)

{

          u32_t lf_clk_src;

          u32_t intenset;

 

          /* TODO: implement the ref count and re-entrancy guard, if a use-case

          * needs it.

          */

 

          if ((NRF_CLOCK->LFCLKSTAT & CLOCK_LFCLKSTAT_STATE_Msk)) {

                      return 0;

          }
(...)

After watchdog is activated, LFCLK is forcibly on at all times, as it needs it. After a soft reset, WDT registers are retained, so when the nRF resets, the LFCLK source is on but it isn't configured properly.

When _k32src_start is called to activate and configure the LFCLK source, it checks to see if LFCLK is running.

Thanks to the watchdog, it is, so it stops there and doesn't configure it. The fix is detailed at the TODO.

So much for a week (and more!) of debugging and going through kernel code.

I'm just glad it's fixed -- now we don't have to wait a couple minutes until code starts running after we flash. We had been disabling the watchdog when developing to remedy this... we ended up forgetting to activate it on a couple of field test runs, doh! :-)


That being said...

1) I have opened a pull request to address this issue, which can be located here: https://github.com/zephyrproject-rtos/zephyr/pull/4096


I would be very glad if you guys (Carles and Vinaytak) could review it, as you initially assisted me with this issue.

2) I plan to move forward with merging my nRF5 watchdog driver, which VInayak suggested I write.

Because of this problem, I was reluctant to merge it. Now that this issue is resolved, I will open a pull request to merge the driver in. I'm aware that Michał Kruszewski is working on a new iteration of the watchdog driver and I voiced my concerns about the current watchdog driver API to him, but I think that having a nRF5 driver, even in current API form, is only beneficial to Zephyr and its' users, as any production-ready application *will* require a proper watchdog. Once the RFC is approved, I or someone else could easily port it to the new API.

Best regards,

Thiago

 

2017-08-21 14:44 GMT-03:00 Thiago Silveira <thiago@...>:

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

Thiago Silveira
 

Hi everyone,

It's been a little over a month now, but I promised I would explore this issue further and report back. :-)
Turns out the problem is caused by activating the watchdog, but the watchdog itself is not the issue.

At first I thought it was related to this errata: http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.EngB.errata%2Fanomaly_832_20.html
And, turns out, it kind of is. However, this issue is already fixed when activating the LFCLK in _k32src_start. So, why the RTC isn't running properly?

To spare you my whole journey, I'll say that the relevant code is here, right at the start. The TODO and 'if' says it all:

(...)
static int _k32src_start(struct device *dev, clock_control_subsys_t sub_system)
{
u32_t lf_clk_src;
u32_t intenset;

/* TODO: implement the ref count and re-entrancy guard, if a use-case
* needs it.
*/

if ((NRF_CLOCK->LFCLKSTAT & CLOCK_LFCLKSTAT_STATE_Msk)) {
return 0;
}
(...)

After watchdog is activated, LFCLK is forcibly on at all times, as it needs it. After a soft reset, WDT registers are retained, so when the nRF resets, the LFCLK source is on but it isn't configured properly.
When _k32src_start is called to activate and configure the LFCLK source, it checks to see if LFCLK is running.
Thanks to the watchdog, it is, so it stops there and doesn't configure it. The fix is detailed at the TODO.
So much for a week (and more!) of debugging and going through kernel code.

I'm just glad it's fixed -- now we don't have to wait a couple minutes until code starts running after we flash. We had been disabling the watchdog when developing to remedy this... we ended up forgetting to activate it on a couple of field test runs, doh! :-)

That being said...

1) I have opened a pull request to address this issue, which can be located here: https://github.com/zephyrproject-rtos/zephyr/pull/4096

I would be very glad if you guys (Carles and Vinaytak) could review it, as you initially assisted me with this issue.

2) I plan to move forward with merging my nRF5 watchdog driver, which VInayak suggested I write.

Because of this problem, I was reluctant to merge it. Now that this issue is resolved, I will open a pull request to merge the driver in. I'm aware that Michał Kruszewski is working on a new iteration of the watchdog driver and I voiced my concerns about the current watchdog driver API to him, but I think that having a nRF5 driver, even in current API form, is only beneficial to Zephyr and its' users, as any production-ready application *will* require a proper watchdog. Once the RFC is approved, I or someone else could easily port it to the new API.

Best regards,

Thiago

2017-08-21 14:44 GMT-03:00 Thiago Silveira <thiago@...>:

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@nordicsemi.no>:
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: IPSP bluetooth sample with QEMU (ping fails)

Priyanka
 

Hi

Thank you Paul for the suggestions.
We are waiting for the real hardware (KW41Z board), meanwhile I should test IPSP with QEMU.

Unfortunately, I do not have a 96b_carbon board. Does anyone know if IPv6 over BLE, IPSP work on FRDM boards?

Eventually, we would like to test the following scenario;
KW41Z running Zephyr + 6loble (IPv6 over BLE) with a x86 Linux + KW41Z-FRDM / USB.

Any idea if IPv6 over BLE / 6lowpan works over KW41Z running Zephyr? Has anyone tested IPv6 over BLE with Zephyr over KW41Z board?

What is the current status on IPv6 over BLE?

I found some links on IPv6 over BLE, but couldn't figure out much from them. Is there any other link I should look at?

https://github.com/zephyrproject-rtos/zephyr/pull/1151
net: l2: bt: Make 6lowpan/BLE be compatible with Linux by default #1151

https://github.com/zephyrproject-rtos/zephyr/issues/3111
IPv6 over BLE no longer works after commit 2e9fd88 #3111


Update on IPSP sample with QEMU (ping works, but there are errors like fatal kernel error etc., )
-----------------------------------------------------------------------------------------------------------------------------------------

I tested IPSP bluetooth sample with QEMU again and ping works now. Tests with telnet and echo-client work as well.

$ ping6 2001:db8::1
PING 2001:db8::1(2001:db8::1) 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=27.2 ms
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=4.45 ms
64 bytes from 2001:db8::1: icmp_seq=3 ttl=64 time=2.13 ms
64 bytes from 2001:db8::1: icmp_seq=4 ttl=64 time=3.73 ms
^C

s$ telnet 2001:db8::1 4242
Trying 2001:db8::1...
Connected to 2001:db8::1.
Escape character is '^]'.
hello
hello
okkkkkkkk
okkkkkkkk

$ sudo ./echo-client -i bt0 2001:db8::1
Binding to 2001:db8::2
.......

However, I get warnings
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread

and then after a while it terminates with the following error (fatal kernel error and fatal fault in ISR!)

***** CPU Page Fault (error code 0x00000002)
Supervisor thread wrote address 0x00000008
PDE: 0x025 Present Read-only User
PTE: 0x000 Non-present Read-only Supervisor
Current thread ID = 0x004015e0
Faulting segment:address = 0x0008:0x00013170
eax: 0x00402094, ebx: 0x00403510, ecx: 0x0040200a, edx: 0x00402050
esi: 0x00000000, edi: 0x000001f4, ebp: 0x00417774, esp: 0x00417764
eflags: 0x202
Fatal fault in ISR! Spinning...
Terminate emulator due to fatal kernel error
$zephyr/scripts/Makefile.qemu:26: recipe for target 'run' failed
make[2]: *** [run] Error 1
make[2]: Leaving directory 'zephyr/samples/bluetooth/ipsp/outdir/qemu_x86'
Makefile:178: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '...../zephyr'
/zephyr/Makefile.inc:91: recipe for target 'run' failed
make: *** [run] Error 2

-------------------------------------------------

Following is the entire output.


[QEMU] CPU: qemu32

[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
[ipsp] [INF] init_app: Run IPSP sample
[ipsp] [INF] listen: Starting to wait
[bt] [ERR] read_payload: Not enough space in buffer
[bt] [WRN] hci_cmd_done: pool id 4 pool 0x0041add4 != &hci_cmd_pool 0x0041adb4
[ipsp] [DBG] build_reply_pkt: UDP IPv6 received 1 bytes
[ipsp] [DBG] build_reply_pkt: Received 1 bytes, sending 1 bytes
[ipsp] [DBG] pkt_sent: Sent 1 bytes
[ipsp] [DBG] build_reply_pkt: UDP IPv6 received 6 bytes
[ipsp] [DBG] build_reply_pkt: Received 6 bytes, sending 6 bytes
[ipsp] [DBG] pkt_sent: Sent 6 bytes
[ipsp] [DBG] build_reply_pkt: UDP IPv6 received 4 bytes
[ipsp] [DBG] build_reply_pkt: Received 4 bytes, sending 4 bytes
[ipsp] [DBG] pkt_sent: Sent 4 bytes
[ipsp] [DBG] build_reply_pkt: UDP IPv6 received 26 bytes
[ipsp] [DBG] build_reply_pkt: Received 26 bytes, sending 26 bytes
[ipsp] [DBG] pkt_sent: Sent 26 bytes
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread
[ipsp] [DBG] build_reply_pkt: UDP IPv6 received 1232 bytes
[ipsp] [DBG] build_reply_pkt: Received 1232 bytes, sending 1232 bytes
[ipsp] [DBG] build_reply_pkt: UDP IPv6 received 1 bytes
[ipsp] [DBG] build_reply_pkt: Received 1 bytes, sending 1 bytes
[ipsp] [DBG] pkt_sent: Sent 1 bytes
[ipsp] [DBG] build_reply_pkt: UDP IPv6 received 256 bytes
[ipsp] [DBG] build_reply_pkt: Received 256 bytes, sending 256 bytes
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread

[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread
[bt] [WRN] read_payload: Failed to allocate, deferring to rx_thread
[bt] [WRN] hci_cmd_done: pool id 4 pool 0x0041add4 != &hci_cmd_pool 0x0041adb4
[bt] [WRN] hci_cmd_done: pool id 4 pool 0x0041add4 != &hci_cmd_pool 0x0041adb4

[ipsp] [DBG] build_reply_pkt: TCP IPv6 received 7 bytes
[ipsp] [DBG] build_reply_pkt: Received 7 bytes, sending 7 bytes
[ipsp] [DBG] pkt_sent: Sent 7 bytes
[ipsp] [DBG] pkt_sent: Sent 7 bytes
[ipsp] [DBG] pkt_sent: Sent 0 bytes
[ipsp] [DBG] build_reply_pkt: TCP IPv6 received 11 bytes
[ipsp] [DBG] build_reply_pkt: Received 11 bytes, sending 11 bytes
[ipsp] [DBG] pkt_sent: Sent 11 bytes
[ipsp] [DBG] pkt_sent: Sent 11 bytes
[ipsp] [DBG] pkt_sent: Sent 0 bytes
[ipsp] [DBG] build_reply_pkt: TCP IPv6 received 36 bytes
[ipsp] [DBG] build_reply_pkt: Received 36 bytes, sending 36 bytes
[ipsp] [DBG] pkt_sent: Sent 36 bytes
[ipsp] [DBG] pkt_sent: Sent 36 bytes
[ipsp] [DBG] pkt_sent: Sent 0 bytes
[ipsp] [DBG] build_reply_pkt: TCP IPv6 received 86 bytes
[ipsp] [DBG] build_reply_pkt: Received 86 bytes, sending 86 bytes
[ipsp] [DBG] pkt_sent: Sent 86 bytes
[ipsp] [DBG] pkt_sent: Sent 0 bytes

[ipsp] [DBG] build_reply_pkt: TCP IPv6 received 7 bytes
[ipsp] [DBG] build_reply_pkt: Received 7 bytes, sending 7 bytes
***** CPU Page Fault (error code 0x00000002)
Supervisor thread wrote address 0x00000008
PDE: 0x025 Present Read-only User
PTE: 0x000 Non-present Read-only Supervisor
Current thread ID = 0x004015e0
Faulting segment:address = 0x0008:0x00013170
eax: 0x00402094, ebx: 0x00403510, ecx: 0x0040200a, edx: 0x00402050
esi: 0x00000000, edi: 0x000001f4, ebp: 0x00417774, esp: 0x00417764
eflags: 0x202
Fatal fault in ISR! Spinning...
Terminate emulator due to fatal kernel error
/zephyr/scripts/Makefile.qemu:26: recipe for target 'run' failed
make[2]: *** [run] Error 1
make[2]: Leaving directory '/zephyr/samples/bluetooth/ipsp/outdir/qemu_x86'
Makefile:178: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/Downloads/zephyr-LTI/zephyr'
/zephyr/Makefile.inc:91: recipe for target 'run' failed
make: *** [run] Error 2

-----------------------------------------------------------------------------------

Has anyone come across similar errors?

I found a link on Bluetooth: ipsp fixes
https://github.com/zephyrproject-rtos/zephyr/pull/1537/files?diff=split
Not sure if this would fix the above issues.


Best Regards,
Priyanka

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org
[mailto:zephyr-users- bounces@lists.zephyrproject.org] On Behalf Of
Paul Sokolovsky
Sent: Thursday, September 21, 2017 9:46 PM
To: Priyanka Rawat <priyanka.rawat@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] IPSP bluetooth sample with QEMU (ping
fails)

Hello Priyanka,

On Mon, 18 Sep 2017 17:04:25 +0000
Priyanka Rawat <priyanka.rawat@nxp.com> wrote:

While testing bluetooth IPSP sample (recent master branch of zephyr)
with Qemu, ping fails (no response found) and

ping: sendmsg: No buffer space available (wireshark capture attached).

I noticed that there are some old issues and bugs reported on the
IPSP sample. However, I couldn't figure out if the bugs/issues have
been resolved already.

What is the current status on the IPSP bluetooth sample? Anyone
tested IPSP sample with Qemu?
I tested it on BOARD=96b_carbon (real hardware) straight before 1.9
release, everything worked well, and I captured docs required to set
it up at
https://github.com/zephyrproject-rtos/zephyr/pull/1185 (if you would
find detailed instructions for setting up IPSP in Zephyr useful,
please add +1 comment to that pull request).

What's your usecase for working with BLE in qemu_x86 in general? I
fully understand and support the idea of being able to run it via
QEMU, so everyone can test it without a real hardware, but based on
your own experience, not everything works smooth there. So, if you're
just interested in BLE and/or IPSP, I'd suggest to try them on some
real board as an alternative to QEMU, that's known to work pretty well (across few boards).

I myself a novice with BLE support in Zephyr (usually work on other
things), and would be interested to get it work with QEMU too, but
don't know when I'll be able to pay enough attention to it, as I'm
currently working on few other things keeping me pretty busy.


I get the following for the IPSP test:

zephyr/samples/bluetooth/ipsp$ make BOARD=qemu_x86
CONF_FILE=prj_dbg.conf run

[QEMU] CPU: qemu32
qemu-system-i386: warning: Unknown firmware file in legacy mode:
genroms/multiboot.bin

[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 [ipsp] [INF] init_app: Run IPSP sample [ipsp]
[INF]
listen: Starting to wait


On host PC

----------------

I enabled 6lowpan and bluetooth_6lowpan


# modprobe bluetooth_6lowpan
# modprobe 6lowpan
# echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
# echo connect "00:aa:01:00:00:23 1"
/sys/kernel/debug/bluetooth/6lowpan_control


$ sudo hcitool lescan
[sudo] password for nxf32661:
LE Scan ...
00:AA:01:00:00:23 (unknown)
00:AA:01:00:00:23 Test IPSP node


$ sudo ./echo-client -i bt0 2001:db8::1 Binding to 2001:db8::2
Timeout while waiting idx 0 len 1 Timeout while waiting idx 1 len 6
Timeout while waiting idx 2 len 4 Timeout while waiting idx 3 len 26
Timeout while waiting idx 4 len 1232 Timeout while waiting idx 5 len
1 Timeout while waiting idx 6 len 256

$ ping6 -I bt0 2001:db8::1
PING 2001:db8::1(2001:db8::1) from 2001:db8::2 bt0: 56 data bytes
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

$ ifconfig bt0
bt0 Link encap:UNSPEC HWaddr
00-AA-01-FF-FE-01-00-24-00-00-00-00-00-00-00-00 inet6 addr:
fe80::2aa:1ff:fe01:24/64 Scope:Link inet6 addr: 2001:db8::2/64
Scope:Global UP POINTOPOINT RUNNING MULTICAST MTU:1280 Metric:1
RX packets:76 errors:0 dropped:0 overruns:0 frame:0
TX packets:91 errors:0 dropped:91 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:7128 (7.1 KB) TX bytes:8532 (8.5 KB)

Thanks
Priyanka


--
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
_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Re: IPSP bluetooth sample with QEMU (ping fails)

Vakul Garg <vakul.garg@...>
 

Hi Paul

On the same topic, I am facing a different issue on my setup.
On running Bluetooth ipsp using QEMU, I get a zephyr error about insufficient buffer space.

shell> [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
[ipsp] [INF] init_app: Run IPSP sample
[ipsp] [INF] listen: Starting to wait
[bt] [ERR] read_payload: Not enough space in buffer
[bt] [WRN] hci_cmd_done: pool id 6 pool 0x0041d570 != &hci_cmd_pool 0x0041d550
QEMU: Terminated

To reproduce this, I run Bluetooth/ipsp example with emulator Bluetooth controller and btproxy.
Now doing hciconfig -a on a terminal trigger about error.

[b16394@lti emulator]$ sudo ./btvirt -l1
Bluetooth emulator ver 5.47

[b16394@lti bluez-5.47]$ sudo ./tools/btproxy -i 0 -u
Listening on /tmp/bt-server-bredr

[root@lti bluetooth]# sudo hciconfig -a
hci0: Type: Primary 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:99 errors:0
TX bytes:3226 acl:0 sco:0 commands:122 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: 'LTI'
Can't read class of device on hci0: Connection timed out (110)
[root@lti bluetooth]#


Regards

Vakul

-----Original Message-----
From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-
bounces@lists.zephyrproject.org] On Behalf Of Paul Sokolovsky
Sent: Thursday, September 21, 2017 9:46 PM
To: Priyanka Rawat <priyanka.rawat@nxp.com>
Cc: zephyr-users@lists.zephyrproject.org
Subject: Re: [Zephyr-users] IPSP bluetooth sample with QEMU (ping fails)

Hello Priyanka,

On Mon, 18 Sep 2017 17:04:25 +0000
Priyanka Rawat <priyanka.rawat@nxp.com> wrote:

While testing bluetooth IPSP sample (recent master branch of zephyr)
with Qemu, ping fails (no response found) and

ping: sendmsg: No buffer space available (wireshark capture attached).

I noticed that there are some old issues and bugs reported on the IPSP
sample. However, I couldn't figure out if the bugs/issues have been
resolved already.

What is the current status on the IPSP bluetooth sample? Anyone tested
IPSP sample with Qemu?
I tested it on BOARD=96b_carbon (real hardware) straight before 1.9 release,
everything worked well, and I captured docs required to set it up at
https://github.com/zephyrproject-rtos/zephyr/pull/1185 (if you would find
detailed instructions for setting up IPSP in Zephyr useful, please add +1
comment to that pull request).

What's your usecase for working with BLE in qemu_x86 in general? I fully
understand and support the idea of being able to run it via QEMU, so
everyone can test it without a real hardware, but based on your own
experience, not everything works smooth there. So, if you're just interested in
BLE and/or IPSP, I'd suggest to try them on some real board as an alternative
to QEMU, that's known to work pretty well (across few boards).

I myself a novice with BLE support in Zephyr (usually work on other things),
and would be interested to get it work with QEMU too, but don't know when
I'll be able to pay enough attention to it, as I'm currently working on few other
things keeping me pretty busy.


I get the following for the IPSP test:

zephyr/samples/bluetooth/ipsp$ make BOARD=qemu_x86
CONF_FILE=prj_dbg.conf run

[QEMU] CPU: qemu32
qemu-system-i386: warning: Unknown firmware file in legacy mode:
genroms/multiboot.bin

[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 [ipsp] [INF] init_app: Run IPSP sample [ipsp] [INF]
listen: Starting to wait


On host PC

----------------

I enabled 6lowpan and bluetooth_6lowpan


# modprobe bluetooth_6lowpan
# modprobe 6lowpan
# echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
# echo connect "00:aa:01:00:00:23 1"
/sys/kernel/debug/bluetooth/6lowpan_control


$ sudo hcitool lescan
[sudo] password for nxf32661:
LE Scan ...
00:AA:01:00:00:23 (unknown)
00:AA:01:00:00:23 Test IPSP node


$ sudo ./echo-client -i bt0 2001:db8::1 Binding to 2001:db8::2 Timeout
while waiting idx 0 len 1 Timeout while waiting idx 1 len 6 Timeout
while waiting idx 2 len 4 Timeout while waiting idx 3 len 26 Timeout
while waiting idx 4 len 1232 Timeout while waiting idx 5 len 1 Timeout
while waiting idx 6 len 256

$ ping6 -I bt0 2001:db8::1
PING 2001:db8::1(2001:db8::1) from 2001:db8::2 bt0: 56 data bytes
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

$ ifconfig bt0
bt0 Link encap:UNSPEC HWaddr
00-AA-01-FF-FE-01-00-24-00-00-00-00-00-00-00-00 inet6 addr:
fe80::2aa:1ff:fe01:24/64 Scope:Link inet6 addr: 2001:db8::2/64
Scope:Global UP POINTOPOINT RUNNING MULTICAST MTU:1280 Metric:1
RX packets:76 errors:0 dropped:0 overruns:0 frame:0
TX packets:91 errors:0 dropped:91 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:7128 (7.1 KB) TX bytes:8532 (8.5 KB)

Thanks
Priyanka


--
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
_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Re: mbedtls config file

Vakul Garg <vakul.garg@...>
 

Hi Sergio

The suggested way would require to change zephyr code. I want to avoid making local changes in vanilla zephyr codebase. So some kind of macro which adds application defined config file path in  ext/lib/crypto/mbedtls/Makefile.inc is what I am searching.

Vakul

From: Rodriguez, Sergio SF
Sent: Wednesday, 27 September, 12:58 AM
Subject: Re: [Zephyr-users] mbedtls config file
To: zephyr-users@...


On Tue, 2017-09-26 at 11:16 +0000, Vakul Garg wrote: > Hi >   > I want to create my own mbedtls config file and maintain it as part > of my codebase. > The Makefiles in my code are according to zephyr reference manual. >   > How can I tell the zephyr build system pick up the mbedtls > configuration file from a given path in my code base rather than > ‘zephyr/ext/lib/crypto/mbedtls/configs’? >   This can be a local change, see if it works for you, in the file ext/lib/crypto/mbedtls/Makefile.include add the path where your configuration files are in the include path subdir-ccflags-$(CONFIG_MBEDTLS_BUILTIN) += -I/path/myconfig and use a unique name for your configuration file in your prj.conf CONFIG_MBEDTLS_CFG_FILE="my-config.h"  let me know if it helps > Regards >   > Vakul > _______________________________________________ > Zephyr-users mailing list > Zephyr-users@... > https://lists.zephyrproject.org/mailman/listinfo/zephyr-users _______________________________________________ Zephyr-users mailing list Zephyr-users@... https://lists.zephyrproject.org/mailman/listinfo/zephyr-users


Re: mbedtls config file

Rodriguez, Sergio SF <sergio.sf.rodriguez@...>
 

On Tue, 2017-09-26 at 11:16 +0000, Vakul Garg wrote:
Hi
 
I want to create my own mbedtls config file and maintain it as part
of my codebase.
The Makefiles in my code are according to zephyr reference manual.
 
How can I tell the zephyr build system pick up the mbedtls
configuration file from a given path in my code base rather than
‘zephyr/ext/lib/crypto/mbedtls/configs’?
 
This can be a local change, see if it works for you, in the file

ext/lib/crypto/mbedtls/Makefile.include

add the path where your configuration files are in the include path

subdir-ccflags-$(CONFIG_MBEDTLS_BUILTIN) += -I/path/myconfig

and use a unique name for your configuration file in your prj.conf

CONFIG_MBEDTLS_CFG_FILE="my-config.h" 

let me know if it helps


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


mbedtls config file

Vakul Garg <vakul.garg@...>
 

Hi

 

I want to create my own mbedtls config file and maintain it as part of my codebase.

The Makefiles in my code are according to zephyr reference manual.

 

How can I tell the zephyr build system pick up the mbedtls configuration file from a given path in my code base rather than ‘zephyr/ext/lib/crypto/mbedtls/configs’?

 

Regards

 

Vakul


Re: Mesh provisioning w/ SILabs Android Mesh app

Steve Brown
 

Johan,

On Sun, 2017-09-24 at 19:48 +0300, Johan Hedberg wrote:
Hi Steve,

On Sun, Sep 24, 2017, Steve Brown wrote:
===================================================================
======================
[bt] [ERR] prov_start: Invalid authentication method: 0x02; action:
0x00; size: 0x04
===================================================================
======================
At least some versions of the SiLabs app had a bug with OOB handling
that was causing similar results as above. A simple solution was to
disable OOB provisioning support from the Zephyr side, i.e. set all
output* members to zero in struct bt_mesh_prov in main.c. That said,
I'm
not sure if the issue you're seeing is the same.

[bt] [ERR] hci_acl_handle: Invalid Tx Enqueue
[bt] [ERR] send_frag: Unable to send to driver (err -22)
This is something coming from the controller code that I haven't seen
before. Maybe the controller maintainers from Nordic have some idea.

Johan
That was it!

I disabled OOB and it's working.

The Invalid Tx Enqueue error is gone too.  

Thanks,

Steve


Re: Mesh provisioning w/ SILabs Android Mesh app

Johan Hedberg
 

Hi Steve,

On Sun, Sep 24, 2017, Steve Brown wrote:
=========================================================================================
[bt] [ERR] prov_start: Invalid authentication method: 0x02; action: 0x00; size: 0x04
=========================================================================================
At least some versions of the SiLabs app had a bug with OOB handling
that was causing similar results as above. A simple solution was to
disable OOB provisioning support from the Zephyr side, i.e. set all
output* members to zero in struct bt_mesh_prov in main.c. That said, I'm
not sure if the issue you're seeing is the same.

[bt] [ERR] hci_acl_handle: Invalid Tx Enqueue
[bt] [ERR] send_frag: Unable to send to driver (err -22)
This is something coming from the controller code that I haven't seen
before. Maybe the controller maintainers from Nordic have some idea.

Johan


Mesh provisioning w/ SILabs Android Mesh app

Steve Brown
 

Has anybody been able to provision samples/bluetooth/mesh with v1.0.2?

I get the following error below on my RedBear Nano2.

Steve

Kernel stacks:
main (real size 512): unused 280 usage 232 / 512 (45 %)
idle (real size 320): unused 272 usage 48 / 320 (15 %)
interrupt (real size 2048): unused 1672 usage 376 / 2048 (18 %)
workqueue (real size 2048): unused 1744 usage 304 / 2048 (14 %)
[bt] [DBG] adv_thread: (0x200007c4) Proxy Advertising up to -1 ms
[bt] [DBG] bt_mesh_pb_gatt_open: (0x20001a88) conn 0x2000049c
prio recv thread stack (real size 748): unused 488 usage 260 / 748 (34 %)
recv thread stack (real size 4396): unused 3832 usage 564 / 4396 (12 %)
prio recv thread stack (real size 748): unused 488 usage 260 / 748 (34 %)
[bt] [DBG] bt_mesh_pb_gatt_recv: (0x20001a88) 2 bytes: 0000
[bt] [DBG] prov_invite: (0x20001a88) Attention Duration: 0 seconds
recv thread stack (real size 4396): unused 3624 usage 772 / 4396 (17 %)
[bt] [DBG] bt_mesh_pb_gatt_recv: (0x20001a88) 6 bytes: 020000020004
[bt] [DBG] prov_start: (0x20001a88) Algorithm: 0x00
[bt] [DBG] prov_start: (0x20001a88) Public Key: 0x00
[bt] [DBG] prov_start: (0x20001a88) Auth Method: 0x02
[bt] [DBG] prov_start: (0x20001a88) Auth Action: 0x00
[bt] [DBG] prov_start: (0x20001a88) Auth Size: 0x04
=========================================================================================
[bt] [ERR] prov_start: Invalid authentication method: 0x02; action: 0x00; size: 0x04
=========================================================================================
[bt] [DBG] bt_mesh_pb_gatt_recv: (0x20001a88) 65 bytes: 030cd335ab54b2e5095e46c52bafb51ed26fca5faf49fe6b55a92652bb0c86d2879fde098f92eddc06bca81944d774f91e0d5b1ebe7038693e213044916db1ed
[bt] [DBG] prov_pub_key: (0x20001a88) Remote Public Key: 0cd335ab54b2e5095e46c52bafb51ed26fca5faf49fe6b55a92652bb0c86d2879fde098f92eddc06bca81944d774f91e0d5b1ebe7038693e213044916db1ed69
[bt] [DBG] send_pub_key: (0x20001a88) Local Public Key: 9bea5c734577bb2bdb5251fe8f3e589a7201bcf5932838f7353990e33a5754622334e47ee9097fb60eed1c8abe8c50df15cf445269d28159f565ca8759a4642c
[bt] [ERR] hci_acl_handle: Invalid Tx Enqueue
[bt] [ERR] send_frag: Unable to send to driver (err -22)
Kernel stacks:
main (real size 512): unused 280 usage 232 / 512 (45 %)
idle (real size 320): unused 272 usage 48 / 320 (15 %)
interrupt (real size 2048): unused 1672 usage 376 / 2048 (18 %)
workqueue (real size 2048): unused 1744 usage 304 / 2048 (14 %)
tx stack (real size 940): unused 552 usage 388 / 940 (41 %)
[bt] [DBG] bt_mesh_pb_gatt_close: (0x20001a88) conn 0x2000049c
[bt] [DBG] bt_mesh_adv_update: (0x20001a88)
[bt] [DBG] adv_thread: (0x200007c4) Proxy Advertising up to -1 ms
[bt] [DBG] prov_dh_key_cb: (0x2000033c) 0x200025a8
[bt] [DBG] prov_dh_key_cb: (0x2000033c) DHkey: 93786861a21a66499c69e9e56af54d5f8b80167fa3e375f3d032d83cd5739c42
ecc stack (real size 1324): unused 448 usage 876 / 1324 (66 %)
[bt] [DBG] bt_mesh_adv_send: (0x20001b80) type 0x02 len 23: 00dddf0000000000000000000000000000000000000000
[bt] [DBG] adv_send: (0x200007c4) type 2 len 23: 00dddf0000000000000000000000000000000000000000
[bt] [DBG] adv_send: (0x200007c4) count 3 interval 20ms duration 90ms
[bt] [DBG] adv_send: (0x200007c4) Advertising started. Sleeping 90 ms
[bt] [DBG] adv_send: (0x200007c4) Advertising stopped


Re: IPSP bluetooth sample with QEMU (ping fails)

Paul Sokolovsky
 

Hello Priyanka,

On Mon, 18 Sep 2017 17:04:25 +0000
Priyanka Rawat <priyanka.rawat@nxp.com> wrote:

While testing bluetooth IPSP sample (recent master branch of zephyr)
with Qemu, ping fails (no response found) and

ping: sendmsg: No buffer space available (wireshark capture attached).

I noticed that there are some old issues and bugs reported on the
IPSP sample. However, I couldn't figure out if the bugs/issues have
been resolved already.

What is the current status on the IPSP bluetooth sample? Anyone
tested IPSP sample with Qemu?
I tested it on BOARD=96b_carbon (real hardware) straight before 1.9
release, everything worked well, and I captured docs required to set it
up at https://github.com/zephyrproject-rtos/zephyr/pull/1185 (if you
would find detailed instructions for setting up IPSP in Zephyr useful,
please add +1 comment to that pull request).

What's your usecase for working with BLE in qemu_x86 in general? I
fully understand and support the idea of being able to run it via QEMU,
so everyone can test it without a real hardware, but based on your own
experience, not everything works smooth there. So, if you're just
interested in BLE and/or IPSP, I'd suggest to try them on some real
board as an alternative to QEMU, that's known to work pretty well
(across few boards).

I myself a novice with BLE support in Zephyr (usually work on other
things), and would be interested to get it work with QEMU too, but
don't know when I'll be able to pay enough attention to it, as I'm
currently working on few other things keeping me pretty busy.


I get the following for the IPSP test:

zephyr/samples/bluetooth/ipsp$ make BOARD=qemu_x86
CONF_FILE=prj_dbg.conf run

[QEMU] CPU: qemu32
qemu-system-i386: warning: Unknown firmware file in legacy mode:
genroms/multiboot.bin

[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 [ipsp] [INF] init_app: Run IPSP sample
[ipsp] [INF] listen: Starting to wait


On host PC

----------------

I enabled 6lowpan and bluetooth_6lowpan


# modprobe bluetooth_6lowpan
# modprobe 6lowpan
# echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
# echo connect "00:aa:01:00:00:23 1"
/sys/kernel/debug/bluetooth/6lowpan_control


$ sudo hcitool lescan
[sudo] password for nxf32661:
LE Scan ...
00:AA:01:00:00:23 (unknown)
00:AA:01:00:00:23 Test IPSP node


$ sudo ./echo-client -i bt0 2001:db8::1
Binding to 2001:db8::2
Timeout while waiting idx 0 len 1
Timeout while waiting idx 1 len 6
Timeout while waiting idx 2 len 4
Timeout while waiting idx 3 len 26
Timeout while waiting idx 4 len 1232
Timeout while waiting idx 5 len 1
Timeout while waiting idx 6 len 256

$ ping6 -I bt0 2001:db8::1
PING 2001:db8::1(2001:db8::1) from 2001:db8::2 bt0: 56 data bytes
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

$ ifconfig bt0
bt0 Link encap:UNSPEC HWaddr
00-AA-01-FF-FE-01-00-24-00-00-00-00-00-00-00-00 inet6 addr:
fe80::2aa:1ff:fe01:24/64 Scope:Link inet6 addr: 2001:db8::2/64
Scope:Global UP POINTOPOINT RUNNING MULTICAST MTU:1280 Metric:1
RX packets:76 errors:0 dropped:0 overruns:0 frame:0
TX packets:91 errors:0 dropped:91 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:7128 (7.1 KB) TX bytes:8532 (8.5 KB)

Thanks
Priyanka


--
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: Testing Bluetooth with QEMU

Priyanka
 

Hi Paul


Yes, first I did use "make run".


In the Zephyr's application console QEMU :

-------------------------------------------------------------

Bluetooth gets initialized and Beacon started. All looks fine there.


Then, in the Host PC ( Linux console) :

-----------------------------------------------------

I do "hciconfig"  to see hci0 and hci1

With 'hciconfig" it looks all ok.


It is only when I use "hciconfig -a"  in the Host PC (Linux console) then

I get the following in the Zephyr's app console QEMU.

In the Zephyr's application console QEMU :

------------------------------------------

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

I get this error for other bluetooth samples (e.g., peripheral_hr and IPSP) as well.

Here is my set up to make it more clear to you.

Terminal 1

----------------

# 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


Host PC (Terminal 2)
--------------------
$ sudo tools/btproxy -u
Listening on /tmp/bt-server-bredr
Opening user channel for hci0
New client connected


Host PC (Terminal 3)

-------------------------------

$ hciconfig

hci2:    Type: BR/EDR  Bus: USB
    BD Address: 08:ED:B9:DD:DD:86  ACL MTU: 1021:8  SCO MTU: 64:1
    UP RUNNING
    RX bytes:589 acl:0 sco:0 events:36 errors:0
    TX bytes:2564 acl:0 sco:0 commands:36 errors:0

hci1:    Type: BR/EDR  Bus: VIRTUAL
    BD Address: 00:AA:01:01:00:24  ACL MTU: 192:1  SCO MTU: 0:0
    UP RUNNING
    RX bytes:0 acl:0 sco:0 events:77 errors:0
    TX bytes:1205 acl:0 sco:0 commands:77 errors:0

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:77 errors:0
    TX bytes:1389 acl:0 sco:0 commands:97 errors:0



Host PC (Terminal 3)

-------------------------------


$ sudo 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)

Whereas at the other end on Terminal 1 (Zephyr's application console QEMU), I get the following.

Terminal 1 (Zephyr's application console QEMU) :

-------------------------------------------------

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

I restarted QEMU to see if it works, but I get the same error again.

Thanks
Priyanka


From: Paul Sokolovsky <paul.sokolovsky@...>
Sent: Monday, September 18, 2017 4:41 PM
To: Priyanka Rawat
Cc: zephyr-users@...
Subject: Re: [Zephyr-users] Testing Bluetooth with QEMU
 
Hello Priyanka,

On Mon, 18 Sep 2017 09:24:55 +0000
Priyanka Rawat <priyanka.rawat@...> wrote:

[]


> When I do "make qemu" : Bluetooth is initialized and Beacon started.
> BD address is 00:aa:01:00:00:23 (public).

I can't say much of BT emulation using QEMU - never tried that, but
you should use "make run" instead of "make qemu". It's an oversight
that the latter still works, and at least some issues were spotted
with it: https://github.com/zephyrproject-rtos/zephyr/issues/1522

>
>
> However, "hciconfig -a" gives
>
> [bt] [ERR] read_payload: Not enough space in buffer
>
> [bt] [WRN] hci_cmd_done: pool id 1 pool 0x00405098 != &hci_cmd_pool
> 0x00405078

I'd suggest to describe more explicitly where/how '"hciconfig -a"
gives' that: at the Linux console while running the command, in the
Linux syslog, in Zephyr's application console QEMU, etc. (Maybe it's
obvious, but I wouldn't jump to reproduce it with the info given, though
again, I may be biased as I never tried that).



Otherwise, if you don't receive a reply here, can you consider joining
the IRC channel and try to ping @jhe and other Bluetooth folks there?
(I'd hope they read the list, but I sometimes myself skip to check it
for few days.)

Sorry for not bringing more specific answers.

[]

>
> Thanks
> Priyanka
>



--
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
twitter.com
1,732 tweets • 605 photos/videos • 3,058 followers. Check out the latest Tweets from Linaro (@LinaroOrg)


IPSP bluetooth sample with QEMU (ping fails)

Priyanka
 

Hi


While testing bluetooth IPSP sample (recent master branch of zephyr) with Qemu, ping fails (no response found) and 

ping: sendmsg: No buffer space available (wireshark capture attached).

I noticed that there are some old issues and bugs reported on the IPSP sample. However, I couldn't figure out if the bugs/issues have been resolved already.

What is the current status on the IPSP bluetooth sample? Anyone tested IPSP sample with Qemu?


I get the following for the IPSP test:

zephyr/samples/bluetooth/ipsp$ make BOARD=qemu_x86 CONF_FILE=prj_dbg.conf run


[QEMU] CPU: qemu32
qemu-system-i386: warning: Unknown firmware file in legacy mode: genroms/multiboot.bin

[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
[ipsp] [INF] init_app: Run IPSP sample
[ipsp] [INF] listen: Starting to wait

On host PC

----------------

I enabled 6lowpan and bluetooth_6lowpan


# modprobe bluetooth_6lowpan
# modprobe 6lowpan                  
# echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
# echo connect "00:aa:01:00:00:23 1" > /sys/kernel/debug/bluetooth/6lowpan_control


$ sudo hcitool lescan
[sudo] password for nxf32661:
LE Scan ...
00:AA:01:00:00:23 (unknown)
00:AA:01:00:00:23 Test IPSP node

$ sudo ./echo-client -i bt0 2001:db8::1
Binding to 2001:db8::2
Timeout while waiting idx 0 len 1
Timeout while waiting idx 1 len 6
Timeout while waiting idx 2 len 4
Timeout while waiting idx 3 len 26
Timeout while waiting idx 4 len 1232
Timeout while waiting idx 5 len 1
Timeout while waiting idx 6 len 256

$ ping6 -I bt0 2001:db8::1
PING 2001:db8::1(2001:db8::1) from 2001:db8::2 bt0: 56 data bytes
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

$ ifconfig bt0
bt0       Link encap:UNSPEC  HWaddr 00-AA-01-FF-FE-01-00-24-00-00-00-00-00-00-00-00  
          inet6 addr: fe80::2aa:1ff:fe01:24/64 Scope:Link
          inet6 addr: 2001:db8::2/64 Scope:Global
          UP POINTOPOINT RUNNING MULTICAST  MTU:1280  Metric:1
          RX packets:76 errors:0 dropped:0 overruns:0 frame:0
          TX packets:91 errors:0 dropped:91 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:7128 (7.1 KB)  TX bytes:8532 (8.5 KB)

Thanks
Priyanka


Re: Testing Bluetooth with QEMU

Paul Sokolovsky
 

Hello Priyanka,

On Mon, 18 Sep 2017 09:24:55 +0000
Priyanka Rawat <priyanka.rawat@nxp.com> wrote:

[]


When I do "make qemu" : Bluetooth is initialized and Beacon started.
BD address is 00:aa:01:00:00:23 (public).
I can't say much of BT emulation using QEMU - never tried that, but
you should use "make run" instead of "make qemu". It's an oversight
that the latter still works, and at least some issues were spotted
with it: https://github.com/zephyrproject-rtos/zephyr/issues/1522



However, "hciconfig -a" gives

[bt] [ERR] read_payload: Not enough space in buffer

[bt] [WRN] hci_cmd_done: pool id 1 pool 0x00405098 != &hci_cmd_pool
0x00405078
I'd suggest to describe more explicitly where/how '"hciconfig -a"
gives' that: at the Linux console while running the command, in the
Linux syslog, in Zephyr's application console QEMU, etc. (Maybe it's
obvious, but I wouldn't jump to reproduce it with the info given, though
again, I may be biased as I never tried that).

Otherwise, if you don't receive a reply here, can you consider joining
the IRC channel and try to ping @jhe and other Bluetooth folks there?
(I'd hope they read the list, but I sometimes myself skip to check it
for few days.)

Sorry for not bringing more specific answers.

[]


Thanks
Priyanka


--
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: Testing Bluetooth with QEMU

Luiz Augusto von Dentz
 

Hi Priyanka,

On Mon, Sep 18, 2017 at 12:24 PM, Priyanka Rawat <priyanka.rawat@nxp.com> wrote:
Hi


I am testing samples/bluetooth/beacon with QEMU.

The version of zephyr is recent master branch.


1)

The beacon sample test with local Bluetooth adapter on Linux PC, gives the
init failed error

[QEMU] CPU: qemu32
qemu-system-i386: warning: Unknown firmware file in legacy mode:
genroms/multiboot.bin
Starting Beacon Demo
Bluetooth init failed (err -35)

2)

So, I test the sample "beacon" with emulation support with BlueZ.

Attached wireshark capture.

Could someone verify if my setup (tools and commands) is correct or I am
missing something here?

For further bluetooth tests, has anyone tried the tools "l2ping" and
"l2test" ?

When I do "make qemu" : Bluetooth is initialized and Beacon started. BD
address is 00:aa:01:00:00:23 (public).


However, "hciconfig -a" gives

[bt] [ERR] read_payload: Not enough space in buffer

[bt] [WRN] hci_cmd_done: pool id 1 pool 0x00405098 != &hci_cmd_pool
0x00405078

I have following running in different terminals.

$ sudo ./btvirt -l2
Bluetooth emulator ver 5.46

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

# zephyr/samples/bluetooth/beacon$ make qemu
[QEMU] CPU: qemu32
qemu-system-i386: warning: Unknown firmware file in legacy mode:
genroms/multiboot.bin

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 don't get this error when using a real controller:

Starting Beacon Demo
[bt] [INF] show_dev_info: Identity: 00:1b:dc:07:31:88 (public)
[bt] [INF] show_dev_info: HCI: version 4.0 (0x06) revision 0x2031,
manufacturer 0x000a
[bt] [INF] show_dev_info: LMP: version 4.0 (0x06) subver 0x2031
Bluetooth initialized
Beacon started

Perhaps this has something to do with the emulator as it is now
emulating 5.0 features there maybe something not working quite right.


$ hciconfig -a

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)

$ sudo btmgmt --index 1

[hci1]# find -l
Discovery started
hci1 type 6 discovering on
hci1 dev_found: 00:AA:01:00:00:23 type LE Public rssi 127 flags 0x0000
AD flags 0x06
name Zephyr Heartrate Sensor
hci1 type 6 discovering off

Thanks
Priyanka



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


--
Luiz Augusto von Dentz


Re: 96boards Nitrogen

Steve Brown
 

Hi Vanayak,

I've got some more information.

I converted the SDK's radio_test to run on both the nano2 and the
nitrogen.

The nano2 is transmitting continuous carrier (test "c") on 2402 and the
nitrogen on 2426. TX power is -4 dBm. The data rate is 1M.

The attached sample was from ubertooth-specan-ui. Lots of jitter at
2426 with both nitrogen boards.

Steve

On Mon, 2017-09-18 at 05:04 +0200, Vinayak Kariappa wrote:
Hi Steve,

Good. You have clarified that indeed radio h/w is live and kicking.

May be something around the antenna matching is bad that only some
peer see the transmissions.

I can be suspicious that the Factory Configuration Information is
probably erased (like a full erase done using nrfjprog). You can
check if the identity address printed on  "init" in shell application
remains same after power resets, if so, then I have no more ideas.

Few of us are available at #zephyrproject on freenode.net, in case
you prefer to IRC.

- Vinayak

On Fri, Sep 15, 2017 at 7:27 PM, Steve Brown <sbrown@cortland.com>
wrote:
More

On Thu, 2017-09-14 at 19:54 +0000, Chettimada, Vinayak Kariappa
wrote:

Hello and blinky work. BT does not.
Ok, so the CPU and UART works :-)
And, the 32KHz clock domain works, hence the blinks.

Now, CPU can run from internal High Frequency RC or External
crystal.
If your 32MHz crystal on the board has dry solder (or what ever
has
happened), then most probably internal RC remains to clock the
SoC.
But 2.4GHz radio will not be 2.4GHz.

Zephyr v1.9 has Radio Direct Test Mode implementation, hci_uart
sample can be used with DTM HCI commands to test the radio. The
DTM
HCI commands will fail to respond if the HF clock cannot source
from
a stable crystal.


And, yes nitrogen_beacon.hex from http://builds.96boards.org/re
leas
es/n
itrogen/zephyr-1.8/ flashed to the nano2 advertises. There's no
console
output as I explained previously.

I'm now more convinced that the devices somehow got damaged in
transit
from Seeed. 
Very unlikely (and likely based on conditions), I use nRF51
dongles
over 5 years now, carry it around in bare hands, worst I have
done is
to have my 32KHz crystal go out of its spec. but BLE operational
using the 32KHz RC.
 

I'll report when I get the ones I ordered from Digikey. I
expect
them
to work just fine.

If you are curious about what happened to the radios, I'd be
glad
to
send you the 2 I got from Seeed.
I think Seeed need to contact our support (I am just a software
guy).


The shipment didn't seem to have been opened. I'm pretty ESD
conscious
at my end.

Steve
These tests were run using tests/bluetooth/shell.

I found and fired up an ubertooth. The 3 advertising freqs are spot
on.

Whatever is on the air isn't decoded by ubertooth-btle or bluez w/
a
CSR (0a12:0001) dongle.

So, I tried your iOS nRF connect app. It picks up the
advertisements. I
can also connect from my iPhone.

All 3 applications function with the nano2.

Next I tested with a rpi3. It sees the advertisements and can also
connect to the nitrogen. Curiously, ubertooth picks up the SCAN_REQ
from the rpi3, but not the responses from the nitrogen. All the
devices
are within 1 meter of each other.

So, I have 2 apps (nRF connect & rpi3) that see what the nitrogen
puts
on the air and 2 apps (ubertooth & x64 w/ bluez & CSR dongle) that
do
not.

Versions

ubertooth:
  Firmware version: 2017-03-R2 (API:1.02)
  ubertooth 2017-03-R2 (dominicgs@hydrogen) Mon Mar 13 16:09:02 MDT
2017

x64 w/ bluez: V5.47

nRF Connect: V1.7.5

rpi3: raspbian Linux raspberrypi 4.9.43-v7+ w/ bluez V5.43

Can you think of any possible explanation?

Steve





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


Testing Bluetooth with QEMU

Priyanka
 

Hi


I am testing samples/bluetooth/beacon with QEMU.

The version of zephyr is recent master branch.


1)

The beacon sample test with local Bluetooth adapter on Linux PC, gives the init failed error

[QEMU] CPU: qemu32
qemu-system-i386: warning: Unknown firmware file in legacy mode: genroms/multiboot.bin
Starting Beacon Demo
Bluetooth init failed (err -35)

2)

So, I test the sample "beacon" with emulation support with BlueZ.

Attached wireshark capture.

Could someone verify if my setup (tools and commands) is correct or I am missing something here? 

For further bluetooth tests, has anyone tried the tools "l2ping" and "l2test" ?

When I do "make qemu" : Bluetooth is initialized and Beacon started. BD address is 00:aa:01:00:00:23 (public).


However, "hciconfig -a" gives 

[bt] [ERR] read_payload: Not enough space in buffer

[bt] [WRN] hci_cmd_done: pool id 1 pool 0x00405098 != &hci_cmd_pool 0x00405078

I have following running in different terminals.

$ sudo ./btvirt -l2
Bluetooth emulator ver 5.46

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

# zephyr/samples/bluetooth/beacon$ make qemu
[QEMU] CPU: qemu32
qemu-system-i386: warning: Unknown firmware file in legacy mode: genroms/multiboot.bin

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


$ hciconfig -a

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)

$ sudo btmgmt --index 1

[hci1]# find -l
Discovery started
hci1 type 6 discovering on
hci1 dev_found: 00:AA:01:00:00:23 type LE Public rssi 127 flags 0x0000
AD flags 0x06
name Zephyr Heartrate Sensor
hci1 type 6 discovering off

Thanks
Priyanka



Re: 96boards Nitrogen

Steve Brown
 

Vinayak,

The identity address is persistent across power resets.

I'll report on the behavior of the 2 units arriving this week. If they
also show compatibility issues, I'll continue to investigate.

Thanks for your help.

Steve

On Mon, 2017-09-18 at 05:04 +0200, Vinayak Kariappa wrote:
Hi Steve,

Good. You have clarified that indeed radio h/w is live and kicking.

May be something around the antenna matching is bad that only some
peer see the transmissions.

I can be suspicious that the Factory Configuration Information is
probably erased (like a full erase done using nrfjprog). You can
check if the identity address printed on  "init" in shell application
remains same after power resets, if so, then I have no more ideas.

Few of us are available at #zephyrproject on freenode.net, in case
you prefer to IRC.

- Vinayak

On Fri, Sep 15, 2017 at 7:27 PM, Steve Brown <sbrown@cortland.com>
wrote:
More

On Thu, 2017-09-14 at 19:54 +0000, Chettimada, Vinayak Kariappa
wrote:

Hello and blinky work. BT does not.
Ok, so the CPU and UART works :-)
And, the 32KHz clock domain works, hence the blinks.

Now, CPU can run from internal High Frequency RC or External
crystal.
If your 32MHz crystal on the board has dry solder (or what ever
has
happened), then most probably internal RC remains to clock the
SoC.
But 2.4GHz radio will not be 2.4GHz.

Zephyr v1.9 has Radio Direct Test Mode implementation, hci_uart
sample can be used with DTM HCI commands to test the radio. The
DTM
HCI commands will fail to respond if the HF clock cannot source
from
a stable crystal.


And, yes nitrogen_beacon.hex from http://builds.96boards.org/re
leas
es/n
itrogen/zephyr-1.8/ flashed to the nano2 advertises. There's no
console
output as I explained previously.

I'm now more convinced that the devices somehow got damaged in
transit
from Seeed. 
Very unlikely (and likely based on conditions), I use nRF51
dongles
over 5 years now, carry it around in bare hands, worst I have
done is
to have my 32KHz crystal go out of its spec. but BLE operational
using the 32KHz RC.
 

I'll report when I get the ones I ordered from Digikey. I
expect
them
to work just fine.

If you are curious about what happened to the radios, I'd be
glad
to
send you the 2 I got from Seeed.
I think Seeed need to contact our support (I am just a software
guy).


The shipment didn't seem to have been opened. I'm pretty ESD
conscious
at my end.

Steve
These tests were run using tests/bluetooth/shell.

I found and fired up an ubertooth. The 3 advertising freqs are spot
on.

Whatever is on the air isn't decoded by ubertooth-btle or bluez w/
a
CSR (0a12:0001) dongle.

So, I tried your iOS nRF connect app. It picks up the
advertisements. I
can also connect from my iPhone.

All 3 applications function with the nano2.

Next I tested with a rpi3. It sees the advertisements and can also
connect to the nitrogen. Curiously, ubertooth picks up the SCAN_REQ
from the rpi3, but not the responses from the nitrogen. All the
devices
are within 1 meter of each other.

So, I have 2 apps (nRF connect & rpi3) that see what the nitrogen
puts
on the air and 2 apps (ubertooth & x64 w/ bluez & CSR dongle) that
do
not.

Versions

ubertooth:
  Firmware version: 2017-03-R2 (API:1.02)
  ubertooth 2017-03-R2 (dominicgs@hydrogen) Mon Mar 13 16:09:02 MDT
2017

x64 w/ bluez: V5.47

nRF Connect: V1.7.5

rpi3: raspbian Linux raspberrypi 4.9.43-v7+ w/ bluez V5.43

Can you think of any possible explanation?

Steve





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

2381 - 2400 of 2575