Date   

Re: Pairing/bonding Zephyr API? Pairing info?

Johan Hedberg
 

Hi Frank,

On 6 Feb 2019, at 11.21, frv <F.Vieren@televic.com> wrote:
It all works like a charm now, after a power cycle the BLE central applic reconnects without authentication issues anymore.
Good to hear!

I know you can run an emulator on a host PC but probably without the BT HW this is hard to do unless the host BT device can be used? Is this possible?
Yes, it’s possible, however you need to use Linux as your development environment (in case you were using MacOS or Windows until now).

There are instructions available here:

https://docs.zephyrproject.org/latest/subsystems/bluetooth/devel.html#bluetooth-qemu

Johan


Re: Pairing/bonding Zephyr API? Pairing info?

frv
 

Hi Johan, all,


It all works like a charm now, after a power cycle the BLE central applic reconnects without authentication issues anymore. 

So indeed flash configuration was required as demonstrated in the BT peripheral applic. 

Sometimes hard to follow what happens behind the scene, e.g. settings_load. So a lot of work for me to understand better Zephyr and some of it subsystems. 


I'm wondering what will be my next issue. Anyhow very happy with the result so far. 

Basically I have all that is needed for the prototyping of our use case. Just have to replace the BT HR applic with a BT peripheral applic that keeps track of a button press on the nRF52 board. 


As I just do little modifications to the existing BT demo software, I wondering if there exist a better way to develop and debug coding on Zephyr without having to re-flash all the time when something needs to be modified in application. 


I know you can run an emulator on a host PC but probably without the BT HW this is hard to do unless the host BT device can be used? Is this possible?


Thanks!


Best regards,

Frank


Re: Pairing/bonding Zephyr API? Pairing info?

frv
 

Hi Johan,


Sorry for messing up my messages on the forum.

I will try to remember, unfortunately not the first time, I will do my best to do better in the future.


Anyway thanks for pointing me in the right direction.


I'm still getting familar with Zephyr and also with Bluetooth LE. 

Programming in different languages (C / C++) and platforms(Linux / Zephyr) makes it not easier, anyhow we love the challenges as SW developer :).


Ok, I will have a look at the Peripheral example and see how to continue with finalizing my BLE implementation on Zephyr. 


Thanks again for your feedback and I will keep the forum informed on the progress I'm making.


Best regards,

Frank


Van: Hedberg, Johan <johan.hedberg@...>
Verzonden: dinsdag 5 februari 2019 20:45:06
Aan: Vieren Frank
CC: devel@...
Onderwerp: Re: [Zephyr-devel] Pairing/bonding Zephyr API? Pairing info?
 
Hi Frank,

Please try not to use any “edit” feature on the mailing lists web-interface. It makes it very difficult to understand what’s going on when reading your emails with a normal email client.

> On 5 Feb 2019, at 19.48, frv <F.Vieren@...> wrote:
> When I run make menuconfig,
> BT_SETTINGS(=n) "Store Bluetooth state and configuration persistently"
> I can't seem to get this to y(es).
>
> When entering it "Store Bluetooth state and configuration persistenly (NEW) is in red. And nothing can be selected
>
> Normal?
>
> Probably need to first get the Disk/Flash configured

Yes, you need to have flash and the settings subsystem enabled. Simplest is probably to look at any of the existing Bluetooth samples that already successfully use BT_SETTINGS. E.g. samples/bluetooth/peripheral is one such sample. peripheral_hr is (unfortunately) not. Note that even after enabling the Kconfig options you’ll also need to update your app to make a call to settings_load() after calling bt_enable(). Take a look at how and where the peripheral app does this in its main.c. As for the Kconfig options, I believe the following from the peripheral app’s prj.conf are the necessary options, assuming you’re ok with the FCB backend (there’s also an NFFS one):

CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_FCB=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_FCB=y

Johan


Re: Pairing/bonding Zephyr API? Pairing info?

Johan Hedberg
 

Hi Frank,

Please try not to use any “edit” feature on the mailing lists web-interface. It makes it very difficult to understand what’s going on when reading your emails with a normal email client.

On 5 Feb 2019, at 19.48, frv <F.Vieren@televic.com> wrote:
When I run make menuconfig,
BT_SETTINGS(=n) "Store Bluetooth state and configuration persistently"
I can't seem to get this to y(es).

When entering it "Store Bluetooth state and configuration persistenly (NEW) is in red. And nothing can be selected

Normal?

Probably need to first get the Disk/Flash configured
Yes, you need to have flash and the settings subsystem enabled. Simplest is probably to look at any of the existing Bluetooth samples that already successfully use BT_SETTINGS. E.g. samples/bluetooth/peripheral is one such sample. peripheral_hr is (unfortunately) not. Note that even after enabling the Kconfig options you’ll also need to update your app to make a call to settings_load() after calling bt_enable(). Take a look at how and where the peripheral app does this in its main.c. As for the Kconfig options, I believe the following from the peripheral app’s prj.conf are the necessary options, assuming you’re ok with the FCB backend (there’s also an NFFS one):

CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_FCB=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_FCB=y

Johan


Re: Pairing/bonding Zephyr API? Pairing info?

frv
 
Edited

On Tue, Feb 5, 2019 at 02:51 PM, Johan Hedberg wrote:
Note that you need to have flash storage support enabled, including CONFIG_BT_SETTINGS, in order for the bonding information to be persistently stored and reloaded after a power cycle.
https://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_BT_SETTINGS.html

Merging /home/frv/zephyr/samples/bluetooth/peripheral_hr/prj.conf warning: BT_SETTINGS (defined at subsys/bluetooth/host/Kconfig:139) was assigned the value 'y' but got the value 'n'.


When I run make menuconfig, 
BT_SETTINGS(=n) "Store Bluetooth state and configuration persistently"
I can't seem to get this to y(es).

When entering it "Store Bluetooth state and configuration persistenly (NEW) is in red. And nothing can be selected

Normal?

Probably need to first get the Disk/Flash configured, what are appropriate values for the Flash?
Currently I'm using 117012 bytes or 22% of 512KB.

Thanks,
Best regards,

Frank


Re: Zephyr SDK 0.10.0-rc2 available

Paul Sokolovsky
 

Hello Anas,

Do we make Zephyr 1.14 release with the stable 0.9.5 SDK?

On Tue, 5 Feb 2019 12:55:48 +0000
"Nashif, Anas" <anas.nashif@intel.com> wrote:

Hi,
We are excited to announce the availability of a new pre-release of
the Zephyr SDK.

This release of the SDK provides a major update to all tools and
toolchains. The current SDK was based on yocto, this release uses
crosstool-ng for the toolchains and yocto for the host tools.

Major changes in this release:
[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Pairing/bonding Zephyr API? Pairing info?

frv
 
Edited

Hi Johan,

thanks for the feedback.

- conn.h and missing function void set_bondable():
Not sure what went wrong but in my git checkout I see after executing the command git branch in the zephyr/include/bluetooth/ : HEAD detached at v1.13.0, and in the conn.h I'm missing the set_bondable function call. 
Nevertheless it is clear for me that this is not an issue for my current problem.

- So why I need to know if I'm paired? Well maybe and probably my wrong doing of using the fixed passkey.... 

So my working flow is :
- in the BLE peripheral applic I use a fixed passkey that is randomly generated and set via the function call : bt_passkey_set
- my BLE central applic initiates the pairing process to the peripheral device. 
- at the central side, the passkey is asked that was generated in the peripheral.
- so after providing the correct passkey (can be done automatically via the BlueZ API, without manual interaction via a keyboard), the pairing is successfully.
- the BLE central applic can now successfully connect to the peripheral applic and subscribe to the "change" notifications of the heart rate measurement characteristic. 

 - now I restart/power cycle the nRF52 running the BLE peripheral applic, so I call again the "bt_passkey_set" as I don't check if the device is already paired (the reason for my question earlier). So this is probably already fishy... 

As the BLE Central application still sees that it is paired with the BLE peripheral, it just calls a function to make a connection, it will not initiate again a pairing process.
But the BLE peripheral, rejects the connection with returning an error, hci error code: 0x05, meaning authorization failure... 

However after rebuilding my Zephyr peripheral applic without the bt_passkey_set, I still get the connection rejection in the peripheral applic throwing the authorization failure as reason.

So what do I still do wrong? Forgive me I'm still learning... 

Best regards,
Frank

ADDITIONAL INFO: 
I used the peripheral_sc_only example to implement a secure connection.

So in my connected callback function I have this:

static void connected(struct bt_conn *conn, u8_t err)
{
        if (err)
        {
                printk("Connection failed (err %u)\n", err);
        }
        else
        {
                default_conn = bt_conn_ref(conn);
                printk("Connected\n");
                if (bt_conn_security(conn, BT_SECURITY_FIPS) < 0)
                {
                        printk("Failed to set security...\n");
                        bt_conn_disconnect(conn, 0);
                }
        }
}
 


Re: Pairing/bonding Zephyr API? Pairing info?

Johan Hedberg
 

Hi Frank,


On 5 Feb 2019, at 15.25, frv <F.Vieren@televic.com> wrote:
If the pairing process has succeeded is bonding automatically done?
I don't really understand the comment in the Bluetooth API for the function call:
"For the vast majority of applications calling this function shouldn’t be needed."

void bt_set_bondable(bool enable)

"Set/clear the Bonding flag in the Authentication Requirements of SMP Pairing Request/Response data. The initial value of this flag depends on BT_BONDABLE Kconfig setting. For the vast majority of applications calling this function shouldn’t be needed."

BTW I don't find this API any longer in Bluetooth code (V1.14), probably no longer valid?
Why do you say that? It’s still there in include/bluetooth/conn.h. However, the comment is correct - Zephyr defaults to bondable, so you only need to touch this stuff if you want to perform qualification tests on non-bondable mode.

Pairing:

Also is there an API call to see if the device is already paired? Because after a board startup(power cycle) I don't want to set a new passkey if the device is already paired.

In my case the BLE peripheral sets a random fixed passkey at startup and the connecting central needs to set this passkey after initiating the pairing process.
You can iterate through existing bonds using the bt_foreach_bond() API, however it’s not clear to me why your application would need to use it - if a device is bonded then the previously stored LTK will be used, and if it’s not bonded then a new pairing process will be triggered. Note that you need to have flash storage support enabled, including CONFIG_BT_SETTINGS, in order for the bonding information to be persistently stored and reloaded after a power cycle.

Johan


Pairing/bonding Zephyr API? Pairing info?

frv
 

Hi,


Bonding:


If the pairing process has succeeded is bonding automatically done? 

I don't really understand the comment in the Bluetooth API  for the function call:

"For the vast majority of applications calling this function shouldn’t be needed."


void bt_set_bondable(bool enable)


"Set/clear the Bonding flag in the Authentication Requirements of SMP Pairing Request/Response data. The initial value of this flag depends on BT_BONDABLE Kconfig setting. For the vast majority of applications calling this function shouldn’t be needed."


BTW I don't find this API any longer in Bluetooth code (V1.14), probably no longer valid?


Pairing:


Also is there an API call to see if the device is already paired? Because after a board startup(power cycle) I don't want to set a new passkey if the device is already paired. 


In my case the BLE peripheral sets a random fixed passkey at startup and the connecting central needs to set this passkey after initiating the pairing process. 


Thanks,

Best regards,

Frank


Zephyr SDK 0.10.0-rc2 available

Nashif, Anas
 

Hi,

We are excited to announce the availability of a new pre-release of the Zephyr SDK.

 

This release of the SDK provides a major update to all tools and toolchains. The current SDK was based on yocto, this release uses crosstool-ng for the toolchains and yocto for the host tools.

 

Major changes in this release:

 

·       Use crosstool-ng for building the toolchains

·       Update toolchains to GCC 8.2

·       bossa: Update to 1.9.1

·       qemu: Update to release 3.1.0

·       Update openocd to Zephyr Branch from 20190130

 

The SDK is available for download from  https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.10.0-rc2

 

 

Knowns issues:

-          Newlib with xtensa targets does not work yet.

-          1 nios2 tests fails to build

 

 

If you find any issues or have general feedback, use the following issue system to report:

 

https://github.com/zephyrproject-rtos/sdk-ng/issues

 

 

Regards,

Anas Nashif

 


Re: Introducing west, Zephyr's meta-tool

Carles Cufi
 

Hi David,

-----Original Message-----
From: David Leach <david.leach@nxp.com>
Sent: 05 February 2019 06:40
To: Cufi, Carles <Carles.Cufi@nordicsemi.no>; zephyr-devel <zephyr-
devel@lists.zephyrproject.org>; zephyr-users@lists.zephyrproject.org
Subject: RE: Introducing west, Zephyr's meta-tool

With west merged in does that mean we can no longer use the cmake/ninja
debug type of flow (I'm seeing a problem).
You can definitely continue to use the exact same workflow as before. If there's a problem please let us know via GitHub issue or on Slack.

If not, will the west setup instructions work on an existing working
directory or do we have to start from scratch?
This is thoroughly documented in the new Getting Started guide:

https://docs.zephyrproject.org/latest/getting_started/getting_started.html#get-the-source-code

You can use "west init -l" to initialize an existing copy of zephyr.

Carles


Re: Introducing west, Zephyr's meta-tool

David Leach
 

With west merged in does that mean we can no longer use the cmake/ninja debug type of flow (I'm seeing a problem).

If not, will the west setup instructions work on an existing working directory or do we have to start from scratch?

David

-----Original Message-----
From: users@lists.zephyrproject.org <users@lists.zephyrproject.org> On Behalf Of Cufi, Carles
Sent: Monday, January 28, 2019 2:43 AM
To: zephyr-devel <zephyr-devel@lists.zephyrproject.org>; zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-users] Introducing west, Zephyr's meta-tool

Hi all,

For a few months now we have been working on a meta-tool named west, designed to act both as a command-line tool to build, flash an debug Zephyr-based applications and also to manage the additional Git repositories that Zephyr will require in order to build in the near future.

West is written in Python 3, lives in its own repository [1] and its bootstrapper is available on PyPi [2].
As soon as we merge the topic-west [3] branch into master (which should happen in the next few days) you will need to install west in order to flash and debug, since those commands will rely on havig west present as part of your Zephyr workflow.

The updated west documentation will be online in the Zephyr documentation website [4] as soon as the topic-west branch is merged into master. In the meantime you can also look at the unrendered documentation sources in the topic-west branch [5] and the existing GitHub issues [6][7].

In order to install the west boostrapper (which you can do today) run:

# On Linux
pip3 install --user west

# On macOS and Windows
pip3 install west

Once the west bootstrapper is installed and the topic-west branch is merged into master, you will have 2 choices to get a west main installation.

1. Clone a new copy of the zephyr repository using west:

west init zephyrproject
cd zephyrproject
west update

2. Install west around an existing local zephyr clone:

Move the cloned zephyr/ repository to an empty enclosing folder (for example zephyrproject/zephyr/), and from this enclosing folder zephyrproject/ run:

west init -l zephyr/
west update
The -l <path to zephyr> parameter instructs west to use an existing local copy instead of cloning a remote repository.

Feedback and patches are welcome, but note that the feature will likely be merged as-is since we consider we have left ample time to raise any major issues regarding the workflow and decisions taken during the development of west. This is however only the beginning of west's (hopefully) long existence as the Zephyr command-line meta-tool, and it will certainly evolve and change considerably in the future with the help of the community.

Please submit feedback in the form of GitHub issues on the west repository itself [1] unless it affects features or functionality in the zephyr repository directly.

I will reply to this email once the topic-west branch is merged into master.

Thank you to everybody who has contributed so far!

Regards,

Carles

[1] https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fwest&;data=02%7C01%7Cdavid.leach%40nxp.com%7C00f0e35b58e5451e970a08d684fc9d2c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636842617832104319&amp;sdata=D9DzUmRQzSsMQmTimO24LdS%2BPSOUotSj5jDBHlNq6yU%3D&amp;reserved=0
[2] https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpypi.org%2Fproject%2Fwest%2F&;data=02%7C01%7Cdavid.leach%40nxp.com%7C00f0e35b58e5451e970a08d684fc9d2c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636842617832104319&amp;sdata=xC6UxiHQrdilDEvOsFpjDkcSH6dVDBxzb3zyxz%2ByJHA%3D&amp;reserved=0
[3] https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Ftree%2Ftopic-west&;data=02%7C01%7Cdavid.leach%40nxp.com%7C00f0e35b58e5451e970a08d684fc9d2c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636842617832104319&amp;sdata=Le7FGSNWn1eiOtmcwInOdN0N3vy202JxRERjm5NTHIA%3D&amp;reserved=0
[4] https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zephyrproject.org%2Flatest%2Ftools%2Fwest%2Findex.html&;data=02%7C01%7Cdavid.leach%40nxp.com%7C00f0e35b58e5451e970a08d684fc9d2c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636842617832104319&amp;sdata=rPWN%2BcApijJTO68eVfnWNnh1bnSqlR%2FJy9sH8OePbhk%3D&amp;reserved=0
[5] https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Ftree%2Ftopic-west%2Fdoc%2Ftools%2Fwest&;data=02%7C01%7Cdavid.leach%40nxp.com%7C00f0e35b58e5451e970a08d684fc9d2c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636842617832104319&amp;sdata=cvzXhr5Qc0ahoZcmPMrCaLW5ryNQFZb1lYlCgQ84iBo%3D&amp;reserved=0
[6] https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fissues%2F6205&;data=02%7C01%7Cdavid.leach%40nxp.com%7C00f0e35b58e5451e970a08d684fc9d2c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636842617832104319&amp;sdata=qNvTwQBdGyxeqPUpmML8CrgVhXa%2FNxE70iibPYmsVOY%3D&amp;reserved=0
[7] https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fissues%2F6770&;data=02%7C01%7Cdavid.leach%40nxp.com%7C00f0e35b58e5451e970a08d684fc9d2c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636842617832104319&amp;sdata=H2w8phH%2FM0h3kEds9stm%2FyQU8BvVbNi8g4i795Z3cxg%3D&amp;reserved=0


Re: 1-Wire driver for nRF52

Marti Bolivar <marti@...>
 

Hi Sven,
On Mon, Feb 4, 2019 at 1:16 PM Sven Schwermer <sven@svenschwermer.de> wrote:

Hi!

I have written a bitbanged 1-wire driver for the nRF52 to interface with
DS18B20 sensors. Since it seems to be impossible to read back from a
pulled up open-drain driver without clearing the DIR register on the
nRF52, I have timing issues, because gpio_pin_configure just takes too
much time.

Putting device-specific hardware accesses into the driver solves the
issue but completely defeats the purpose of a platform-agnostic driver.
I also can't just write a nRF-specific backend, since the GPIO hardware
is managed by the actual nRF GPIO driver and the lower level functions
in said driver are not meant to be called (static, no public declarations).

How does one write timing critical bitbanged drivers in Zephyr?
There is an open issue:

https://github.com/zephyrproject-rtos/zephyr/issues/11917

Please feel free to review and provide feedback.


Any pointers are welcome :-)

Best regards,
Sven
Best,
Marti





1-Wire driver for nRF52

Sven Schwermer <sven@...>
 

Hi!

I have written a bitbanged 1-wire driver for the nRF52 to interface with
DS18B20 sensors. Since it seems to be impossible to read back from a
pulled up open-drain driver without clearing the DIR register on the
nRF52, I have timing issues, because gpio_pin_configure just takes too
much time.

Putting device-specific hardware accesses into the driver solves the
issue but completely defeats the purpose of a platform-agnostic driver.
I also can't just write a nRF-specific backend, since the GPIO hardware
is managed by the actual nRF GPIO driver and the lower level functions
in said driver are not meant to be called (static, no public declarations).

How does one write timing critical bitbanged drivers in Zephyr?

Any pointers are welcome :-)

Best regards,
Sven


Re: Patches to implement DMA for STM32F4 SPI.

Paul Sokolovsky
 

Hello Dave,

On Mon, 4 Feb 2019 13:31:12 +0000
"Dave Marples" <dave@marples.net> wrote:

Folks,

I'm new around here so please bear with me and nudge me in the right
direction if I get things wrong.

I have just submitted Pull Request 13031 which implements DMA mode on
the STM32F4 series (specifically tested on the STM32F427ZI). This
note is by way of providing a bit more background on it since the
PullReq itself probably isn't the place for it.
Thanks for this post. The best suggestion I however would have is to
look it up in the mailing list archive and link from the Github pull
request.

The rule of thumb we follow is that technical matters are discussed in
PRs. If discussion goes beyond mid-level technical matters, e.g. to
organizational matters, or to technical changes which may affect many
Zephyr users, an authors of proposed changes is encouraged to submit an
RFC to the mailing list to get wider coverage.

Of course, everyone if welcome to post to the mailing list to draw
attention to a particular matter.

Hope those were useful hints, and hope other folks will comment on
technical matters (but again, better if all of that is in/reachable
from the PR).

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Code Freeze for 1.14 on Friday Feb 1st

Paul Sokolovsky
 

Hello Kumar,

On Tue, 29 Jan 2019 19:32:08 -0600
"Kumar Gala" <kumar.gala@linaro.org> wrote:

All,

Just wanted to remind everyone that the code freeze for 1.14 will be
this Friday. Please tag any PR as with 1.14 milestone that you feel
should try and get merged as part of 1.14.
So, did the freeze officially happen on last Friday? What next steps
can we expect?


Thanks

- k
[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Patches to implement DMA for STM32F4 SPI.

Dave Marples
 

Folks,

I'm new around here so please bear with me and nudge me in the right direction if I get things wrong.

I have just submitted Pull Request 13031 which implements DMA mode on the STM32F4 series (specifically tested on the STM32F427ZI). This note is by way of providing a bit more background on it since the PullReq itself probably isn't the place for it.

My use case is a pin going low which triggers the exchange of 24 octets of data which happen to originate from an ADC. This occurs at 100uS intervals. My CPU is running from flash at 160MHz, with 8 bit SPI running at 10MHz. The actual 'busy time' exchanging these data should be 19.2uS.

I initially tried Interrupt mode. The 100uS deadline was frequently exceeded and the intervals _between_ each octet exchange were longer than each octet exchange itself! A typical 24-octet exchange took 116uS from the pin request to the pin going inactive again at the end of the request.  This is shown at https://drive.google.com/file/d/1m20klSrnFNzHa7W3f3j03g4-1PaoB6Dk (Yellow trace is the requesting pin, green is the SPI clock. The high pulse after 100uS is the next data request coming in).

Programmed IO mode is better, reducing the time required to 93uS ( At https://drive.google.com/file/d/1IH15dD1WMq0hX5KvmDU0qm9o8ardhoaJ ) but the CPU is busy and I don't get any time to do anything with the samples after they've arrived.

I therefore added DMA mode to the driver and the result is visible at https://drive.google.com/file/d/1KiroWn1kfyrg1gnOl7xfAeVmwFkq5M8j . The actual data transfer now takes the calculated minimum of 19.2uS and the overall transaction time is reduced to 69uS.

It can be seen in that last scope picture that the setup latency is really starting to hurt in this scenario so I've gone slightly further.  I have added a new operation flag in spi.h called SPI_DEFER_TRANSFER. When a spi transfer is set up it will do everything as normal apart from actually enabling the SPI device itself....effectively the transfer hangs in a pending state. When the trigger arrives then a new API called spi_trigger is called, which actually enables the SPI device (and thus the transfer to complete). Since this doesn't use any APIs other other routines the intention is that it should be safe to call from a direct interrupt and it should work irrespective of if you're using ProgrammedIO, Interrupt or DMA mode.  When called from a conventional GPIO interrupt, the result using DMA is shown at https://drive.google.com/file/d/1gxxBnc4MZEWD5YouEQ0NHh1wBH5bVMIT ... basically, a reduction in SPI startup latency from 32uS to 3.5uS, and a reduction in overall SPI transaction time from 69uS to 35uS for this 24 octet packet (it should reduce considerably further when I move to a direct interrupt for the GPIO).

I'd appreciate it if folks can take a look at these patches and give (constructive?) feedback. For me the RT is the important bit in this RTos :-)

Regards

DAVE


Re: BLE encryption : Which AES 128 decryptor to be used?

frv
 

Hi Johan,

Indeed when using the Big Endian I'm getting the same result. I was mislead as I thought I had to use the little endian as my BLE central applic that needs to decode runs on a BBB, that is little endian. 

Anyhow, problem solved, moving to the next one :).

Thanks,
Best regards,
Frank


Re: BLE Advertising raw data via scan response - bt_le_adv_start

frv
 

Hi Johan,

Thanks, yup, I succeeded  just before reading your answer.
Indeed I wrongly set my array size, and that after 25 years of 'professional' programming, shame on me... :(.

Anyhow, I'm getting pretty close to where I want to be.
Setting up an automatic "secure/authorized" pairing system succeeds pretty well, I just had to add "some" customized code to the current QT BLE implementation... :)
 :
I'm just missing the NFC implementation in Zephyr but that is no longer required for OOB pairing but for putting the secret AES key into the BLE peripheral during the commissioning.

I will come back to the Zephyr forum with some questions about authentication and encryption permissions on the characteristics of services in BLE Zephyr. 
It seems when I connect via my  QT BLE central application without secure connection with the Zephyr HR peripheral demo applic and without pairing I can always readout the characteristics (of my heart rate service) despite having authorization and security flags set.
But I will open a new topic on this later... 

Thanks once more for your response, much appreciated.

Best regards,
Frank


Re: BLE encryption : Which AES 128 decryptor to be used?

Johan Hedberg
 

Hi Frank,

On 31 Jan 2019, at 16.20, frv <F.Vieren@televic.com> wrote:

I also see that the encrypted data done with both functions: bt_encrypt_le and AES_ECB_encrypt are not the same.
...
Any idea?
The “_le” in bt_encrypt_le stands for “little endian”. Most Bluetooth protocols are little endian, which is why this convenience API exists. Generic crypto APIs OTOH are usually big endian, which might be why you’re getting different results. Try to byte-swap before and after, or use bt_encrypt_be() and my guess would be that you get the same results.

Johan

2261 - 2280 of 7924