|
Mesh sample Of zephyer
Lalit-LINUX
Hello All,
Can Any one help me to how to setup for mesh sample of Zephyr or actually how it works ?? Thanks in advance.. -- Thanks and Regards Lalit Mahajan Three MediaTech Co. Pvt. Ltd. (m) +91-9970275835
|
|||
|
|
|||
|
Re: Projects in Zephyr v1.9.0 always rebuild even no changes in source code. How to fix this?
Carles Cufi
Hi Alan,
Is this on Windows using MSYS2?
Thanks,
Carles
From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...]
On Behalf Of Alan Low
Sent: 02 October 2017 12:46 To: zephyr-users@... Subject: [Zephyr-users] Projects in Zephyr v1.9.0 always rebuild even no changes in source code. How to fix this?
Hi,
I realized that the projects on Zephyr v1.9.0 release will always re-build when you type "make" even there is no changes in the source code. This does not happens on v1.8.0 release.
It would be quite annoying during source code development and will waste a lot of time waiting. Is there a way to fix this?
Best Regards,
|
|||
|
|
|||
|
Re: Projects in Zephyr v1.9.0 always rebuild even no changes in source code. How to fix this?
Paul Sokolovsky
Hello Alan,
On Mon, 2 Oct 2017 18:46:08 +0800 Alan Low <alanlhc@gmail.com> wrote: Hi,I can't reproduce this. So, feel free to provide additional information, steps to reproduce, etc. Actually, if you would have that information and "always rebuilds" matter is confirmed, feel free to open a bug with that info directly: https://github.com/zephyrproject-rtos/zephyr/issues Best Regards,-- 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: IPSP bluetooth sample with QEMU (ping fails)
Paul Sokolovsky
Hello Priyanka,
Sorry for the delay with response, I was at Linaro Connect with pretty packed local program. But we touched some questions you posed below with Maureen Helm and David Leach of NXP (both are in cc:), so hopefully I can bring some info. Another note is that I appreciate that you use Zephyr "user" mailing list - we have also the "devel" mailing, and some posts there would be better suited for the user lists. But your posts are actually the opposite, as they touch Zephyr development matters, so given there're not many responses, I may suggest to post there too, maybe people monitor it better. See also below for more comments. On Wed, 27 Sep 2017 20:27:05 +0000 Priyanka Rawat <priyanka.rawat@nxp.com> wrote: HiNot that I know of. And work done by Linaro on KW41Z/KW40Z revolves around 802.15.4 instead. For example, there's a Zephyr driver already in the tree, and 15.4-over-FSCI driver in the review: https://github.com/zephyrproject-rtos/zephyr/pull/868 . I found a bit strange there was no talk about BLE support, as "native" Hexiwear support is all about BLE (and communication with smartphones), and vice-versa, there's no sign of 15.4 support. At the Connect, David mentioned that BLE controller/stack might have been licensed from 3rd party vendor, and that poses additional organizational complications to its support in Zephyr. However, if you have a two-core system, like Hexiwear, where KW40Z is used completely as a block box BLE controller, you might be able to run it, if it uses the standard HCI protocol. At least we have couple of boards in Zephyr which use a similar arrangement. Eventually, we would like to test the following scenario;Same here at Linaro, except we want to do it over 15.4 ;-). Any idea if IPv6 over BLE / 6lowpan works over KW41Z running Zephyr?David (re)tested 6lowpan over 15.4 with KW41Z, it mostly works. Reproducing that is my immediate TODO once I finish with post-travel backlog. What is the current status on IPv6 over BLE?Well, it works (as an "experimental technology" would, with various requirements and caveats). I mention previously https://github.com/zephyrproject-rtos/zephyr/pull/1185 , which documents steps I went thru to get IPv6 over BLE running. I'd like to extend an invitation to add a "+1" style comment to it if you find it useful and would like to see it in the official documentation (otherwise, the reviewers of that patch are people who also maintain Linux kernel side of BLE and Bluez, and they assume that everyone runs the latest kernel and Bluez, which is of course not true ;-) ). Well, great news! What kernel version do you use? The latest news is that kernel 4.12 finally should fix all the issues (known issues) with 6lowpan/ble support: https://github.com/zephyrproject-rtos/zephyr/commit/a4e176b6a33ebbb0732e4a1d8cb174bb57a6f510 If you have below that, might as well be not too surprised with errors, etc. ;-). I myself running 4.10, waiting while my OS vendor will issue an (still experimental) 4.12 upgrade. ----------------------------------------------------------------------------------------------------------------------------------------- -- 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
|
|||
|
|
|||
|
Problem with echo_server / echo_client samples running in QEMU (No rule to make target 'qemu' ?)
Priyanka
Hello
While testing with recent zephyr (master branch), echo_server and echo_client samples running in QEMU fail.
Both "make server" and "make client" fail for QEMU with error No rule to make target 'qemu'.
I did "git pull" today, after that I get the error "No rule to make target 'qemu'.
Whereas with 3 weeks older master branch, this error was not there, but even earlier the sample "echo-client" failed to compile with errors such as
"undefined reference to net_app_send_pkt" as shown below.
I want to test IPv6 over 802.15.4 so I test the sample application zephyr/samples/net/ieee802154/qemu
Here are the steps to show my test set up:
Terminal 1 echo_server ----------------------------------- I modified makefile to do "make server" else I also tried "make BOARD=qemu_x86 CONF_FILE=prj_qemu_802154.conf server"
zephyr/samples/net/echo_server$ make server
or
zephyr/samples/net/echo_server$ make CONF_FILE=prj_qemu_802154.conf server
rm -f /tmp/ip-stack-server.in /tmp/ip-stack-server.out /tmp/ip-stack-client.in \ /tmp/ip-stack-client.out mkfifo /tmp/ip-stack-server.in mkfifo /tmp/ip-stack-server.out ln /tmp/ip-stack-server.in /tmp/ip-stack-client.out ln /tmp/ip-stack-server.out /tmp/ip-stack-client.in make[1]: Entering directory 'Downloads/zephyr-LTI/zephyr' make[2]: Entering directory '/Downloads/zephyr-LTI/zephyr/samples/net/echo_server/outdir/qemu_x86' CHK include/generated/generated_dts_board.conf UPD include/generated/generated_dts_board.conf CHK include/generated/generated_dts_board.conf make[2]: *** No rule to make target 'qemu'. Stop. make[2]: Leaving directory '/Downloads/zephyr-LTI/zephyr/samples/net/echo_server/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' --------------------------------
Moreover, echo_client fails to compile with following errors
zephyr/samples/net/echo_client$ make CONF_FILE=prj_qemu_802154.conf
In function `prepare_send_pkt':
/zephyr/samples/net/echo_client/src/echo-client.c:111: undefined reference to `net_app_get_net_pkt'
src/built-in.o: In function `send_udp_data': zephyr/samples/net/echo_client/src/udp.c:160: undefined reference to `net_app_send_pkt' src/built-in.o: In function `connect_udp': /zephyr/samples/net/echo_client/src/udp.c:262: undefined reference to `net_app_init_udp_client' zephyr/samples/net/echo_client/src/udp.c:273: undefined reference to `net_app_set_cb' /zephyr/samples/net/echo_client/src/udp.c:302: undefined reference to `net_app_connect' src/built-in.o: In function `stop_udp': zephyr/samples/net/echo_client/src/udp.c:360: undefined reference to `net_app_close' /zephyr/samples/net/echo_client/src/udp.c:361: undefined reference to `net_app_release' zephyr/samples/net/echo_client$ make CONF_FILE=prj_qemu_802154.conf client
make[1]: Entering directory 'Downloads/zephyr-LTI/zephyr'
make[2]: Entering directory 'Downloads/zephyr-LTI/zephyr/samples/net/echo_client/outdir/qemu_x86' CHK include/generated/generated_dts_board.conf UPD include/generated/generated_dts_board.conf CHK include/generated/generated_dts_board.conf make[2]: *** No rule to make target 'qemu'. Stop. make[2]: Leaving directory 'Downloads/zephyr-LTI/zephyr/samples/net/echo_client/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' Best,
Priyanka
|
|||
|
|
|||
|
Projects in Zephyr v1.9.0 always rebuild even no changes in source code. How to fix this?
Spider73
Hi, I realized that the projects on Zephyr v1.9.0 release will always re-build when you type "make" even there is no changes in the source code. This does not happens on v1.8.0 release. It would be quite annoying during source code development and will waste a lot of time waiting. Is there a way to fix this? Best Regards, Spider73
|
|||
|
|
|||
|
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?
|
|||
|
|
|||
|
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, 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; } 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.
2017-08-21 14:44 GMT-03:00 Thiago Silveira <thiago@...>:
|
|||
|
|
|||
|
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@...>:
|
|||
|
|
|||
|
Re: IPSP bluetooth sample with QEMU (ping fails)
Priyanka
Hi
toggle quoted messageShow quoted text
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-----
|
|||
|
|
|||
|
Re: IPSP bluetooth sample with QEMU (ping fails)
Vakul Garg <vakul.garg@...>
Hi Paul
toggle quoted messageShow quoted text
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-----
|
|||
|
|
|||
|
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:
HiThis 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
|
|||
|
|
|||
|
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,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
Hi Steve,
On Sun, Sep 24, 2017, Steve Brown wrote: =========================================================================================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 EnqueueThis 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)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.
-- 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.
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 $ 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.
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
|
|||
|
|
|||
