1. devel@lists.zephyrproject.org
  2. Messages
   Date   
about newly introduced #BluetoothMesh persistent storage feature #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi, 

How to save (SIG or Vendor) Model states on SoC flash ? Is it going to be depend upon setting layer which is newly introduce concept or gonna completely independent as part of App layer ?

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

There are 2 types of Persistent Data in context of #BluetoothMesh:
1) constant 
     (which is created & saved during provisioning & configuration )

2) non - constant 
  ( eg. Sequence no., Models states etc.) 

Is current implementation using same sector of flash for both ? 

Will it be secured during #DFU_OTA ?
Where it is define for every Board? Where I can get details about flash memory sector which here acting like EEPROM ?


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

If Node is receiving 100 messages a day in which destination address could be it's own or group address for which it has subscribed, then what will be life of that device  (assuming SoC flash supports 10K erase cycles) as per FCB based current implementation ?

Is there any documentation which shows approximate life span of #BluetoothMesh NODE in different scenarios if we go ahead with #FCB ( or upcoming #NVS layer) ?

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


If we use #meshctl, then sometimes it complete provisioning but it fails after executing 

--> appkey-add 1

& something constantly goes on #meshctl terminal. Is anyone observed same ? 

[In that case, I have to reflash the firmware or reset the board & send node-reset command via #meshctl.]

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

If provisioning or configuration fails & there is no hardware reset button to trigger bt_mesh_reset() in that case, how to push device into factory reset mode ? Any Idea ?

My solution is to add vendor state (Let it be Foo) which will be set to "1" only after proper provisioning & configuration by provisioner App.
 
On device side following logic will get execute after every reset

   if(Foo == 0)
   {
        bt_mesh_reset( );
   }

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


Thank You !!
Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Johan Hedberg
 

Hi Kai,

On Fri, May 11, 2018, Kai Ren wrote:
Following your suggestion, I just did a test on it after git fetch
7428. After compiling and running "mesh_demo", at least, sequence
number store and restore work well on my side. I use micro:bit as the
platform. :  But I have a question: when sequence number reach to
0x1A, I reset the board, after restoring, then I pressed button to
send message, sequence number start at 0x89, what is the consideration
on this? 
The idea is to avoid excessive flash writes (or worse, flash erases).
There's a variable that's set with CONFIG_BT_MESH_SEQ_STORE_RATE. It
controls that only the Nth sequence number increment gets stored. Since
only the Nth sequence gets stored, we have to add N upon bootup to the
stored value to ensure that we start with something that's guaranteed to
be higher than the last sent message when the board was powered off.

Btw, the PR is already merged to master, so you can just the master
branch from now on.

Johan
Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Kai Ren
 

Hi Johan,

Following your suggestion, I just did a test on it after git fetch 7428.
After compiling and running "mesh_demo", at least, sequence number store and restore work well on my side. I use micro:bit as the platform. : 
But I have a question: when sequence number reach to 0x1A, I reset the board, after restoring, then I pressed button to send message, sequence number start at 0x89, what is the consideration on this? 

Kai
Re: Read connection RSSI always return -127

전형욱
 

Hi Carles,

Thank you for your reply.

Yes, I enable COFIG_BT_CTRL_CONN in prj.conf file.
HCI command was successfully executed but I got always -127 for rssi value.
(Please refer to btmon log in my previous message.)

Regrads,
Hyoungwook

2018-05-11 오후 6:28에 Cufi, Carles 이(가) 쓴 글:

Hi there,

 

Strange, this should work as expected. I haven’t tested it myself but will do if you cannot figure it out.

 

Have you enabled the CONFIG_BT_CTLR_CONN_RSSI option in Kconfig?

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of ???
Sent: 10 May 2018 03:35
To: devel@...
Subject: [Zephyr-devel] Read connection RSSI always return -127

 

Hello,

I wrote the same question on user forum but haven't got any response so I'm writing this on devel forum, too.

I'm developing HCI UART dongle using nRF52840 based on Zephyr v1.11 branch.
Everything works fine now except for reading RSSI on connected device.

HCI commands were successfully executed but always return -127.

< HCI Command: Read RSSI (0x05|0x0005) plen 2            #488 [hci1] 620.325803
        Handle: 0
> HCI Event: Command Complete (0x0e) plen 7              #489 [hci1] 620.326563
      Read RSSI (0x05|0x0005) ncmd 1
        Status: Success (0x00)
        Handle: 0
        RSSI: -127 dBm (0x81)

It is the same on nRF52840_pca10056 reference board.

Here are contents of prj.conf file.

CONFIG_CONSOLE=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_NRF5_BAUD_RATE=1000000
CONFIG_UART_NRF5_FLOW_CONTROL=y
CONFIG_MAIN_STACK_SIZE=512
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512
CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=16
CONFIG_BT_TINYCRYPT_ECC=y
CONFIG_BT_CTLR_DTM_HCI=y
CONFIG_BT_CTLR_ASSERT_HANDLER=n
CONFIG_BT_HCI_ACL_FLOW_CONTROL=y
CONFIG_BT_CTLR_DATA_LENGTH=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_GPIO_LNA=y
CONFIG_BT_CTLR_GPIO_LNA_PIN=28
CONFIG_BT_CTLR_GPIO_PA=y
CONFIG_BT_CTLR_GPIO_PA_PIN=3
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_CONN_RSSI=y

Is there anything that I need to configure in project setting?

Regards,

Hyoungwook Jeon

 
64 bit time stamp in microseconds (us)

Abderrezak Mekkaoui
 

Hi All,
Does anybody know how to reliably implement a 64 bit (int64_t) time stamp in microseconds?
Thanks and have a great WE.
Abderrezak
Re: Using SPI_SLAVE on STM32

Armando Visconti
 

Hello Thomasz,

Quick update before leaving for the week.

I took the patches suggested by you and I prepared
a very simple test environment. I have an issue
though: it seems that I'm not able to consume data
at the proper speed and OVR error is found in SR.

Just for testing I tried to comment the error out and
what I see is that I receive 1 byte evry 3.

I think I can slow down the spi master, but I think that
we would need to add DMA handling to stm32 spi. Is there
any plan?

Thanks,
Armando

On 05/04/2018 03:00 PM, Tomasz Bursztyka wrote:
It has not been rebased against latest SPI API changes, thus why it
can't be merged. But it's a fine PR besides that.
Tomasz

Thx Tomasz,

On 05/04/2018 02:08 PM, Tomasz Bursztyka wrote:
Hi,

Check this PR: https://github.com/zephyrproject-rtos/zephyr/pull/52
00
You probably need the first patch, and the second is an example how
to
do it. Note however the API has changed a bit, you'll have to
check.
It seems quite old. Why hasn't it been merged yet?
Is there something wrong that prevent it?
Re: IPv6 addresses

Diana Rivera
 

Hi Jukka,

Thanks for your answer. If SLAAC is enabled by default, how are you then able to know the device's IPv6 address so that so that it can be set as the PEER_ADDR of another device?

I've been also trying to run the OpenThread shell by simply enabling CONFIG_OPENTHREAD_SHELL=y in the Kconfig file, but it doesn't seem to be having any effect. What is the proper way to run this shell?

Once again. Thank you for your answer.

Best regards,
Diana
Re: problems building a BME680 app: zephyr_prebuilt.elf uses VFP register arguments ....

Abderrezak Mekkaoui <ab.mekka@...>
 

Hi All,

Just in case this is helpful. To build and correctly run my app, I needed to add the following configuration variables to my prj.conf:

CONFIG_FLOAT=y
CONFIG_NEWLIB_LIBC=y

Nothing else is needed because everything is defined with the board (nrf52840_pca10056).

Adding CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y would enable float fprinting for debugging.
Thanks for your help.
Abderrezak

On 5/7/2018 12:04 PM, Abderrezak Mekkaoui wrote:
Hi All,
I am having problems porting a BME680 app to Zephyr. This app uses a pre-compiled library (libalgobsec.a) provided by Bosch.
It builds and runs correctly on mynewt (using the exact same tool chain and the same flags). After solving few issues related to stdint I am struggling with the last issues possibly related incompatibilities between different libraries.
I think I am using the right compiler and linker flags (see below) but I may be wrong.
Any hints/help would be greatly appreciated.
Regards
Abderrezak

P.S. I have other apps that  build and run correctly using the same tool chain (but use the default zephyr flags and have no need for an external binary library). I am using a custom nrf52840 based board.



###########################################################################################################################################################
CMakelists.txt (latest flag settings, many other combinations all failed)

target_link_libraries(app libalgobsec.a)
target_link_libraries(app libm.a)

set(FPU_FOR_cortex-m4      fpv4-sp-d16)
target_link_libraries(app m.a)
zephyr_cc_option(-DFLOAT_ABI_HARD -mcpu=cortex-m4 -mthumb-interwork -mthumb -mabi=aapcs -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fno-exceptions -ffunction-sections -fdata-sections )
zephyr_ld_options(-static -specs=nosys.specs -lgcc -Wl,--gc-sections -nostartfiles -mthumb -mabi=aapcs -mfloat-abi=hard -mfpu=fpv4-sp-d16 -DFLOAT_ABI_HARD -lalgobsec -lm)
#

###########################################################################################################################################################
Error messages (only few lines)

/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_popcountsi2.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_popcountsi2.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_udivmoddi4.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_udivmoddi4.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp2_data.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp2_data.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_fabs.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_fabs.o)
Re: IPv6 addresses

Jukka Rissanen
 

Hi Diana,

the static IP address configuration is fully optional and is only meant
to make testing a bit easier. So if you want to have auto IPv6
addresses, then just do not set CONFIG_NET_APP_MY_IPV6_ADDR option.

SLAAC is enabled by default. Please create a github issue if you find
bugs in it.


Cheers,
Jukka

On Fri, 2018-05-11 at 11:39 +0200, Diana Rivera wrote:
Hello,

I am currently working on an OpenThread application based on
echo_client and echo_server. I have noticed that the devices' IPv6
addresses are set in the configuration file through
CONFIG_NET_APP_MY_IPV6_ADDR.
I was wondering if there is another way to set the devices' IPv6
addresses without having to modify the configuration file every time?

Zephyr's documentation mentions the possibility to use SLAAC. Could
you please point me in the right direction to use it instead of
having to set static IPv6 addresses?

Thank you in advance,
Diana
IPv6 addresses

Diana Rivera
 

Hello,

I am currently working on an OpenThread application based on echo_client and echo_server. I have noticed that the devices' IPv6 addresses are set in the configuration file through CONFIG_NET_APP_MY_IPV6_ADDR.
I was wondering if there is another way to set the devices' IPv6 addresses without having to modify the configuration file every time?

Zephyr's documentation mentions the possibility to use SLAAC. Could you please point me in the right direction to use it instead of having to set static IPv6 addresses?

Thank you in advance,
Diana
Re: Read connection RSSI always return -127

Carles Cufi
 

Hi there,

 

Strange, this should work as expected. I haven’t tested it myself but will do if you cannot figure it out.

 

Have you enabled the CONFIG_BT_CTLR_CONN_RSSI option in Kconfig?

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of ???
Sent: 10 May 2018 03:35
To: devel@...
Subject: [Zephyr-devel] Read connection RSSI always return -127

 

Hello,

I wrote the same question on user forum but haven't got any response so I'm writing this on devel forum, too.

I'm developing HCI UART dongle using nRF52840 based on Zephyr v1.11 branch.
Everything works fine now except for reading RSSI on connected device.

HCI commands were successfully executed but always return -127.

< HCI Command: Read RSSI (0x05|0x0005) plen 2            #488 [hci1] 620.325803
        Handle: 0
> HCI Event: Command Complete (0x0e) plen 7              #489 [hci1] 620.326563
      Read RSSI (0x05|0x0005) ncmd 1
        Status: Success (0x00)
        Handle: 0
        RSSI: -127 dBm (0x81)

It is the same on nRF52840_pca10056 reference board.

Here are contents of prj.conf file.

CONFIG_CONSOLE=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_NRF5_BAUD_RATE=1000000
CONFIG_UART_NRF5_FLOW_CONTROL=y
CONFIG_MAIN_STACK_SIZE=512
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512
CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=16
CONFIG_BT_TINYCRYPT_ECC=y
CONFIG_BT_CTLR_DTM_HCI=y
CONFIG_BT_CTLR_ASSERT_HANDLER=n
CONFIG_BT_HCI_ACL_FLOW_CONTROL=y
CONFIG_BT_CTLR_DATA_LENGTH=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_GPIO_LNA=y
CONFIG_BT_CTLR_GPIO_LNA_PIN=28
CONFIG_BT_CTLR_GPIO_PA=y
CONFIG_BT_CTLR_GPIO_PA_PIN=3
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_CONN_RSSI=y

Is there anything that I need to configure in project setting?

Regards,

Hyoungwook Jeon

 
Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Johan Hedberg
 

Hi Kai,

Please check the PR I referenced earlier. I've added a patch there to
convert mesh_demo to use settings. It was actually the other way around
that it made sense to do the calls: first settings_load() and then
bt_mesh_provision(). That way we can catch an -EALREADY return from
bt_mesh_provision() which tells us that calling configure() should not
be done.

Johan

On Fri, May 11, 2018, Kai Ren wrote:
Thanks for the reply!

The problem I suffered is that: when I run mesh_demo on microbit, I can't restore SEQ after a reset, when means that if a GenericOnOff client reset unexpected, I need to make this client catch up the SEQ on GenericOnOff server. 

I saw that there are two functions which seem to be store and restore SEQ,

void board_seq_update( u32_t seq);

static u32_t get_seq( void );

but get_seq() is called in board initial, but I don't find any piece about board_seq_update().

I agree with you, mesh_demo doesn't need persistent storage because its netkey, devkey and appkey are already in flash memory, but one thing need to be solved is SEQ. 


Also, if you run it on the BBC micro:bit be sure to remove
the direct flash access from src/microbit.c.
What does it mean? 

Kai
Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Kai Ren
 

Thanks for the reply!

The problem I suffered is that: when I run mesh_demo on microbit, I can't restore SEQ after a reset, when means that if a GenericOnOff client reset unexpected, I need to make this client catch up the SEQ on GenericOnOff server. 

I saw that there are two functions which seem to be store and restore SEQ,

void board_seq_update(u32_t seq);

static u32_t get_seq(void);

but get_seq() is called in board initial, but I don't find any piece about board_seq_update().

I agree with you, mesh_demo doesn't need persistent storage because its netkey, devkey and appkey are already in flash memory, but one thing need to be solved is SEQ. 
Also, if you run it on the BBC micro:bit be sure to remove
the direct flash access from src/microbit.c.
What does it mean? 

Kai
Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Johan Hedberg
 

Hi Kai,

On Fri, May 11, 2018, Kai Ren wrote:
I noticed that zephyr start to support persistent storage for
provisioning data like:
{ "Net", net_set },
{ "IV", iv_set },
{ "Seq", seq_set },
{ "RPL", rpl_set },
{ "NetKey", net_key_set },
{ "AppKey", app_key_set },
Also note that the remaining state storing is coming as part of the
following PR:

https://github.com/zephyrproject-rtos/zephyr/pull/7428

Essentially everything is in place there now, but I still need to think
a little about how to handle IV Update - we may need to store in some
circumstances information about how many hours the node has been in a
certain state.

And I know that it's already added in the sample of
./sample/bluetooth/mesh/, I know that this sample need a provisioner
to provision it. I'm curious that does the persistent storage function
can be used by the sample of ./sample/bluetooth/mesh_demo/ because
this sample is an example of self-provisioning.
I think there might be some conflicts, or at least interesting
artifacts, since mesh_demo calls itself bt_mesh_provision() and
restoring values from flash does essentially the same thing. That said,
I'm not sure what the benefit would be? Perhaps to restore the Seq and
RPL? You could try it, but be sure to call settings_load() only after
bt_mesh_provision() so that stored values overwrite the ones hard-coded
in the app. Also, if you run it on the BBC micro:bit be sure to remove
the direct flash access from src/microbit.c.

Johan
#BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Kai Ren
 

Hello,

I noticed that zephyr start to support persistent storage for provisioning data like:
{ "Net", net_set },
{ "IV", iv_set },
{ "Seq", seq_set },
{ "RPL", rpl_set },
{ "NetKey", net_key_set },
{ "AppKey", app_key_set },

And I know that it's already added in the sample of ./sample/bluetooth/mesh/, I know that this sample need a provisioner to provision it. I'm curious that does the persistent storage function can be used by the sample of ./sample/bluetooth/mesh_demo/ because this sample is an example of self-provisioning.
Thanks.

Regards,
Kai
Re: Can't download in chuncks using https

christian tavares
 

I was able to resolve this problem by configuring the server to send smaller fragments than it was sending
Re: new PR adding initial dts support for nrf52 gpio, needs reviewer(s)

Carles Cufi
 

Hi Marc,

 

Thanks very much for your PR. Since you cannot add reviewers yourself I have added them for you.

 

Regards,

 

Carles

 

From: <devel@...> on behalf of Marc Reilly <marc.reilly@...>
Date: Thursday, 10 May 2018 at 10:28
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] new PR adding initial dts support for nrf52 gpio, needs reviewer(s)

 

Hi,

I've just added PR #7444 (https://github.com/zephyrproject-rtos/zephyr/pull/7444), but I'm not sure who to ask as reviewer(s). So, I'd like to make an appeal to anyone who is interested in bringing nrf52 devices into using device tree to have a look and give some advice.

Its a small change, but already it means for example that nrf boards could use the "gpio-leds" dt binding to generate some defines for leds.

Next steps are to support pin selection for common drivers like uart, spi, i2c, etc. as well as pin selection for interrupts etc.

All and any feedback will be much appreciated..

I also invite anyone to ask me to review theirs, although I'm still a novice here.

 

Cheers

Marc

 

 
new PR adding initial dts support for nrf52 gpio, needs reviewer(s)

Marc Reilly
 

Hi,

I've just added PR #7444 (https://github.com/zephyrproject-rtos/zephyr/pull/7444), but I'm not sure who to ask as reviewer(s). So, I'd like to make an appeal to anyone who is interested in bringing nrf52 devices into using device tree to have a look and give some advice.

Its a small change, but already it means for example that nrf boards could use the "gpio-leds" dt binding to generate some defines for leds.

Next steps are to support pin selection for common drivers like uart, spi, i2c, etc. as well as pin selection for interrupts etc.

All and any feedback will be much appreciated..
I also invite anyone to ask me to review theirs, although I'm still a novice here.

Cheers
Marc
Read connection RSSI always return -127

전형욱
 

Hello,

I wrote the same question on user forum but haven't got any response so I'm writing this on devel forum, too.

I'm developing HCI UART dongle using nRF52840 based on Zephyr v1.11 branch.
Everything works fine now except for reading RSSI on connected device.

HCI commands were successfully executed but always return -127.

< HCI Command: Read RSSI (0x05|0x0005) plen 2            #488 [hci1] 620.325803
        Handle: 0
> HCI Event: Command Complete (0x0e) plen 7              #489 [hci1] 620.326563
      Read RSSI (0x05|0x0005) ncmd 1
        Status: Success (0x00)
        Handle: 0
        RSSI: -127 dBm (0x81)
It is the same on nRF52840_pca10056 reference board.

Here are contents of prj.conf file.
CONFIG_CONSOLE=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_NRF5_BAUD_RATE=1000000
CONFIG_UART_NRF5_FLOW_CONTROL=y
CONFIG_MAIN_STACK_SIZE=512
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512
CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=16
CONFIG_BT_TINYCRYPT_ECC=y
CONFIG_BT_CTLR_DTM_HCI=y
CONFIG_BT_CTLR_ASSERT_HANDLER=n
CONFIG_BT_HCI_ACL_FLOW_CONTROL=y
CONFIG_BT_CTLR_DATA_LENGTH=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_GPIO_LNA=y
CONFIG_BT_CTLR_GPIO_LNA_PIN=28
CONFIG_BT_CTLR_GPIO_PA=y
CONFIG_BT_CTLR_GPIO_PA_PIN=3
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_CONN_RSSI=y

Is there anything that I need to configure in project setting?

Regards,

Hyoungwook Jeon
1.12 merge window closing soon

Maureen Helm
 

The Zephyr 1.12 release feature merge window is due to close soon. Our original schedule had this milestone set for today, but the TSC agreed to extend the merge window by one week to allow a few remaining 1.12 roadmap features to make it in. These features include OpenAMP (#3065) and full persistent storage for Bluetooth (#7073).

 

If you have any new features in the works that you would like to get into the 1.12 release, please submit a PR as soon as possible. After the feature merge window closes on Friday May 18, we will only merge bug fixes and documentation until the release. Please also help out by reviewing PRs from other contributors. Even if you do not have merge privileges, it is a big help if you review and vote on PRs.

 

Thanks for all your contributions!

 

Schedule:

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

 

Roadmap:

https://github.com/zephyrproject-rtos/zephyr/projects/9

 

?
smime.p7s

4081 - 4100 of 8638