Date   

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


Re: 96boards Nitrogen

Vinayak Kariappa
 

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@...> 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/releas
> > 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


Re: 96boards Nitrogen

Steve Brown
 

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/releas
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


Re: TCP assert error logs

Paul Sokolovsky
 

Hello Vakul,

On Thu, 14 Sep 2017 05:14:55 +0000
Vakul Garg <vakul.garg@nxp.com> wrote:

[]

Yes, POSIX bits is Zephyr are very initial and very bare so far - a
bit of threads and a bit of sockets support. There're neither
full-featured poll() implementation, nor fd's (file descriptors),
nor other POSIX IPC.
I used TCP/UDP POSIX sockets between two local apps just because I
thought I can't multiplex a local IPC method such as mailbox/pipe
with network sockets connected to a remote endpoint.

If I change my code to use net_context apis for remote networking and
use mailbox/pipe between local apps, will I be able to multiplex
net_contexts with mailbox/pipes using k_poll mechanism?
Yes, there's k_poll() which can work with native Zephyr synchronization
primitives. But synchronization primitives is also what it's limited
to. A net context is not such. You interact with it not by using k_poll,
but by installing callbacks which will be called when something happens.

Then you can do something in a callback (put something in a queue,
release a semaphore, raise an event), and use that with k_poll. But
that's exactly how sockets are implemented!

So, there're few choices:

1. Implement more POSIX synchronization primitives. That would take
some time and effort of course.

2. If needed to be done quickly for experimentation, can use sockets'
net_context::recv_q in k_poll, with a usual warning that it's not
intended to be used like that, and is an implementation detail which can
be changed at any time.

3. The worst way (IMHO) is to duplicate what BSD Sockets already do in
some adhoc code. This way, Zephyr doesn't grow POSIX functionality,
doesn't have its sockets subsystem used, but the adhoc code is all
yours to maintain ;-).

[]

--
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: 96boards Nitrogen

Steve Brown
 

Vinayak,

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/releas
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
I found tests/bluetooth/shell. I also found my wispy toy spec analyzer.

With "scan on", I receive advertisements. So, the 32Mhz xtal is ok.
With "advertise on", I observe rf on 3 freq's. The wispy doesn't seem
to calibrate properly, so I don't know the exact freqs, but they are
the same as the nano2. The difference is that "hcitool lescan" receives
the nano2 advertisements, but nothing from the nitrogen.

Next, I will try to see what is actually on the air. I'll also try to
get accurate freqs for the advertisements.

Any ideas?

Steve


Re: 96boards Nitrogen

Chettimada, Vinayak Kariappa
 


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/releases/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


Re: 96boards Nitrogen

Steve Brown
 

Hi Vinayak,

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

Yes, we (for myself) are listening ;-)

You say beacon hex flashed to ble nano2 works (advertises).

1. Does hello world sample work (print out on UART)?
2. Does the samples/basic/blinky  work (flash LED) ?

Lets proceed with these.

Regards,
Vinayak



On 14 Sep 2017, at 21:03, Steve Brown <sbrown@cortland.com> wrote:

Ricardo,

On Thu, 2017-09-14 at 14:49 -0300, Ricardo Salveti de Araujo wrote:
On Thu, Sep 14, 2017 at 5:53 AM, Steve Brown <sbrown@cortland.com
wrote:
Richardo,

On Thu, 2017-09-14 at 01:47 -0300, Ricardo Salveti de Araujo
wrote:
On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@cortland
.com
 wrote:
Has anyone had success with samples/bluetooth/beacon on
this
device?

Even the nitrogen_beacon.hex file from 96boards.org won't
transmit.
The
console messages are as expected, but nothing on the air.
Same
results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does
transmit.
There
is no console output because a different uart is used, but
the
beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I
looked
at
the
errata and didn't see anything obvious.
It is supposed to just work, without any additional changes,
so
wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be
either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional.
Just
tested the beacon sample from Zephyr 1.9 and it is working
just
fine.

Cheers,
The boards are:
 v1.0 build date 09/19/2016
 v1.1 build date 02/16/2017

The nitrogen build uses pyOCD to flash the device. This works
as
expected.
By works as expected you mean including the BT radio?

However, copying a .bin file to /media/$USER/MBED gives the
following error:
"The interface firmware FAILED to parse the hex file" in
FAIL.TXT

If I copy a .hex file to the MBED disk, it isn't processed and
the
file
remains in the folder.

Both boards exhibit identical behavior.
Yeah, this looks like an issue in the firmware flashed in
LPC11U35.
Talking with Seeeds, it seems they originally flashed
https://github.com/xiongyihui/CMSIS-DAP/tree/arch_ble, but I
didn't
yet investigate to see why this is currently broken. Maybe it
assumes
the user will flash softdevice compatible fw by default, not
sure.

Cheers,
Thanks for the info on the CMSIS firmware. I'm not using it, but
thought that it might be connected to my radio problem. From your
comments, it's not.

pyocd-flashtool flashes the device with the expected console
output.
The radio doesn't work.

I've ordered another 2 from Digikey and will see how they behave.
When
I ordered them from Seeed, I never thought to check if they were
available locally.

I wonder if they got zapped during customs inspection. They
probably x-
ray the small boxes. I hope the customs inspector wears a film
badge.
If anybody from Nordic is listening, maybe they have an opinion.

Steve


_______________________________________________
Zephyr-users mailing list
Zephyr-users@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users
Hello and blinky work. BT does not.

And, yes nitrogen_beacon.hex from http://builds.96boards.org/releases/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.

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.

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

Steve


Re: 96boards Nitrogen

Chettimada, Vinayak Kariappa
 

Hi Steve,

Yes, we (for myself) are listening ;-)

You say beacon hex flashed to ble nano2 works (advertises).

1. Does hello world sample work (print out on UART)?
2. Does the samples/basic/blinky  work (flash LED) ?

Lets proceed with these.

Regards,
Vinayak



On 14 Sep 2017, at 21:03, Steve Brown <sbrown@...> wrote:

Ricardo,

On Thu, 2017-09-14 at 14:49 -0300, Ricardo Salveti de Araujo wrote:
On Thu, Sep 14, 2017 at 5:53 AM, Steve Brown <sbrown@...>
wrote:
Richardo,

On Thu, 2017-09-14 at 01:47 -0300, Ricardo Salveti de Araujo wrote:
On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@...

wrote:
Has anyone had success with samples/bluetooth/beacon on this
device?

Even the nitrogen_beacon.hex file from 96boards.org won't
transmit.
The
console messages are as expected, but nothing on the air. Same
results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does
transmit.
There
is no console output because a different uart is used, but the
beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked
at
the
errata and didn't see anything obvious.

It is supposed to just work, without any additional changes, so
wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be
either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional.
Just
tested the beacon sample from Zephyr 1.9 and it is working just
fine.

Cheers,

The boards are:
 v1.0 build date 09/19/2016
 v1.1 build date 02/16/2017

The nitrogen build uses pyOCD to flash the device. This works as
expected.

By works as expected you mean including the BT radio?

However, copying a .bin file to /media/$USER/MBED gives the
following error:
"The interface firmware FAILED to parse the hex file" in FAIL.TXT

If I copy a .hex file to the MBED disk, it isn't processed and the
file
remains in the folder.

Both boards exhibit identical behavior.

Yeah, this looks like an issue in the firmware flashed in LPC11U35.
Talking with Seeeds, it seems they originally flashed
https://github.com/xiongyihui/CMSIS-DAP/tree/arch_ble, but I didn't
yet investigate to see why this is currently broken. Maybe it assumes
the user will flash softdevice compatible fw by default, not sure.

Cheers,

Thanks for the info on the CMSIS firmware. I'm not using it, but
thought that it might be connected to my radio problem. From your
comments, it's not.

pyocd-flashtool flashes the device with the expected console output.
The radio doesn't work.

I've ordered another 2 from Digikey and will see how they behave. When
I ordered them from Seeed, I never thought to check if they were
available locally.

I wonder if they got zapped during customs inspection. They probably x-
ray the small boxes. I hope the customs inspector wears a film badge.
If anybody from Nordic is listening, maybe they have an opinion.

Steve


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


Re: 96boards Nitrogen

Steve Brown
 

Ricardo,

On Thu, 2017-09-14 at 14:49 -0300, Ricardo Salveti de Araujo wrote:
On Thu, Sep 14, 2017 at 5:53 AM, Steve Brown <sbrown@cortland.com>
wrote:
Richardo,

On Thu, 2017-09-14 at 01:47 -0300, Ricardo Salveti de Araujo wrote:
On Wed, Sep 13, 2017 at 6:37 PM, Steve Brown <sbrown@cortland.com
wrote:
Has anyone had success with samples/bluetooth/beacon on this
device?

Even the nitrogen_beacon.hex file from 96boards.org won't
transmit.
The
console messages are as expected, but nothing on the air. Same
results
on two recent boards from Seeed.

The same .hex file flashed to a redbear ble nano2 does
transmit.
There
is no console output because a different uart is used, but the
beacons
are on the air.

The designation on the nRF52 is N52832/QFAAB0/1616BD. I looked
at
the
errata and didn't see anything obvious.
It is supposed to just work, without any additional changes, so
wonder
if this could be hw issues.

Can you check the hw revision for your Nitrogens (should be
either
v0.9, v1.0 or v1.1)?

I got several from v0.9 and v1.1 and they are all functional.
Just
tested the beacon sample from Zephyr 1.9 and it is working just
fine.

Cheers,
The boards are:
 v1.0 build date 09/19/2016
 v1.1 build date 02/16/2017

The nitrogen build uses pyOCD to flash the device. This works as
expected.
By works as expected you mean including the BT radio?

However, copying a .bin file to /media/$USER/MBED gives the
following error:
"The interface firmware FAILED to parse the hex file" in FAIL.TXT

If I copy a .hex file to the MBED disk, it isn't processed and the
file
remains in the folder.

Both boards exhibit identical behavior.
Yeah, this looks like an issue in the firmware flashed in LPC11U35.
Talking with Seeeds, it seems they originally flashed
https://github.com/xiongyihui/CMSIS-DAP/tree/arch_ble, but I didn't
yet investigate to see why this is currently broken. Maybe it assumes
the user will flash softdevice compatible fw by default, not sure.

Cheers,
Thanks for the info on the CMSIS firmware. I'm not using it, but
thought that it might be connected to my radio problem. From your
comments, it's not.

pyocd-flashtool flashes the device with the expected console output.
The radio doesn't work.

I've ordered another 2 from Digikey and will see how they behave. When
I ordered them from Seeed, I never thought to check if they were
available locally.

I wonder if they got zapped during customs inspection. They probably x-
ray the small boxes. I hope the customs inspector wears a film badge.
If anybody from Nordic is listening, maybe they have an opinion.

Steve

2421 - 2440 of 2607