Date   

Bluetooth bonding

Timothy <tymoteusz.kielan@...>
 

Hello,

I'm trying to get CTS GATT profile working with my android phone over BLE.

I managed to connect from "nRF Connect" app where GATT server is serving CTS.

Here are my logs:

***** BOOTING ZEPHYR OS v1.9.99 - BUILD: Nov 16 2017 19:39:37 *****
shell> [bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [WRN] set_flow_control: Controller to host flow control not supported
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [WRN] set_static_addr: Using temporary static random address
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [INF] show_dev_info: Identity: cd:a5:23:43:2c:d0 (random)
[bt] [INF] show_dev_info: HCI: version 4.1 (0x07) revision 0x3107, manufacturer 0x0030
[bt] [INF] show_dev_info: LMP: version 4.1 (0x07) subver 0x0023
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005d48 handle 0x0001 uuid 2800 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005d5c handle 0x0002 uuid 2803 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005d70 handle 0x0003 uuid 2a00 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005d84 handle 0x0004 uuid 2803 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005d98 handle 0x0005 uuid 2a01 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005db8 handle 0x0006 uuid 2800 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005dcc handle 0x0007 uuid 2803 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005de0 handle 0x0008 uuid 2a05 perm 0x00
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005df4 handle 0x0009 uuid 2902 perm 0x03
[bt] [DBG] bt_smp_init: (0x20002848) LE SC disabled
[bt] [WRN] bt_pub_key_gen: ECC HCI commands not available
[bt] [WRN] irk_init: Using temporary IRK
Bluetooth initialized
[bt] [DBG] gatt_register: (0x20002848) attr 0x200056b0 handle 0x000a uuid 2800 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x200056c4 handle 0x000b uuid 2803 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x200056d8 handle 0x000c uuid 2a24 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x200056ec handle 0x000d uuid 2803 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005700 handle 0x000e uuid 2a29 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005750 handle 0x000f uuid 2800 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005764 handle 0x0010 uuid 2803 perm 0x01
[bt] [DBG] gatt_register: (0x20002848) attr 0x20005778 handle 0x0011 uuid 2a2b perm 0x03
[bt] [DBG] gatt_register: (0x20002848) attr 0x2000578c handle 0x0012 uuid 2902 perm 0x03
[bt] [DBG] update_range: (0x20002848) start 0x000a end 0x000e new_start 0x000f new_end 0x0012
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
Advertising successfully started
[bt] [DBG] bt_keys_find_irk: (0x20001258) 5e:a3:62:88:e1:04 (random)
[bt] [DBG] bt_keys_find_irk: (0x20001258) No IRK for 5e:a3:62:88:e1:04 (random)
[bt] [DBG] bt_conn_set_state: (0x20001258) disconnected -> connected
[bt] [DBG] bt_conn_ref: (0x20001258) handle 2049 ref 2
[bt] [DBG] bt_att_accept: (0x20001258) conn 0x200014b4 handle 2049
[bt] [DBG] bt_att_connected: (0x20001258) chan 0x20001988 cid 0x0004
[bt] [DBG] bt_gatt_connected: (0x20001258) conn 0x200014b4
[bt] [DBG] bt_smp_accept: (0x20001258) conn 0x200014b4 handle 2049
[bt] [DBG] bt_smp_connected: (0x20001258) chan 0x20001e20 cid 0x0006
Connected 5e:a3:62:88:e1:04 (random)
[bt] [DBG] bt_smp_send_security_req: (0x20001258) 
[bt] [DBG] bt_conn_send_cb: (0x20001258) conn handle 2049 buf len 6 cb 0x00000000
[bt] [DBG] bt_conn_unref: (0x20001258) handle 2049 ref 1
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) Adding conn 0x200014b4 to poll list
[bt] [DBG] bt_conn_process_tx: (0x200012cc) conn 0x200014b4
[bt] [DBG] send_buf: (0x200012cc) conn 0x200014b4 buf 0x20004324 len 6
[bt] [DBG] send_frag: (0x200012cc) conn 0x200014b4 buf 0x20004324 len 6 flags 0x00
[bt] [DBG] bt_conn_notify_tx: (0x200012cc) conn 0x200014b4
[bt] [DBG] add_pending_tx: (0x200012cc) conn 0x200014b4 cb 0x00000000
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) Adding conn 0x200014b4 to poll list
[bt] [DBG] bt_conn_ref: (0x20001258) handle 2049 ref 2
[bt] [DBG] bt_conn_unref: (0x20001258) handle 2049 ref 1
[bt] [DBG] bt_conn_ref: (0x20001258) handle 2049 ref 2
[bt] [DBG] bt_conn_unref: (0x20001258) handle 2049 ref 1
[bt] [DBG] bt_conn_le_param_update: (0x20002848) conn 0x200014b4 features 0x00 params (24-40 0 2000)
[bt] [DBG] bt_conn_ref: (0x20001258) handle 2049 ref 2
Kernel stacks:
main      (real size 1024):     unused 784      usage 240 / 1024 (23 %)
idle      (real size 256):      unused 200      usage 56 / 256 (21 %)
interrupt (real size 2048):     unused 1884     usage 164 / 2048 (8 %)
workqueue (real size 1024):     unused 316      usage 708 / 1024 (69 %)
rx stack (real size 1324):      unused 656      usage 668 / 1324 (50 %)
tx stack (real size 716):       unused 264      usage 452 / 716 (63 %)
[bt] [DBG] bt_conn_set_state: (0x20001258) connected -> disconnected
[bt] [DBG] bt_att_disconnected: (0x20001258) chan 0x20001988 cid 0x0004
[bt] [DBG] bt_gatt_disconnected: (0x20001258) conn 0x200014b4
[bt] [DBG] bt_smp_disconnected: (0x20001258) chan 0x20001e20 cid 0x0006
Disconnected from 5e:a3:62:88:e1:04 (random) (reason 19)
[bt] [DBG] bt_conn_unref: (0x20001258) handle 0 ref 1
[bt] [DBG] bt_conn_prepare_events: (0x200012cc) 
[bt] [DBG] bt_conn_notify_tx: (0x200012cc) conn 0x200014b4
[bt] [DBG] bt_conn_unref: (0x200012cc) handle 0 ref 0

Why am I seeing threads stack dump and sudden disconnect?
Where should I seek for help/information.

Please help me getting back on track.

Tim

--
Tim Kielan
Registered Linux User #239184

vim [noun] - lively or energetic spirit; enthusiasm; vitality


Re: No thread to run before main

Timothy <tymoteusz.kielan@...>
 

Hi,
Found that it was caused by some MPU fault.
Changing CONFIG_APPLICATION_MEMORY from y to n solved this strange issue.

Tim

On 15 November 2017 at 22:31, Timothy <tymoteusz.kielan@...> wrote:
Hi,

I have recently encountered weird issue.
This probably happen after rebase to zephyr 1.9.99


Before entering main() kernel stopped stating to thread to run:

0x0800c9e6 in _get_ready_q_head () at ../zephyr/kernel/sched.c:51
51 __ASSERT(!sys_dlist_is_empty(list),
(gdb) bt
#0  0x0800c9e6 in _get_ready_q_head () at ../zephyr/kernel/sched.c:51
#1  0x0800ca8a in _remove_thread_from_ready_q (thread=0x20000080 <k_sys_work_q+16>) at ../zephyr/kernel/sched.c:111
#2  0x0800ccea in _pend_current_thread (wait_q=wait_q@entry=0x20001d24 <sys_work_q_stack+932>, timeout=timeout@entry=-1) at ../zephyr/kernel/sched.c:220
#3  0x0800e814 in k_poll (events=events@entry=0x20001d5c <sys_work_q_stack+988>, num_events=num_events@entry=1, timeout=timeout@entry=-1) at ../zephyr/kernel/poll.c:249
#4  0x0800c7e2 in k_queue_poll (queue=0x20000070 <k_sys_work_q>, timeout=-1) at ../zephyr/kernel/queue.c:209
#5  0x0800c93a in k_queue_get (queue=queue@entry=0x20000070 <k_sys_work_q>, timeout=timeout@entry=-1) at ../zephyr/kernel/queue.c:250
#6  0x0800dd5c in work_q_main (work_q_ptr=0x20000070 <k_sys_work_q>, p2=<optimized out>, p3=<optimized out>) at ../zephyr/kernel/work_q.c:29
#7  0x0800d864 in _thread_entry (entry=0x800dd45 <work_q_main>, p1=<optimized out>, p2=<optimized out>, p3=<optimized out>) at ../zephyr/kernel/thread.c:194
#8  0xaaaaaaaa in ?? ()


This happen while executing

_sys_device_do_config_level(_SYS_INIT_LEVEL_POST_KERNEL);

before

_sys_device_do_config_level(_SYS_INIT_LEVEL_APPLICATION);

so app was not supposed to be started yet.

app is not the first thread to run?

thanks, Tim

--
Tim Kielan
Registered Linux User #239184

vim [noun] - lively or energetic spirit; enthusiasm; vitality



--
Tim Kielan
Registered Linux User #239184

vim [noun] - lively or energetic spirit; enthusiasm; vitality


NRF5x I2C driver and the sensor/th02 example

Arthur Mühlbeier <arthur.muehlbeier@...>
 

Hello,

I am trying to get running the example sensor/th02 with the nrf52_pca10040 or nrf51_pca10028. I disbaled the Grove LCD display in menuconfig. I configured the I2C drivers like https://imgur.com/Q6bh1XJ
I set the priority to 8 and tried also other values. I tried also different pins. This is what I get from the logic analyzer with both boards and different pins.
Time [s], Analyzer Name, Decoded Protocol Result
  • 1.631275625000000,I2C,Setup Write to ['128'] + ACK
  • 1.631315375000000,I2C,'3' + ACK
  • 1.631363125000000,I2C,'17' + ACK
  • 1.631439375000000,I2C,Setup Write to ['128'] + ACK
  • 1.631479125000000,I2C,'0' + ACK
  • 1.631538750000000,I2C,Setup Read to ['129'] + ACK
  • 1.631574625000000,I2C,'1' + NAK
  • 1.631641000000000,I2C,Setup Write to ['128'] + ACK
  • 1.631680750000000,I2C,'0' + ACK
  • 1.631740375000000,I2C,Setup Read to ['129'] + ACK
  • 1.631776125000000,I2C,'1' + NAK
  • 1.631842500000000,I2C,Setup Write to ['128'] + ACK
  • 1.631882375000000,I2C,'0' + ACK
  • 1.631942000000000,I2C,Setup Read to ['129'] + ACK
  • 1.631977750000000,I2C,'1' + NAK
  • ...
  • 1.763528625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763568375000000,I2C,'0' + ACK
  • 1.763628000000000,I2C,Setup Read to ['129'] + ACK
  • 1.763663750000000,I2C,'0' + NAK
  • 1.763730250000000,I2C,Setup Write to ['128'] + ACK
  • 1.763770000000000,I2C,'1' + ACK
  • 1.763829625000000,I2C,Setup Read to ['129'] + ACK
  • 1.763865375000000,I2C,M + NAK
  • 1.763931625000000,I2C,Setup Write to ['128'] + ACK
  • 1.763971250000000,I2C,'2' + ACK
  • 1.764030875000000,I2C,Setup Read to ['129'] + ACK
  • 1.764066625000000,I2C,'160' + NAK

So it seems that there is some working I2C functionality. But it seems to not working after the read command.
I tried the sensor with the Raspberry PI to find out what the expected output is and whether the sensor is working.
Raspi Log:
  • Time [s], Analyzer Name, Decoded Protocol Result
  • 1.055657625000000,I2C,Setup Write to ['128'] + ACK
  • 1.055747625000000,I2C,'3' + ACK
  • 1.055837625000000,I2C,'17' + ACK
  • 1.558392000000000,I2C,Setup Write to ['128'] + ACK
  • 1.558482000000000,I2C,'0' + ACK
  • 1.558650875000000,I2C,Setup Read to ['129'] + ACK
  • 1.558740875000000,I2C,'0' + ACK
  • 1.558830875000000,I2C,$ + ACK
  • 1.558920875000000,I2C,'140' + NAK

I have already asked for help in the IRC channel. I know that the "wrong" sequence is received after

if (offset == 0) {
      SYS_LOG_DBG("STARTRX");
      twi->TASKS_STARTRX = 1;
} in i2c_nrf5.c     function i2c_nrf5_read

Am I miconfiguring the I2C driver or is there a bug with the driver. Any help would be greatly appreciated. Thank you and have a nice day.

Arthur



Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Vikrant More <vikrant8051@...>
 

It is working now !!
I run hcitool lescan on another terminal & { discover-unprovisioned on , provision dddd0000000000000000000000000000 } on messhctl terminal.

Output -->
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[meshctl]# discover-unprovisioned on
set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
SetDiscoveryFilter success
Discovery started
Adapter property changed 
[CHG] Controller F0:03:8C:B7:5A:18 Discovering: yes
Mesh Provisioning Service (00001827-0000-1000-8000-00805f9b34fb)
Device UUID: dddd0000000000000000000000000000
OOB: 0000
[NEW] Device EA:E8:05:9B:16:1D Zephyr
[meshctl]# provision dddd0000000000000000000000000000
Trying to connect Device EA:E8:05:9B:16:1D Zephyr
Adapter property changed 
[CHG] Controller F0:03:8C:B7:5A:18 Discovering: no
[Zephyr]# Connection successful
[Zephyr]# Service added /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service0006
Service added /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a
Char added /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b:
Char added /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
Characteristic property changed /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
Notify started
Notify for Mesh Provisioning Out Data started
Open-Node: 0x1444640
Open-Prov: 0x1446380
Open-Prov: proxy 0x144a150
GATT-TX:  03 00 10 
Attempting to write /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
GATT-RX: 03 01 01 00 01 00 00 04 00 08 00 00 00 
Got provisioning data (12 bytes)
01 01 00 01 00 00 04 00 08 00 00 00 
GATT-TX:  03 02 00 00 02 03 04 
Attempting to write /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
GATT-TX:  03 03 a8 09 93 50 18 6f 0d 3a cb af 39 40 28 60 
GATT-TX:  9b fa 15 c9 
Attempting to write /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
Characteristic property changed /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
GATT-RX: 03 03 3a bd 0b 6e 8a d8 dd a9 92 22 a9 3c e4 c7 
GATT-RX: fe c3 f1 08 d9 5b ef ff 56 49 87 aa 64 ca 74 af 
GATT-RX: ed 3d 89 b9 60 9c b8 19 a3 54 16 a4 dd 12 8d 3c 
GATT-RX: f3 79 1c 18 15 2e 64 3a 4a e2 c1 34 19 c7 39 ab 
GATT-RX: 9f e3 
Got provisioning data (65 bytes)
03 3a bd 0b 6e 8a d8 dd a9 92 22 a9 3c e4 c7 fe 
c3 f1 08 d9 5b ef ff 56 49 87 aa 64 ca 74 af ed 
3d 89 b9 60 9c b8 19 a3 54 16 a4 dd 12 8d 3c f3 
79 1c 18 15 2e 64 3a 4a e2 c1 34 19 c7 39 ab 9f 
e3 
Request decimal key (0 - 9999)
[mesh] Enter Numeric key: 1234
GATT-TX:  03 05 79 75 31 d9 3c ce a3 27 2c d7 1b 5d 90 f3 
GATT-TX:  30 27 
Attempting to write /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
Characteristic property changed /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000d
GATT-RX: 03 05 eb 68 f7 99 be 18 ef 71 6e 51 10 f6 f5 05 
GATT-RX: d2 40 
Got provisioning data (17 bytes)
05 eb 68 f7 99 be 18 ef 71 6e 51 10 f6 f5 05 d2 
40 
GATT-TX:  03 06 af 78 37 46 88 64 92 8f f1 f4 9c c1 18 95 
GATT-TX:  a7 8d 
Attempting to write /org/bluez/hci0/dev_EA_E8_05_9B_16_1D/service000a/char000b
[Zephyr]#

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

Now what to do next ??
I've repeat this procedure on all three board.

How to control LEDs on these board using meshctl or any android APP ??

Thank You!!



On Thu, Nov 16, 2017 at 10:10 AM, Vikrant More <vikrant8051@...> wrote:
Now I'm able to run "discover-unprovisioned on" this command & o/p is

set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
SetDiscoveryFilter success
Discovery started
Adapter property changed 
[CHG] Controller F0:03:8C:B7:5A:18 Discovering: ye


But "provision dddd0000000000000000000000000000" is still giving me this o/p-

Device with UUID dddd0000000000000000000000000000 not found.
Stale services? Remove device and re-discover

I'm able to discover & connect nRF52840-PDK board via nRF connect android app.


On Wed, Nov 15, 2017 at 10:01 PM, Steve Brown <sbrown@...> wrote:
More.

If I run the old bluetoothd, I get

[NEW] Controller B8:27:EB:06:2E:57 raspberrypi [default]
[meshctl]# discover-unprovisioned on
set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
SetDiscoveryFilter failed: org.bluez.Error.InvalidArguments
Discovery started
Adapter property changed
[CHG] Controller B8:27:EB:06:2E:57 Discovering: yes

The same as you.

I'm pretty sure that's your problem.

Steve


On Wed, 2017-11-15 at 21:17 +0530, Vikrant More wrote:
>
> [meshctl]# discover-unprovisioned on
> set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
> SetDiscoveryFilter failed: org.bluez.Error.InvalidArguments
> Discovery started
> Adapter property changed
> [CHG] Controller F0:03:8C:B7:5A:18 Discovering: yes
>
> I built BlueZ 5.47 as per your style but I am getting same error
> which is mentioned above.
>
> On Nov 15, 2017 5:47 PM, "Steve Brown" <sbrown@...> wrote:
> > I don't recognize that repository. The one I'm using is
> >
> > https://git.kernel.org/pub/scm/bluetooth/bluez.git
> >
> > The json files are in that repository.
> >
> > I run ./bootstrap-configure, then make and sudo make install.
> >
> > You might want to remove your distribution's bluez from your system
> > so
> > there's no confusion over version.
> >
> > Lastly, are you sure that the bluetooth hardware on your computer
> > does
> > ble? If in doubt, try
> > sudo btmgmt info
> >
> > Steve
> >
> > On Wed, 2017-11-15 at 17:12 +0530, Vikrant More wrote:
> > > could you please help how to build https://github.com/hadess/blue
> > z ??
> > >
> > > since here I am not getting configure file to execute -->
> > > ./configure --prefix=/usr  --sysconfdir=/etc  --
> > localstatedir=/var
> > > --enable-library  --disable-systemd  && make
> > >
> > > On Wed, Nov 15, 2017 at 4:52 PM, Steve Brown <sbrown@...
> > >
> > > wrote:
> > > > It looks like you have some kind of problem on the bluez end.
> > > >
> > > > I get the following on the same board.
> > > >
> > > > [meshctl]# discover-unprovisioned on
> > > > set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
> > > > SetDiscoveryFilter success
> > > > Discovery started
> > > > Adapter property changed
> > > > [CHG] Controller B8:27:EB:06:2E:57 Discovering: yes
> > > >                 Mesh Provisioning Service (00001827-0000-1000-
> > 8000-
> > > > 00805f9b34fb)
> > > >                         Device UUID:
> > > > dddd0000000000000000000000000000
> > > >                         OOB: 0000
> > > >
> > > >
> > > > Are you sure you have a 5.47 bluetoothd running?
> > > >
> > > > Steve
> > > >
> > > >
> > > > On Wed, 2017-11-15 at 16:29 +0530, Vikrant More wrote:
> > > > > Thank very much !!
> > > > >
> > > > > I used your suggested commands. And I got following response
> > -
> > > > >
> > > > > [meshctl]# discover-unprovisioned on
> > > > > set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
> > > > > SetDiscoveryFilter failed: org.bluez.Error.InvalidArguments
> > > > > Discovery started
> > > > > Adapter property changed
> > > > > [CHG] Controller F0:03:8C:B7:5A:18 Discovering: yes
> > > > >
> > > > >
> > > > >
> > > > > meshctl]# provision dddd0000000000000000000000000000
> > > > > Device with UUID dddd0000000000000000000000000000 not found.
> > > > > Stale services? Remove device and re-discover
> > > > >
> > > > >
> > > > > On Wed, Nov 15, 2017 at 2:32 PM, Steve Brown <sbrown@cortland
> > .com
> > > > >
> > > > > wrote:
> > > > > > Hi Vikrant,
> > > > > >
> > > > > > On Wed, 2017-11-15 at 13:58 +0530, Vikrant More wrote:
> > > > > > > Hello,
> > > > > > > I to want build Zephyr based lighting system & for
> > testing I
> > > > have
> > > > > > 3
> > > > > > > nRF52840-PDK boards.
> > > > > > >
> > > > > > > I've flashed  zephyr/samples/bluetooth/mesh firmware on
> > all
> > > > three
> > > > > > > board.
> > > > > > > They are advertising themselves as any other GATT
> > peripheral
> > > > > > devices.
> > > > > > >
> > > > > > > As per my understanding they are in unprovisioned state.
> > > > > > >
> > > > > > > Using "NRF connect" Android app I can send data to
> > service
> > > > (Mesh
> > > > > > > Provisioning Service) running on it.
> > > > > > >
> > > > > > > I think this service is for provisioning purpose. Am I
> > right
> > > > ?
> > > > > > >
> > > > > > > How to do provisioning using meshctl utility (BlueZ 5.47)
> > ?
> > > > > > >
> > > > > > > When I execute meshctl on my ubuntu laptop it gives me
> > > > following
> > > > > > > error -
> > > > > > >
> > > > > > >        Local config directory not provided.
> > > > > > >    Failed to parse local node configuration file
> > > > local_node.json
> > > > > > >
> > > > > > >
> > > > > > I assume you built the bluez 5.47 from source.
> > > > > >
> > > > > > The json files live in bluez/mesh. You either have to run
> > > > meshctl
> > > > > > in
> > > > > > that directory or point to it with the "-c" option.
> > > > > >
> > > > > > Once in meshctl, the commands:
> > > > > > discover-unprovisioned on
> > > > > > provision <Device UUID>
> > > > > >
> > > > > > should get you going.
> > > > > >
> > > > > > In the mesh sample the UUID is hardwired to
> > > > > > "dddd0000000000000000000000000000"
> > > > > >
> > > > > > Steve
> > > > > >
> > > > >
> > > > >
> > >
> > >



No thread to run before main

Timothy <tymoteusz.kielan@...>
 

Hi,

I have recently encountered weird issue.
This probably happen after rebase to zephyr 1.9.99


Before entering main() kernel stopped stating to thread to run:

0x0800c9e6 in _get_ready_q_head () at ../zephyr/kernel/sched.c:51
51 __ASSERT(!sys_dlist_is_empty(list),
(gdb) bt
#0  0x0800c9e6 in _get_ready_q_head () at ../zephyr/kernel/sched.c:51
#1  0x0800ca8a in _remove_thread_from_ready_q (thread=0x20000080 <k_sys_work_q+16>) at ../zephyr/kernel/sched.c:111
#2  0x0800ccea in _pend_current_thread (wait_q=wait_q@entry=0x20001d24 <sys_work_q_stack+932>, timeout=timeout@entry=-1) at ../zephyr/kernel/sched.c:220
#3  0x0800e814 in k_poll (events=events@entry=0x20001d5c <sys_work_q_stack+988>, num_events=num_events@entry=1, timeout=timeout@entry=-1) at ../zephyr/kernel/poll.c:249
#4  0x0800c7e2 in k_queue_poll (queue=0x20000070 <k_sys_work_q>, timeout=-1) at ../zephyr/kernel/queue.c:209
#5  0x0800c93a in k_queue_get (queue=queue@entry=0x20000070 <k_sys_work_q>, timeout=timeout@entry=-1) at ../zephyr/kernel/queue.c:250
#6  0x0800dd5c in work_q_main (work_q_ptr=0x20000070 <k_sys_work_q>, p2=<optimized out>, p3=<optimized out>) at ../zephyr/kernel/work_q.c:29
#7  0x0800d864 in _thread_entry (entry=0x800dd45 <work_q_main>, p1=<optimized out>, p2=<optimized out>, p3=<optimized out>) at ../zephyr/kernel/thread.c:194
#8  0xaaaaaaaa in ?? ()


This happen while executing

_sys_device_do_config_level(_SYS_INIT_LEVEL_POST_KERNEL);

before

_sys_device_do_config_level(_SYS_INIT_LEVEL_APPLICATION);

so app was not supposed to be started yet.

app is not the first thread to run?

thanks, Tim

--
Tim Kielan
Registered Linux User #239184

vim [noun] - lively or energetic spirit; enthusiasm; vitality


Re: Flash drivers compatibility attitude

Marti Bolivar
 

Hi Jonas,

I'm glad we're agreed on the meaning. I've submitted a pull request which defines "page" and removes uses of "sector".

Could you please review it to see if it resolves the ambiguity?


Thanks,
Marti

On Wed, Nov 15, 2017 at 1:11 PM, Jonas Pfaff <jonas.pfaff@...> wrote:
Hi Marti,

Thank you for the clarification. It surely is the logical interpretation from an "external program" (like MCUboot) point of view.
But, especially after a few hours of data sheet reading, the words "page" and "sector" can have different meanings. IMHO it would be safer to add a short definition of the word "page" to the description in order to exclude any further misunderstanding.

Thanks,
Jonas

On 15. 11. 17 17:49, Marti Bolivar wrote:
Hi Jonas,

"Page" meaning "smallest erasable area" is the sense I have, and the sense in which MCUBoot interprets the word.

If anybody has a different interpretation please speak up, as I'd like to discuss  so we can make sure API users are aligned (are on the same page? ba-dum-ch).

Thanks,
Marti

On Wed, Nov 15, 2017 at 10:18 AM, Jonas Pfaff <jonas.pfaff@... <mailto:jonas.pfaff@...>> wrote:

    Hi,

    I am working on the flash driver for the Atmel SAM E70 MCU and it is
    not yet clear to me what the API expects in the flash_pages_layout
    structure. In the description the words sectors and pages seem to be
    used interchangeably. On the other hand they have very distinct
    meaning in the MCU documentation.

    Additionally in case of the Atmel MCU the flash can be erased by
    sector or in 16 (Atmel)-pages steps. (1 sector = 256 pages, with a
    few exceptions). So the smallest erasable part equals to 16 Atmel-pages.
    Depending on the interpretation of the API I therefore have 3
    different flash layouts:
    1) uniform layout with API page size = Atmel page size
    2) uniform layout with API page size = Atmel page size * 16
    3) nonuniform layout with API page sizes = Atmel sectors

     From the previous discussion here the "API page size" seems to be
    thought as the smallest erasable quantity of the flash (case 2), ist
    that the correct interpretation?


    Jonas

    On 11. 07. 17 16:35, david.brown at linaro.org <http://linaro.org>
    (David Brown) wrote:

        On Tue, Jul 11, 2017 at 01:05:56PM +0000, Puzdrowski, Andrzej wrote:

            I think it's more suitable to get pages size as it is
            quantum of the
            erase. Instead of get map in run-length format I propose to
            query by
            address like here:
            https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NORDIC/TARGET_NRF5/flash_api.c#L93
            <https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NORDIC/TARGET_NRF5/flash_api.c#L93>
            It will be very easy possible to produce such a map using
            similar API
            - but usually map is easy to describe in a "get" algorithm.


        This does make sense.  Having the get API makes the code very simple
        for the majority of devices where the sector sizes are uniform in
        size.  The only thing is that if code needs to know if the
        sectors are
        uniform in size, it would have to scan through the device to learn
        this.  I can see this as a common optimization, or in the case of a
        filesystem, even a requirement.

        For mcuboot, the address query would be fine.

        David

    _______________________________________________
    Zephyr-devel mailing list
    Zephyr-devel@...ct.org
    <mailto:Zephyr-devel@...hyrproject.org>
    https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
    <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>




Re: Flash drivers compatibility attitude

Jonas Pfaff
 

Hi Marti,

Thank you for the clarification. It surely is the logical interpretation from an "external program" (like MCUboot) point of view.
But, especially after a few hours of data sheet reading, the words "page" and "sector" can have different meanings. IMHO it would be safer to add a short definition of the word "page" to the description in order to exclude any further misunderstanding.

Thanks,
Jonas

On 15. 11. 17 17:49, Marti Bolivar wrote:
Hi Jonas,
"Page" meaning "smallest erasable area" is the sense I have, and the sense in which MCUBoot interprets the word.
If anybody has a different interpretation please speak up, as I'd like to discuss  so we can make sure API users are aligned (are on the same page? ba-dum-ch).
Thanks,
Marti
On Wed, Nov 15, 2017 at 10:18 AM, Jonas Pfaff <jonas.pfaff@gmail.com <mailto:jonas.pfaff@gmail.com>> wrote:
Hi,
I am working on the flash driver for the Atmel SAM E70 MCU and it is
not yet clear to me what the API expects in the flash_pages_layout
structure. In the description the words sectors and pages seem to be
used interchangeably. On the other hand they have very distinct
meaning in the MCU documentation.
Additionally in case of the Atmel MCU the flash can be erased by
sector or in 16 (Atmel)-pages steps. (1 sector = 256 pages, with a
few exceptions). So the smallest erasable part equals to 16 Atmel-pages.
Depending on the interpretation of the API I therefore have 3
different flash layouts:
1) uniform layout with API page size = Atmel page size
2) uniform layout with API page size = Atmel page size * 16
3) nonuniform layout with API page sizes = Atmel sectors
From the previous discussion here the "API page size" seems to be
thought as the smallest erasable quantity of the flash (case 2), ist
that the correct interpretation?
Jonas
On 11. 07. 17 16:35, david.brown at linaro.org <http://linaro.org>
(David Brown) wrote:
On Tue, Jul 11, 2017 at 01:05:56PM +0000, Puzdrowski, Andrzej wrote:
I think it's more suitable to get pages size as it is
quantum of the
erase. Instead of get map in run-length format I propose to
query by
address like here:
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NORDIC/TARGET_NRF5/flash_api.c#L93
<https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NORDIC/TARGET_NRF5/flash_api.c#L93>
It will be very easy possible to produce such a map using
similar API
- but usually map is easy to describe in a "get" algorithm.
This does make sense.  Having the get API makes the code very simple
for the majority of devices where the sector sizes are uniform in
size.  The only thing is that if code needs to know if the
sectors are
uniform in size, it would have to scan through the device to learn
this.  I can see this as a common optimization, or in the case of a
filesystem, even a requirement.
For mcuboot, the address query would be fine.
David
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
<mailto:Zephyr-devel@lists.zephyrproject.org>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
<https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>


Re: Flash drivers compatibility attitude

Marti Bolivar
 

Hi Jonas,

"Page" meaning "smallest erasable area" is the sense I have, and the sense in which MCUBoot interprets the word.

If anybody has a different interpretation please speak up, as I'd like to discuss  so we can make sure API users are aligned (are on the same page? ba-dum-ch).

Thanks,
Marti

On Wed, Nov 15, 2017 at 10:18 AM, Jonas Pfaff <jonas.pfaff@...> wrote:
Hi,

I am working on the flash driver for the Atmel SAM E70 MCU and it is not yet clear to me what the API expects in the flash_pages_layout structure. In the description the words sectors and pages seem to be used interchangeably. On the other hand they have very distinct meaning in the MCU documentation.

Additionally in case of the Atmel MCU the flash can be erased by sector or in 16 (Atmel)-pages steps. (1 sector = 256 pages, with a few exceptions). So the smallest erasable part equals to 16 Atmel-pages.
Depending on the interpretation of the API I therefore have 3 different flash layouts:
1) uniform layout with API page size = Atmel page size
2) uniform layout with API page size = Atmel page size * 16
3) nonuniform layout with API page sizes = Atmel sectors

From the previous discussion here the "API page size" seems to be thought as the smallest erasable quantity of the flash (case 2), ist that the correct interpretation?


Jonas

On 11. 07. 17 16:35, david.brown at linaro.org (David Brown) wrote:
On Tue, Jul 11, 2017 at 01:05:56PM +0000, Puzdrowski, Andrzej wrote:

I think it's more suitable to get pages size as it is quantum of the
erase. Instead of get map in run-length format I propose to query by
address like here:
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NORDIC/TARGET_NRF5/flash_api.c#L93
It will be very easy possible to produce such a map using similar API
- but usually map is easy to describe in a "get" algorithm.

This does make sense.  Having the get API makes the code very simple
for the majority of devices where the sector sizes are uniform in
size.  The only thing is that if code needs to know if the sectors are
uniform in size, it would have to scan through the device to learn
this.  I can see this as a common optimization, or in the case of a
filesystem, even a requirement.

For mcuboot, the address query would be fine.

David

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


Flash drivers compatibility attitude

Jonas Pfaff
 

Hi,

I am working on the flash driver for the Atmel SAM E70 MCU and it is not yet clear to me what the API expects in the flash_pages_layout structure. In the description the words sectors and pages seem to be used interchangeably. On the other hand they have very distinct meaning in the MCU documentation.

Additionally in case of the Atmel MCU the flash can be erased by sector or in 16 (Atmel)-pages steps. (1 sector = 256 pages, with a few exceptions). So the smallest erasable part equals to 16 Atmel-pages.
Depending on the interpretation of the API I therefore have 3 different flash layouts:
1) uniform layout with API page size = Atmel page size
2) uniform layout with API page size = Atmel page size * 16
3) nonuniform layout with API page sizes = Atmel sectors

From the previous discussion here the "API page size" seems to be thought as the smallest erasable quantity of the flash (case 2), ist that the correct interpretation?


Jonas

On 11. 07. 17 16:35, david.brown at linaro.org (David Brown) wrote:
On Tue, Jul 11, 2017 at 01:05:56PM +0000, Puzdrowski, Andrzej wrote:

I think it's more suitable to get pages size as it is quantum of the
erase. Instead of get map in run-length format I propose to query by
address like here:
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NORDIC/TARGET_NRF5/flash_api.c#L93
It will be very easy possible to produce such a map using similar API
- but usually map is easy to describe in a "get" algorithm.
This does make sense. Having the get API makes the code very simple
for the majority of devices where the sector sizes are uniform in
size. The only thing is that if code needs to know if the sectors are
uniform in size, it would have to scan through the device to learn
this. I can see this as a common optimization, or in the case of a
filesystem, even a requirement.
For mcuboot, the address query would be fine.
David


Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Vikrant More <vikrant8051@...>
 

Thank very much !!

I used your suggested commands. And I got following response - 

[meshctl]# discover-unprovisioned on
set_scan_filter_uuids 00001827-0000-1000-8000-00805f9b34fb
SetDiscoveryFilter failed: org.bluez.Error.InvalidArguments
Discovery started
Adapter property changed 
[CHG] Controller F0:03:8C:B7:5A:18 Discovering: yes



meshctl]# provision dddd0000000000000000000000000000
Device with UUID dddd0000000000000000000000000000 not found.
Stale services? Remove device and re-discover


On Wed, Nov 15, 2017 at 2:32 PM, Steve Brown <sbrown@...> wrote:
Hi Vikrant,

On Wed, 2017-11-15 at 13:58 +0530, Vikrant More wrote:
> Hello,
> I to want build Zephyr based lighting system & for testing I have 3
> nRF52840-PDK boards.
>
> I've flashed  zephyr/samples/bluetooth/mesh firmware on all three
> board.
> They are advertising themselves as any other GATT peripheral devices.
>
> As per my understanding they are in unprovisioned state.
>
> Using "NRF connect" Android app I can send data to service (Mesh
> Provisioning Service) running on it.
>
> I think this service is for provisioning purpose. Am I right ?
>
> How to do provisioning using meshctl utility (BlueZ 5.47) ?
>
> When I execute meshctl on my ubuntu laptop it gives me following
> error -
>
>        Local config directory not provided.
>    Failed to parse local node configuration file local_node.json
>
>
I assume you built the bluez 5.47 from source.

The json files live in bluez/mesh. You either have to run meshctl in
that directory or point to it with the "-c" option.

Once in meshctl, the commands:
discover-unprovisioned on
provision <Device UUID>

should get you going.

In the mesh sample the UUID is hardwired to
"dddd0000000000000000000000000000"

Steve



Re: Dependency not listet in documentation: gperf

Carles Cufi
 

Hi Daniel,

 

It’s listed in the Getting Started guides as one of the packages you need to install on all 3 OSs (Linux, macOS, Windows/MSYS2).

http://docs.zephyrproject.org/getting_started/installation_linux.html

http://docs.zephyrproject.org/getting_started/installation_mac.html

http://docs.zephyrproject.org/getting_started/installation_win.html

 

Regards,

 

Carles

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Wagenknecht, Daniel
Sent: 15 November 2017 11:41
To: zephyr-devel@...
Subject: [Zephyr-devel] Dependency not listet in documentation: gperf

 

Hi there,

 

I’ve not used zephyr for a few weeks and in the meantime Zephyr-SDK 0.9.2 was released and the CMake migration happened.

 

After pulling the latest zephyr/arm branch, installing cmake (3.9.6) and the SDK 0.9.2 I get a build error:

 

                CMake Error at /home/dw_dev/0_zephyr/cmake/host-tools.cmake:32 (message):

               Unable to find gperf

 

After installing gperf it compiles fine, but I can’t find gperf mentioned as a requirement anywhere in the zephyr documentation. Is the documentation behind on this, or is it just this little detail, that was missed?

 

Regards

Daniel Wagenknecht


Re: Dependency not listet in documentation: gperf

Timothy <tymoteusz.kielan@...>
 

Hi Dan,

I can find it at


under "Installing Requirements and Dependencies" :

Tim

-- 
Tim Kielan
Registered Linux User #239184 

vim [noun] - lively or energetic spirit; enthusiasm; vitality

On 15 November 2017 at 11:41, Wagenknecht, Daniel <Daniel.Wagenknecht@...> wrote:

Hi there,

 

I’ve not used zephyr for a few weeks and in the meantime Zephyr-SDK 0.9.2 was released and the CMake migration happened.

 

After pulling the latest zephyr/arm branch, installing cmake (3.9.6) and the SDK 0.9.2 I get a build error:

 

                CMake Error at /home/dw_dev/0_zephyr/cmake/host-tools.cmake:32 (message):

               Unable to find gperf

 

After installing gperf it compiles fine, but I can’t find gperf mentioned as a requirement anywhere in the zephyr documentation. Is the documentation behind on this, or is it just this little detail, that was missed?

 

Regards

Daniel Wagenknecht


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


Dependency not listet in documentation: gperf

Daniel Wagenknecht
 

Hi there,

 

I’ve not used zephyr for a few weeks and in the meantime Zephyr-SDK 0.9.2 was released and the CMake migration happened.

 

After pulling the latest zephyr/arm branch, installing cmake (3.9.6) and the SDK 0.9.2 I get a build error:

 

                CMake Error at /home/dw_dev/0_zephyr/cmake/host-tools.cmake:32 (message):

               Unable to find gperf

 

After installing gperf it compiles fine, but I can’t find gperf mentioned as a requirement anywhere in the zephyr documentation. Is the documentation behind on this, or is it just this little detail, that was missed?

 

Regards

Daniel Wagenknecht


Re: Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Steve Brown
 

Hi Vikrant,

On Wed, 2017-11-15 at 13:58 +0530, Vikrant More wrote:
Hello,
I to want build Zephyr based lighting system & for testing I have 3
nRF52840-PDK boards.

I've flashed zephyr/samples/bluetooth/mesh firmware on all three
board.
They are advertising themselves as any other GATT peripheral devices.

As per my understanding they are in unprovisioned state.

Using "NRF connect" Android app I can send data to service (Mesh
Provisioning Service) running on it.

I think this service is for provisioning purpose. Am I right ?

How to do provisioning using meshctl utility (BlueZ 5.47) ?

When I execute meshctl on my ubuntu laptop it gives me following
error -

Local config directory not provided.
Failed to parse local node configuration file local_node.json

I assume you built the bluez 5.47 from source.

The json files live in bluez/mesh. You either have to run meshctl in
that directory or point to it with the "-c" option.

Once in meshctl, the commands:
discover-unprovisioned on
provision <Device UUID>

should get you going.

In the mesh sample the UUID is hardwired to
"dddd0000000000000000000000000000"

Steve


Re: I2C is not working for STM-based board

Sebastian Boe
 

PR: https://github.com/zephyrproject-rtos/zephyr/pull/4984

github.com
Fix typo in build scripts for STM's I2C driver. The typo was introduced in the cmake migration. Discovered by Dmitry: https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-November/008383.htm...


From: zephyr-devel-bounces@... <zephyr-devel-bounces@...> on behalf of Yannis Damigos <giannis.damigos@...>
Sent: Wednesday, 15 November 2017 7:58:23 AM
To: Dmitry Shmidt
Cc: zephyr-devel
Subject: Re: [Zephyr-devel] I2C is not working for STM-based board
 
Hi Dmitry,

Thanks for catching this. It is a typo.
Could you create a PR on github to fix it?

Yannis

On Tue, Nov 14, 2017 at 9:21 PM, Dmitry Shmidt via Zephyr-devel
<zephyr-devel@...> wrote:
> Hello,
>
> Change for cmake build:
>
> commit 12f8f7616567f224b920512b6f81a65421e30bae
> Author: Sebastian Bøe <sebastian.boe@...>
> Date:   Fri Oct 27 15:43:34 2017 +0200
>     Introduce cmake-based rewrite of KBuild
>
> set CONFIG_I2C_STM32_V1x instead of CONFIG_I2C_STM32_V1
>
> Was it intentional or should we use old value like this:
>
> diff --git a/drivers/i2c/CMakeLists.txt b/drivers/i2c/CMakeLists.txt
> index 3a544930f..8f8fb67d1 100644
> --- a/drivers/i2c/CMakeLists.txt
> +++ b/drivers/i2c/CMakeLists.txt
> @@ -10,7 +10,7 @@ zephyr_sources_ifdef(CONFIG_I2C_QMSI_SS
>  i2c_qmsi_ss.c)
>  zephyr_sources_ifdef(CONFIG_I2C_SAM_TWI     i2c_sam_twi.c)
>  zephyr_sources_ifdef(CONFIG_I2C_SBCON          i2c_sbcon.c)
>
> -zephyr_sources_ifdef(CONFIG_I2C_STM32_V1x
> +zephyr_sources_ifdef(CONFIG_I2C_STM32_V1
>         i2c_ll_stm32_v1.c
>         i2c_ll_stm32.c
>         )
>
> Thanks,
>
> Dmitry
> _______________________________________________
> Zephyr-devel mailing list
> Zephyr-devel@...
> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Zephyr Based Bluetooth Mesh implementation on nRF52840-PDK boards

Vikrant More <vikrant8051@...>
 

Hello,
I to want build Zephyr based lighting system & for testing I have 3 nRF52840-PDK boards.

I've flashed  zephyr/samples/bluetooth/mesh firmware on all three board.
They are advertising themselves as any other GATT peripheral devices.

As per my understanding they are in unprovisioned state. 

Using "NRF connect" Android app I can send data to service (Mesh Provisioning Service) running on it.

I think this service is for provisioning purpose. Am I right ?

How to do provisioning using meshctl utility (BlueZ 5.47) ?

When I execute meshctl on my ubuntu laptop it gives me following error - 

       Local config directory not provided.
   Failed to parse local node configuration file local_node.json

From where I can get this local_node.json which is compatible for nRF52840-PDK ?

I've also posted same Question of Nordic Semi. devzone forum:


Re: Zephyr flash won't work without usb connection

Andrei
 

Hi,

tinytile has only one USB connector. After connecting to PC first couple
of seconds it waits in DFU mode after that it loads Zephyr and in the
default configuration enables USB UART console, see:
boards/x86/tinytile/tinytile_defconfig. So only one USB connector is
enough and it should be fine to connect to USB power. Remember to reset
and flash quickly while it is in DFU mode.

Best regards
Andrei Emeltchenko

On Wed, Nov 15, 2017 at 01:52:45AM +0000, Rosen, Michael R wrote:
Jie,

 

If you flashed your Zephyr application over USB, it should now be in the
device’s flash memory and should be loaded and run on every reboot. If you
are not seeing the application load when you run the device off external
power, that might be a very different issue. But you will not be able to
flash it once it has been disconnected.

 

Mike

 

From: Jie Zhou [mailto:zhoujie@hawaii.edu]
Sent: Tuesday, November 14, 2017 5:49 PM
To: Rosen, Michael R <michael.r.rosen@intel.com>;
zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Zephyr flash won't work without usb connection

 

Hi Mike,

I'll investigate on the vin/gnd battery. I also have the flyswatter, but I
remember having trouble with flashing with it, so I sticked with the FTDI
but will check that out too. Eventually, I would want the board to run the
application on power up, so it would require no connection with my
computer at all. Zephyr, being a IoT OS, must have this capability. Let me
know if anyone else knows how to by pass the need of usb.

Thanks,

Jie 

 

On Tue, Nov 14, 2017 at 1:27 PM, Rosen, Michael R
<[1]michael.r.rosen@intel.com> wrote:

Jie,

 

Curie boards generally flash in one of two ways: over JTAG or over USB.
In typical uses, they actually flash over the Curie USB interface (using
the USB DFU protocol; via dfu-util). That’s why you need USB connected
in order to flash the device. Not sure how easy it is to do JTAG
flashing on tinyTILE though, it requires a flyswatter2 or similar device
for Arduino 101.

 

Not 100% sure of this, but you should be able to connect a battery to
the VIN/GND holes of the tinyTILE and leave the USB open for flashing.
If you intend to use a USB Battery, then you are somewhat stuck; though
there might be ways to do OTA updates using the BLE Radio SoC if you are
interested in investigating that…

 

Also note that on boot, there might be a UART flashing mechanism on
boot, but I really haven’t done anything with it before and its really
an afterthought to the main USB or JTAG mechanisms. It uses the XModem
protocol and I think you will likely have to make a script specifically
for handling it. But if your needs really merit it, it might be worth
the effort. This feature may or may not be there on the default tinyTILE
bootloader.

 

Code for the bootloader(s) that run on tinyTILE (or at least a close
version to the one on tinyTILE) can be found here:
[2]https://github.com/CurieBSP/bootloader

 

Mike

 

 

From: [3]zephyr-devel-bounces@lists.zephyrproject.org
[mailto:[4]zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of
Jie Zhou
Sent: Tuesday, November 14, 2017 3:09 PM
To: [5]zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Zephyr flash won't work without usb connection

 

Hi all,

I'm flashing my tinyTILE using DFU over FTDI cable. My computer, that
has the zephyr applications, is connected to tinyTILE via a FTDI cable
as TX & RX and a usb cable as power to the tinyTILE. It flashes fine;
however, when I power the board externally so that my computer and
tinyTILE is only connected with the FTDI cable, the application will not
flash. I was always under the impression that the usb cable only
functions as a power source, but it seems to be more than that. Only
when the board is connected both by the FTDI and the USB cable will the
zephyr application flash to my board. This means I won't be able to
flash my zephyr application using battery power which defeats the
purpose an IoT OS. I've tried the same with the arduino 101 board and it
still does the same thing (wouldn't flash). I must be missing something.
Wondering if anyone knows what I'm doing wrong. 

Thanks,

Jie  

 

References

Visible links
1. mailto:michael.r.rosen@intel.com
2. https://github.com/CurieBSP/bootloader
3. mailto:zephyr-devel-bounces@lists.zephyrproject.org
4. mailto:zephyr-devel-bounces@lists.zephyrproject.org
5. mailto:zephyr-devel@lists.zephyrproject.org
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Bluetooth Mesh

Vikrant More <vikrant8051@...>
 

I want build Zephyr based lighting system & for testing I have 3 nRF52840-PDK boards.

I've flashed  zephyr/samples/bluetooth/mesh firmware on all three board.
They are advertising themselves as any other GATT peripheral devices.

As per my understanding they are in unprovisioned state. 

Using "NRF connect" Android app I can send data to service (Mesh Provisioning Service) running on it.

I think this service is for provisioning purpose. Am I right ?

How to do provisioning using meshctl utility (BlueZ 5.47) ?

When I execute meshctl on my ubuntu laptop it gives me following error - 

       Local config directory not provided.
   Failed to parse local node configuration file local_node.json

From where I can get this local_node.json which is compatible for nRF52840-PDK ?

I've also posted same Question of Nordic Semi. devzone forum:


Re: I2C is not working for STM-based board

Yannis Damigos
 

Hi Dmitry,

Thanks for catching this. It is a typo.
Could you create a PR on github to fix it?

Yannis

On Tue, Nov 14, 2017 at 9:21 PM, Dmitry Shmidt via Zephyr-devel
<zephyr-devel@lists.zephyrproject.org> wrote:
Hello,

Change for cmake build:

commit 12f8f7616567f224b920512b6f81a65421e30bae
Author: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Date: Fri Oct 27 15:43:34 2017 +0200
Introduce cmake-based rewrite of KBuild

set CONFIG_I2C_STM32_V1x instead of CONFIG_I2C_STM32_V1

Was it intentional or should we use old value like this:

diff --git a/drivers/i2c/CMakeLists.txt b/drivers/i2c/CMakeLists.txt
index 3a544930f..8f8fb67d1 100644
--- a/drivers/i2c/CMakeLists.txt
+++ b/drivers/i2c/CMakeLists.txt
@@ -10,7 +10,7 @@ zephyr_sources_ifdef(CONFIG_I2C_QMSI_SS
i2c_qmsi_ss.c)
zephyr_sources_ifdef(CONFIG_I2C_SAM_TWI i2c_sam_twi.c)
zephyr_sources_ifdef(CONFIG_I2C_SBCON i2c_sbcon.c)

-zephyr_sources_ifdef(CONFIG_I2C_STM32_V1x
+zephyr_sources_ifdef(CONFIG_I2C_STM32_V1
i2c_ll_stm32_v1.c
i2c_ll_stm32.c
)

Thanks,

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


Re: Zephyr flash won't work without usb connection

Michael Rosen
 

Jie,

 

If you flashed your Zephyr application over USB, it should now be in the device’s flash memory and should be loaded and run on every reboot. If you are not seeing the application load when you run the device off external power, that might be a very different issue. But you will not be able to flash it once it has been disconnected.

 

Mike

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Tuesday, November 14, 2017 5:49 PM
To: Rosen, Michael R <michael.r.rosen@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] Zephyr flash won't work without usb connection

 

Hi Mike,

I'll investigate on the vin/gnd battery. I also have the flyswatter, but I remember having trouble with flashing with it, so I sticked with the FTDI but will check that out too. Eventually, I would want the board to run the application on power up, so it would require no connection with my computer at all. Zephyr, being a IoT OS, must have this capability. Let me know if anyone else knows how to by pass the need of usb.

Thanks,

Jie 

 

On Tue, Nov 14, 2017 at 1:27 PM, Rosen, Michael R <michael.r.rosen@...> wrote:

Jie,

 

Curie boards generally flash in one of two ways: over JTAG or over USB. In typical uses, they actually flash over the Curie USB interface (using the USB DFU protocol; via dfu-util). That’s why you need USB connected in order to flash the device. Not sure how easy it is to do JTAG flashing on tinyTILE though, it requires a flyswatter2 or similar device for Arduino 101.

 

Not 100% sure of this, but you should be able to connect a battery to the VIN/GND holes of the tinyTILE and leave the USB open for flashing. If you intend to use a USB Battery, then you are somewhat stuck; though there might be ways to do OTA updates using the BLE Radio SoC if you are interested in investigating that…

 

Also note that on boot, there might be a UART flashing mechanism on boot, but I really haven’t done anything with it before and its really an afterthought to the main USB or JTAG mechanisms. It uses the XModem protocol and I think you will likely have to make a script specifically for handling it. But if your needs really merit it, it might be worth the effort. This feature may or may not be there on the default tinyTILE bootloader.

 

Code for the bootloader(s) that run on tinyTILE (or at least a close version to the one on tinyTILE) can be found here: https://github.com/CurieBSP/bootloader

 

Mike

 

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Jie Zhou
Sent: Tuesday, November 14, 2017 3:09 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] Zephyr flash won't work without usb connection

 

Hi all,

I'm flashing my tinyTILE using DFU over FTDI cable. My computer, that has the zephyr applications, is connected to tinyTILE via a FTDI cable as TX & RX and a usb cable as power to the tinyTILE. It flashes fine; however, when I power the board externally so that my computer and tinyTILE is only connected with the FTDI cable, the application will not flash. I was always under the impression that the usb cable only functions as a power source, but it seems to be more than that. Only when the board is connected both by the FTDI and the USB cable will the zephyr application flash to my board. This means I won't be able to flash my zephyr application using battery power which defeats the purpose an IoT OS. I've tried the same with the arduino 101 board and it still does the same thing (wouldn't flash). I must be missing something. Wondering if anyone knows what I'm doing wrong. 

Thanks,

Jie  

 

4461 - 4480 of 8109