Date   

Re: #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

Johan Hedberg
 

Hi Vikrant,

I understood what you meant. And those are the steps I followed. I used
Nordic's new iOS mesh app and used its "node reset" feature. Then I
reprovisioned and after that did a power-cycle. After that the node came
back up as provisioned.

Johan

On Wed, Jun 13, 2018, vikrant8051 wrote:
Hi Johan,

I've completely removed NVS from my local project.
Even after that facing same issue.

If you provision & configure -> reset the board -> then it work as
expected.

But I'm not talking about power reset...I'm talking about Provisioner
node-reset command.

For e.g.

provision & configured DEVICE using #meshctl --> send node-reset command
via #meshctl --> unprovision state --> provision & configure it again -->
now do power reset/ hardware reset -> Here device should be
in provisioned state but I always found it in Unprovisioned state.


Thank You !!

On Wed, Jun 13, 2018 at 7:01 PM, Johan Hedberg <johan.hedberg@intel.com>
wrote:

Hi Vikrant,

I just tried your exact steps with the mesh_shell app, and it works
correctly (i.e. after the power cycle the board comes back as
provisioned). I used the nRF51 USB dongle, fwiw. Is it possible that
your NVS usage is somehow messing with things?

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
Hi Johan,

It is with default #FCB.

On Wed, Jun 13, 2018 at 6:24 PM, Johan Hedberg <johan.hedberg@intel.com>
wrote:

Hi Vikrant,

Is this with NFFS or FCB? I remember testing this with FCB and it
worked
correctly.

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
Hi,

Yes, I confirmed my observation. And happening this every time.

I also tried it with #nRFMesh app. In that case too, if I do
(provision + configuration) -> ( node-reset ) -> (provision +
configuration) --> Reset/ Power down the board-> Device found in
unprovisioned state.

Thank You !!

On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@gmail.com>
wrote:

Hi,

If after complete or partial provisioning, execute *node-reset*
command
then in that case I have observe following things :

1) Node get reprovision
2) but after reboot, it boot as unprovisioned device.

Has anybody observe this ?

Thank You !!




Re: #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

vikrant8051 <vikrant8051@...>
 


Hi Johan,

I've completely removed NVS from my local project.
Even after that facing same issue.

If you provision & configure -> reset the board -> then it work as expected.

But I'm not talking about power reset...I'm talking about Provisioner node-reset command.

For e.g.

provision & configured DEVICE using #meshctl  --> send node-reset command via #meshctl  --> unprovision state  --> provision & configure it again --> now do power reset/ hardware reset -> Here device should be
in provisioned state but I always found it in Unprovisioned state.


Thank You !!

On Wed, Jun 13, 2018 at 7:01 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

I just tried your exact steps with the mesh_shell app, and it works
correctly (i.e. after the power cycle the board comes back as
provisioned). I used the nRF51 USB dongle, fwiw. Is it possible that
your NVS usage is somehow messing with things?

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
> Hi Johan,
>
> It is with default #FCB.
>
> On Wed, Jun 13, 2018 at 6:24 PM, Johan Hedberg <johan.hedberg@...>
> wrote:
>
> > Hi Vikrant,
> >
> > Is this with NFFS or FCB? I remember testing this with FCB and it worked
> > correctly.
> >
> > Johan
> >
> > On Wed, Jun 13, 2018, Vikrant More wrote:
> > > Hi,
> > >
> > > Yes, I confirmed my observation. And happening this every time.
> > >
> > > I also tried it with #nRFMesh app. In that case too, if I do
> > > (provision + configuration) -> ( node-reset ) -> (provision +
> > > configuration) --> Reset/ Power down the board-> Device found in
> > > unprovisioned state.
> > >
> > > Thank You !!
> > >
> > > On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@...>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > If after complete or partial provisioning, execute *node-reset* command
> > > > then in that case I have observe following things :
> > > >
> > > > 1) Node get reprovision
> > > > 2) but after reboot, it boot as unprovisioned device.
> > > >
> > > > Has anybody observe this ?
> > > >
> > > > Thank You !! > > > >
> > > >
> >


Re: #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

Johan Hedberg
 

Hi Vikrant,

I just tried your exact steps with the mesh_shell app, and it works
correctly (i.e. after the power cycle the board comes back as
provisioned). I used the nRF51 USB dongle, fwiw. Is it possible that
your NVS usage is somehow messing with things?

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
Hi Johan,

It is with default #FCB.

On Wed, Jun 13, 2018 at 6:24 PM, Johan Hedberg <johan.hedberg@intel.com>
wrote:

Hi Vikrant,

Is this with NFFS or FCB? I remember testing this with FCB and it worked
correctly.

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
Hi,

Yes, I confirmed my observation. And happening this every time.

I also tried it with #nRFMesh app. In that case too, if I do
(provision + configuration) -> ( node-reset ) -> (provision +
configuration) --> Reset/ Power down the board-> Device found in
unprovisioned state.

Thank You !!

On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@gmail.com>
wrote:

Hi,

If after complete or partial provisioning, execute *node-reset* command
then in that case I have observe following things :

1) Node get reprovision
2) but after reboot, it boot as unprovisioned device.

Has anybody observe this ?

Thank You !!



Re: I am not able to configure pins as an input pin using the Zephyr OS API #nrf52832 #input #gpio

Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
 

Hi Rajat,

I would suggest you take a look at samples/basic/button for inspiration of using the input pins and modify it to out to the LEDs.

Regards,
Vinayak

On 13 Jun 2018, at 14:50, Rajat Kalyan <rajatkalyan95@...> wrote:

Hi Everyone,

Pardon me if i write some illogical stuff. Complete beginner to this microcontroller. 

I started using nrf52832 with Zephyr OS . I was trying to configure the pin as a input pin and blink the LED on the input from the Switch pin.

But unfortunately, I am not able to do it.  I am not able to configure the Switch pin as a input pin.

 

Here is code that i was using




#include <zephyr.h>

#include <device.h>

#include <gpio.h>

#include <board.h>

 

#define SW3_PORT SW3_GPIO_NAME

 

#define SW3_PIN SW3_GPIO_PIN

 

#define LED_PORT    LED2_GPIO_PORT

#define LED0    17

 

int main(void)

 

{

 

uint32_t *data=0;

 

struct device *dev1;

dev1 = device_get_binding(LED_PORT);

gpio_pin_configure(dev1, LED0, GPIO_DIR_OUT);

 

struct device *dev;

dev = device_get_binding(SW3_PORT);

gpio_pin_configure(dev, SW3_PIN, GPIO_DIR_IN);

gpio_pin_write(dev, LED0, 1);

  while(1)

{

 

gpio_pin_read(dev,SW3_PIN,data);

 

  //k_sleep(200);

gpio_pin_write(dev1, LED0, *data);

/*

if(data!=0)

{

gpio_pin_write(dev, LED0, 0);

 

}

else

{

gpio_pin_write(dev, LED0, 1);

}

*/

 

}

 

 


Re: #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

vikrant8051 <vikrant8051@...>
 

Hi Johan,

It is with default #FCB.

On Wed, Jun 13, 2018 at 6:24 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

Is this with NFFS or FCB? I remember testing this with FCB and it worked
correctly.

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
> Hi,
>
> Yes, I confirmed my observation. And happening this every time.
>
> I also tried it with #nRFMesh app. In that case too, if I do
> (provision + configuration) -> ( node-reset ) -> (provision +
> configuration) --> Reset/ Power down the board-> Device found in
> unprovisioned state.
>
> Thank You !!
>
> On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@...> wrote:
>
> > Hi,
> >
> > If after complete or partial provisioning, execute *node-reset* command
> > then in that case I have observe following things :
> >
> > 1) Node get reprovision
> > 2) but after reboot, it boot as unprovisioned device.
> >
> > Has anybody observe this ?
> >
> > Thank You !! > >
> >


Re: #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

Johan Hedberg
 

Hi Vikrant,

Is this with NFFS or FCB? I remember testing this with FCB and it worked
correctly.

Johan

On Wed, Jun 13, 2018, Vikrant More wrote:
Hi,

Yes, I confirmed my observation. And happening this every time.

I also tried it with #nRFMesh app. In that case too, if I do
(provision + configuration) -> ( node-reset ) -> (provision +
configuration) --> Reset/ Power down the board-> Device found in
unprovisioned state.

Thank You !!

On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@gmail.com> wrote:

Hi,

If after complete or partial provisioning, execute *node-reset* command
then in that case I have observe following things :

1) Node get reprovision
2) but after reboot, it boot as unprovisioned device.

Has anybody observe this ?

Thank You !!



Re: #BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

vikrant8051 <vikrant8051@...>
 

Hi,

Yes, I confirmed my observation. And happening this every time.

I also tried it with #nRFMesh app. In that case too, if I do
(provision + configuration) -> ( node-reset ) -> (provision + configuration) --> Reset/ Power down the board-> Device found in
unprovisioned state.

Thank You !!

On Wed, Jun 13, 2018 at 4:32 PM, vikrant8051 <vikrant8051@...> wrote:
Hi,

If after complete or partial provisioning, execute node-reset command then in that case I have observe following things :

1) Node get reprovision
2) but after reboot, it boot as unprovisioned device.

Has anybody observe this ?

Thank You !!



k_sleep on mimxrt1050_evk board

marco.hoefle@...
 

Hello,
I got the job to evaluate zephyr on a mimxrt1050_evk board.
I followed the instructions and could successfully download the hello world sample project.
Next step was to enhance the project with a thread:

void thread_0(void *dummy1, void *dummy2, void *dummy3)
{
    int loops = 1;
    while(1) {
        printk("Loops: %d\n", loops++);
        k_sleep(1000);
    }

}

void start_thread(void)
{
    bool failed = false;

    /* create stack_guard_thread */
    k_thread_create(&thread, stack,
            K_THREAD_STACK_SIZEOF(stack),
            thread_0, (void *)0,
            (void *)failed, NULL, PRIORITY, 0, K_NO_WAIT);
}

The first kprintf is printed out:
SHELL>> ***** Booting Zephyr OS 1.12.0 *****
built: Jun 13 2018 13:30:16
Loops: 1

k_sleep() is never returned.
It seems the CPU is stuck here:
Program received signal SIGTRAP, Trace/breakpoint trap.
isr_tables_syms () at /home/marco/projects/misc/zephyr/arch/common/isr_tables.c:63
63    GEN_ABSOLUTE_SYM(__ISR_LIST_SIZEOF, sizeof(struct _isr_list));

Any hints for me?
Thanks
Marco



#BluetoothMesh: if Node reprovisioned then it not get stored on SoC flash

vikrant8051 <vikrant8051@...>
 

Hi,

If after complete or partial provisioning, execute node-reset command then in that case I have observe following things :

1) Node get reprovision
2) but after reboot, it boot as unprovisioned device.

Has anybody observe this ?

Thank You !!


I am not able to configure pins as an input pin using the Zephyr OS API #nrf52832 #input #gpio

Rajat Kalyan
 

Hi Everyone,

Pardon me if i write some illogical stuff. Complete beginner to this microcontroller. 

I started using nrf52832 with Zephyr OS . I was trying to configure the pin as a input pin and blink the LED on the input from the Switch pin.

But unfortunately, I am not able to do it.  I am not able to configure the Switch pin as a input pin.

 

Here is code that i was using




#include <zephyr.h>

#include <device.h>

#include <gpio.h>

#include <board.h>

 

#define SW3_PORT SW3_GPIO_NAME

 

#define SW3_PIN SW3_GPIO_PIN

 

#define LED_PORT    LED2_GPIO_PORT

#define LED0    17

 

int main(void)

 

{

 

uint32_t *data=0;

 

struct device *dev1;

dev1 = device_get_binding(LED_PORT);

gpio_pin_configure(dev1, LED0, GPIO_DIR_OUT);

 

struct device *dev;

dev = device_get_binding(SW3_PORT);

gpio_pin_configure(dev, SW3_PIN, GPIO_DIR_IN);

gpio_pin_write(dev, LED0, 1);

  while(1)

{

 

gpio_pin_read(dev,SW3_PIN,data);

 

  //k_sleep(200);

gpio_pin_write(dev1, LED0, *data);

/*

if(data!=0)

{

gpio_pin_write(dev, LED0, 0);

 

}

else

{

gpio_pin_write(dev, LED0, 1);

}

*/

 

}

 

 


ieee802154: csma-ca: random backoff factor looks wrong

Franco Saworski <franco.saworski@...>
 

The calculation for the random backoff factor looks wrong [1]:
u8_t bo_n = sys_rand32_get() & (2 << (be + 1));

This generates either a power-of-two number or zero for bo_n, because it only overlaps a single bit with the random number. This is very rare and results in the backoff time being zero most of the time, if I'm not completely mistaken.

The standard defines the value to be random between zero and 2^be-1. The implementation should be:
u8_t bo_n = sys_rand32_get() & ((1 << be) - 1);

Has anyone had experience with this? I noticed this going over the implementation.

Kind regards,
Franco

--

Embedded Engineer

blik GmbH
transparent real-time data

Leonrodstraße 68 | 80636 München
HRB: 233881 | Amtsgericht München
Geschäftsführer: Bastian Burger, Philip Eller, Victoria Hauzeneder

Information in this email - including any attachments - may be privileged, confidential and is intended exclusively for the addressee(s). If you are not the intended recipient, please notify the sender and delete all copies from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone.


Re: Zephyr development news, 11 June 2018

Marti Bolivar
 

Hi again,

On Mon, Jun 11, 2018 at 7:28 PM, Marti Bolivar <marti@...> wrote:
Hello and happy release day,

Please note that we've renamed the series to "Zephyr development news"
to avoid a name clash with another publication.

This is the 11 June 2018 newsletter tracking the latest Zephyr
development merged into the mainline tree on GitHub.

I forgot to mention that (as usual) an HTML version is also available:


Sorry about that.

Marti


Zephyr development news, 11 June 2018

Marti Bolivar
 

Hello and happy release day,

Please note that we've renamed the series to "Zephyr development news"
to avoid a name clash with another publication.

This is the 11 June 2018 newsletter tracking the latest Zephyr
development merged into the mainline tree on GitHub.

As usual, content is broken down as follows:

- Highlights
  - Important changes: ABI/API breaks and some features
  - New features: non-exhaustive descriptions of new features
  - Bug fixes: non-exhaustive list of fixed bugs
- Individual changes: a complete list of patches, sorted
  chronologically and categorized into areas, like:
  - Architectures
  - Kernel
  - Drivers
  - etc.

Highlights
==========

As announced previously on the mailing lists, Zephyr v1.12.0 has been
tagged and the v1.13 merge window is now open. Hurray!

This newsletter covers changes in the following inclusive range, which
closes out the v1.12 release candidate period:

- 6a138977 ("susbys: disk: Fix misleading menuconfig prompts"),
  merged 4 June 2018
- f58d9cab ("release: Update VERSION for 1.12.0 release"),
  merged 11 June 2018

Important Changes
-----------------

The areas most affected during this period, as might be expected, were
documentation and testing. There were also a fairly large number of
ARC architecture changes.

Features
--------

Continuous Integration:

Sanitycheck can now export tests in CSV format.

Bug Fixes
---------

Arches:

A variety of ARC fixes were merged. These fix overflows in the
privileged stack, IRQ offloading, the ADC and watchdog timer priority
levels, reset instability, and a couple of issues related to exception
handling.

A bug preventing i.MX RT SoCs from booting correctly was fixed as
well; this also has the nice benefit of eliminating a vast number of
Kconfig warnings emitted when building for other boards.

Bluetooth:

A fix for a Coverity bug related to corrupted flash storage of
persistent settings was merged, along with a fix to retransmit
interval handling in the Mesh implementation, and an invalid pointer
access after disconnect in the ATT code.

Build:

A fix to the kernel helpers for the GCC toolchain was merged which
resolves unaligned access issues on GCC >= 7.

Continuous Integration:

A sanitycheck bug leading to false positive test pass reporting was
fixed.

Documentation:

The final batch of documentation patches covered release notes, issues
in the Getting Started guide, initial documentation for the
experimental West meta-tool, updates to the security documentation,
and some watchdog API documentation.

Kernel:

Architecture-specific attempts to provide thread arguments using its
initial stack layout were replaced with common code, trading off extra
memory to fix broken and incomplete implementations in some
architectures.

Libraries:

A fix was merged for a readdir() buffer out of bounds access
discovered by Coverity.

Networking:

An LWM2M bug was fixed which fixes mandatory rate limiting on the
frequency of notifications for observed object instance attributes.
The LWM2M engine thread priority was also lowered, fixing a thread
starvation issue when running LWM2M concurrently with Bluetooth
(e.g. as part of a 6LoWPAN setup).

The IPv4 stack now correctly updates the time-to-live value based on
the received packet header; a similar fix was merged for IPv6 hop
limits.

Samples:

Some last-minute changes were merged to crypto and networking samples.

The crypto changes appear to have been merged because
samples/drivers/crypto is in fact being used as a test case in
addition to serving as sample code, so they perhaps could be
considered test fixes.

The networking changes were fixes for bugs discovered by Coverity.

Testing:

A variety of patches fixing up and tuning the test cases were merged
in the final days of v1.12 development.

Individual Changes
==================

Patches by area (76 patches total):

- Arches: 11
- Bluetooth: 3
- Boards: 1
- Build: 1
- Continuous Integration: 2
- Documentation: 22
- Firmware Update: 1
- Kernel: 2
- Libraries: 1
- Miscellaneous: 3
- Networking: 5
- Samples: 8
- Scripts: 1
- Storage: 2
- Testing: 13

Arches (11):

- b423ee5f nxp_imx: Move i.MX RT PLL selects to Kconfig.soc
- c5cb8e94 arch/arc: Set the right priority for WDT on quark_se
- 718597fe arch/arm: Fix THREAD_MONITOR entry struct
- 7f7718a0 arch: stm32: remove .hex binary build by default
- 5b6f8605 arch: arc: use a separate stack for exception handling
- 5dd552e6 arch: arc: STACK_CHECK_FAIL of STACK_CHECK not hang the system
- fb3d2d37 arch: arc: remove unused codes
- c63298ea arch: arc: improve the reset code
- 1c4fe3ed arch/arc: Set the right priority for ADC/AON on quark_se
- 97d04364 arch: arc: use top of isr stack as exception stack and bug fixes
- d5bc9d7b arch: arc: adjust privileged stack size of arc to 384 bytes

Bluetooth (3):

- ae829b26 Bluetooth: Fix unchecked settings value lengths
- ed5fb3ff Bluetooth: Mesh: Fix (re)transmit interval handling
- 1218648e Bluetooth: ATT: Fix clearing context at disconnect

Boards (1):

- f0bafc30 boards: make em_starterkit_em7d default test platform

Build (1):

- a37e0372 toolchain: gcc: Add compiler barrier at the end of UNALIGNED_PUT()

Continuous Integration (2):

- 5d6e7eb7 sanitycheck: export list of tests as CSV
- b20c4846 sanitycheck: fail on faults/panics/oopses

Documentation (22):

- 65e191fa api: watchdog: fix wdt_install_timeout doxygen comment
- 265f502b releasenotes: update with doc issues addressed
- 72d4d8bc doc: release notes: Fill in summary, arch, and kernel sections for 1.12
- d04a7efd releasenotes: updated documentation changes
- 59027fb6 doc: relnotes: Correct a couple of headline items
- b0abf365 doc: relnotes: 1.12 Bluetooth release notes
- 2825f79a doc: security: Update security overview for recent features
- 8b9042c4 doc: security: Remove revision history
- 3fc206fa getting_started: fix UNIX-ism
- 9ca4d840 getting_started: fixes for intro section
- 64ab1326 getting_started: fixes and cleanups for installation_linux
- c6c15013 getting_started: building: fix inaccuracies
- e8d0e72a doc: extensions: fix :app: behavior for zephyr-app-commands
- e802d8de doc: conf.py: remove unused import
- 1c852ddf doc: conf.py: make sure west is importable from Python
- 3a766aed doc: conf.py: add sphinx.ext.autodoc extension
- 869e9cce doc: add initial west documentation
- f8251693 conf.py: clean up exit if ZEPHYR_BASE is unset
- d6f2858a doc: relnotes: Add security vulnerability information
- 8e892068 doc: release notes: Update 1.12 release notes with GitHub issues
- d3afa353 doc: release notes: Update 1.12 release notes with more GitHub issues
- 51ae306b doc: release notes: Finalize 1.12 release notes and docs

Firmware Update (1):

- 2cba7017 subsys: mgmt: Remove unnecessary comparison

Kernel (2):

- 0e23ad88 kernel: k_work: k_work_init() should initialize all fields
- 2dd91eca kernel: move thread monitor init to common code

Libraries (1):

- bf1e0198 lib: posix: fix out-of-bound write

Miscellaneous (3):

- eb9df85f release: Move version to 1.12.0-rc3
- 3b1fb7f9 release: update footprint data
- f58d9cab release: Update VERSION for 1.12.0 release

Networking (5):

- 95555221 net: shell: Correct help text for "mem" command
- a957107d net: lwm2m: lower priority of engine thread
- d9a14f5a net: ipv6: Set hop limit in net_pkt according to IPv6 header
- e72dcf02 net: ipv4: Set TTL in net_pkt according to IPv4 header
- ed3ea06f net: lwm2m: fix observer attribute update logic

Samples (8):

- cf3da3c6 samples: crypto: Ensure cap_flags is always initialized
- 858cd199 samples: drivers: crypto: Do not show colors in logs
- d06eecbe samples: drivers: crypto: Update expected sample output
- d05442ee samples: crypto: adapt harness
- fd561dd5 samples: net: Check the return value of nats_publish
- e7a3d01d samples: net: dumb_http_server: Handle recv() errors
- b7ad50b4 samples: net: rpl_border_router: Fix out-of-bounds write
- 7cfd5a41 samples: net: hrpl_border_router: Fix NULL pointer dereference

Scripts (1):

- c6c856bc scripts: west: cherry-pick upstream 321ab2e17

Storage (2):

- 6a138977 susbys: disk: Fix misleading menuconfig prompts
- bfdb6aca subsys: settings: Fix file exist error.

Testing (13):

- 9cefce81 tests: remove obsolete k_thread_cancel
- a803af2f tests/kernel/preempt: Add yield and sleep cases
- a026b9ea tests: crypto: Fully initialize variables using named initializers
- a07d0731 tests: mbox_api: Fully initialize k_box_msg struct
- a803335a tests: net: Increase the stack size of frdm-k64f
- b43000f5 tests: net: trickle: Fix running on frdm-k64f
- 59bf65f4 tests: net: Fix tests so they can be run in real hw
- 3057da07 tests: logger-hook: increase ztest stack size
- bb631076 tests: arm: irq_vector_table: Fix Kconfig override
- fb2e142b tests: fix test identifiers
- 33aa9053 tests: kernel: fifo_timeout: Do not potentially dereference NULL ptrs
- 144a4390 tests: fix the bug of sentinel.conf
- a91f1e5e tests: modify the test conditions for emsk_em7d_v22


Re: is it possible to enable LE Coded PHY for #BluetoothMesh Nodes / #BLE devices? #ble #bluetoothmesh

Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
 

Hi Vikrant,

Advertising on Coded PHY needs the implementation of Extended Advertising feature of BT V5.0. This feature has not been implementation, only a initial effort was attempted.
That said, any contribution are welcome and I am available to assist in reviews.

Regards,
Vinayak


On 11 Jun 2018, at 17:48, vikrant8051 <vikrant8051@...> wrote:

Hi,


Is concept of, LE Codded PHY present in current Zephyr implementation to increase range
between two #BluetoothMesh Nodes ?

What is default configuration out of
- LE M1
- LE M2
- LE Coded ?


Thank You !!



is it possible to enable LE Coded PHY for #BluetoothMesh Nodes / #BLE devices? #ble #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi,


Is concept of, LE Codded PHY present in current Zephyr implementation to increase range
between two #BluetoothMesh Nodes ?

What is default configuration out of
- LE M1
- LE M2
- LE Coded ?


Thank You !!


Re: [Solved] Segger RTT support

Marcio Montenegro
 

My prj.conf file for beacon app:

CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=n
CONFIG_BT_DEVICE_NAME="Test beacon"
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y
CONFIG_I2C=y
CONFIG_I2C_NRF5=y
CONFIG_I2C_0=y
CONFIG_I2C_NRF5_0_GPIO_SDA_PIN=26
CONFIG_I2C_NRF5_0_GPIO_SCL_PIN=27
CONFIG_I2C_0_IRQ_PRI=7
CONFIG_UART_CONSOLE=n
CONFIG_SOC_NRF51822_QFAA=y
CONFIG_CONSOLE_HAS_DRIVER=y
CONFIG_RTT_CONSOLE=y
CONFIG_HAS_SEGGER_RTT=y
CONFIG_UART_NRF5=n
CONFIG_GPIO_NRF5_P0=y

The bluetooth module is nRF51 silicon version NRF51822_QFAA  and has just 1 xtal .I am using GPIO and I2C .
The project was tested on zephyr 1.11.0 version. Many thanks for help Carles.
Regards,
Marcio



Re: Segger RTT support

Carles Cufi
 

Hi Marcio,

 

Can you try adding:

 

CONFIG_UART_CONSOLE=n

 

to your prj.conf?

 

More info here:

 

http://docs.zephyrproject.org/tools/nordic_segger.html#rtt-console

 

Regards,

 

Carles

 

From: users@... <users@...> On Behalf Of Marcio Montenegro
Sent: 08 June 2018 16:30
To: zephyr-users@...; zephyr-devel@...
Subject: [Zephyr-users] Segger RTT support

 

Hi all,

 

I am trying to setup my nrf51 project to use Segger RTT console.I am compiling last version of Zephyr but any previous version can be used.

My nrf51 hardware is ok and  I can use RTT on Keil IDE.

 

This is my prj.conf file

 

CONFIG_BT=y

CONFIG_BT_DEBUG_LOG=y

CONFIG_BT_DEVICE_NAME="Test beacon"

CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y

CONFIG_I2C_NRF5=y

CONFIG_I2C_0=y

CONFIG_I2C_NRF5_0_GPIO_SDA_PIN=26

CONFIG_I2C_NRF5_0_GPIO_SCL_PIN=27

CONFIG_I2C_0_IRQ_PRI=7       

CONFIG_CONSOLE_HAS_DRIVER=y

CONFIG_RTT_CONSOLE=y

CONFIG_HAS_SEGGER_RTT=y

 

On ninja menuconfig I can't find any option for Segger RTT.

Is there any documentation or example ? Am I missing a step ?

Best,

Marcio Montenegro

 

 

 

 


Segger RTT support

Marcio Montenegro
 

Hi all,

I am trying to setup my nrf51 project to use Segger RTT console.I am compiling last version of Zephyr but any previous version can be used.
My nrf51 hardware is ok and  I can use RTT on Keil IDE.

This is my prj.conf file

CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_DEVICE_NAME="Test beacon"
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y
CONFIG_I2C_NRF5=y
CONFIG_I2C_0=y
CONFIG_I2C_NRF5_0_GPIO_SDA_PIN=26
CONFIG_I2C_NRF5_0_GPIO_SCL_PIN=27
CONFIG_I2C_0_IRQ_PRI=7
CONFIG_CONSOLE_HAS_DRIVER=y
CONFIG_RTT_CONSOLE=y
CONFIG_HAS_SEGGER_RTT=y

On ninja menuconfig I can't find any option for Segger RTT.
Is there any documentation or example ? Am I missing a step ?
Best,
Marcio Montenegro





Re: [Zephyr-devel] #BluetoothMesh Lighting Model implementation #bluetoothmesh

Aaron Xu <overheat1984@...>
 

Hi,

MyNewt's is a good start point. But looks need more work to make zephyr bluetooth mesh be used in light.
I am looking forward it. In the mean time, I can start sensor model coding on zephyr when the 1.12 released.

Regards,
Aaron

vikrant8051 <vikrant8051@...> 于2018年6月7日周四 上午2:08写道:

Hi Johan, 

Mynewt's lighting model app is very simple & basic, if compare it with diagram on page 296 of model specs. And it is not what I'm expecting.

Hello Bluetooth_SIG members,

Is Bluetooth_SIG going to maintain this complicated architecture in Spec 2.0  Or there will be something easy on the way ?

Thank You!!

On Wed, Jun 6, 2018, 8:25 PM Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

On Wed, Jun 06, 2018, vikrant8051 wrote:
> is there any one who tried to implement Lighting Models (page 296 of
> Mesh_Model_Specification v1.0.pdf) using Zephyt #BluetoothMesh API ?
>
> I want to control three things -> Light On Off, Light Lightness
> (intensity), Light CTL (cool to warm white) using single message. This is
> possible only with Lighting Models.
>
> Also want to build remote using #nRF52840_PDK which support Lighting Client
> Models.
>
> FYI, this is Mynewt implementation,
> https://github.com/apache/mynewt-core/blob/master/apps/blemesh_light/src/light_model.c

MyNewt's Bluetooth Mesh is essentially the same as Zephyr's mesh, since
it was ported from Zephyr. Most likely you can take any model
implementation from there and use it directly (or with minor changes)
with Zephyr. In fact, I'd welcome if someone wants to port any missing
mesh models from the MyNewt tree to Zephyr.

Johan


Re: [Zephyr-devel] #BluetoothMesh Lighting Model implementation #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi Johan, 

Mynewt's lighting model app is very simple & basic, if compare it with diagram on page 296 of model specs. And it is not what I'm expecting.

Hello Bluetooth_SIG members,

Is Bluetooth_SIG going to maintain this complicated architecture in Spec 2.0  Or there will be something easy on the way ?

Thank You!!

On Wed, Jun 6, 2018, 8:25 PM Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

On Wed, Jun 06, 2018, vikrant8051 wrote:
> is there any one who tried to implement Lighting Models (page 296 of
> Mesh_Model_Specification v1.0.pdf) using Zephyt #BluetoothMesh API ?
>
> I want to control three things -> Light On Off, Light Lightness
> (intensity), Light CTL (cool to warm white) using single message. This is
> possible only with Lighting Models.
>
> Also want to build remote using #nRF52840_PDK which support Lighting Client
> Models.
>
> FYI, this is Mynewt implementation,
> https://github.com/apache/mynewt-core/blob/master/apps/blemesh_light/src/light_model.c

MyNewt's Bluetooth Mesh is essentially the same as Zephyr's mesh, since
it was ported from Zephyr. Most likely you can take any model
implementation from there and use it directly (or with minor changes)
with Zephyr. In fact, I'd welcome if someone wants to port any missing
mesh models from the MyNewt tree to Zephyr.

Johan

1821 - 1840 of 2707