Date   

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@... <users@...> On Behalf Of Cufi, Carles
Sent: Monday, January 28, 2019 2:43 AM
To: zephyr-devel <zephyr-devel@...>; zephyr-users@...
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&amp;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&amp;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&amp;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&amp;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&amp;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&amp;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&amp;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 <@svenschwermer> 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@...> 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@...> 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 <@frv> 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


Re: BLE Advertising raw data via scan response - bt_le_adv_start

Johan Hedberg
 

Hi Frank,


On 31 Jan 2019, at 13.08, frv <@frv> wrote:
struct bt_data bd1[0];
That’s a zero-length array, i.e. it’s not allocating any memory for the variable. Consequently, trying to read or write bd1[0] will cause unexpected behaviour. Other than that I didn’t see anything wrong with your code. Note that using BT_LE_ADV_CONN_NAME (instead of e.g. BT_LE_ADV_CONN) will cause the stack to try to insert the device name in the scan response data, so you won’t get exactly what you’re asking for but something extra as well.

Johan


BLE encryption : Which AES 128 decryptor to be used?

frv
 

Hi,


If I want to use "bt_encrypt_le", what should be the specification to find the right AES decryptor?


I thought I could use the AES_ECB_decrypt from the tiny-AES-C library see : https://github.com/bricke/tiny-AES-C

github.com
Tiny AES in C. This is a small and portable implementation of the AES ECB and CBC encryption algorithms written in C. The API is very simple and looks like this (I am using C99 <stdint.h>-style annotated types):

But without success so far.


I also see that the encrypted data done with both functions: bt_encrypt_le and  AES_ECB_encrypt are not the same.


Nevertheless I can use tiny-AES-C on Zephyr. Just wondering why both are not compatible.



u8_t enc_data[16];
        u8_t key[]       = { 0x01, 0x02, 0x03, 0x04, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7 };
        u8_t plaintext[] = { 0x01, 0x02, 0x03, 0x04, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 };

        AES_ECB_encrypt(plaintext, key, enc_data, 16);
        printk("encrypted text = %x %x %x %x %x\n", enc_data[0], enc_data[1], enc_data[2], enc_data[3], enc_data[4]);

        if (bt_encrypt_le(key, plaintext, enc_data) != 0)
        {
           printk("Encryption failed for passkey");
        }
        else
        {
           printk("encrypted text = %x %x %x %x %x\n", enc_data[0], enc_data[1], enc_data[2], enc_data[3],                                                                                            enc_data[4]);
        }


Any idea?


Thanks in advance,

Best regards,

Frank


Re: NFC support Zephyr voor LE OOB secured pairing...

frv
 

Hi Joakim,

Thanks for your feedback on the topic.

Indeed currently I'm using "passkey authorization" during the pairing process. Although I don't have a keyboard or display on my BLE devices I have created an "automated pairing" process based on passkey verification.

On my Zephyr board acting as BLE peripheral I set a random generated passkey (6 digits).

static void auth_passkey_entry(struct bt_conn *conn, unsigned int passkey)
{       
        bt_passkey_set(random_key);
}

This passkey will be transmitted encrypted by AES 128 via the BLE advertisement. Only a BLE central device having the same private  AES key will be able to decrypt it.

On my BLE central I'm running a BLE QT application that manages to set the passkey automatically without user interaction. When the BLE central tries to pair with the BLE peripheral (Zephyr), the BLE central application injects automatically the passkey (BlueZ Dbus API) when asked.  

So I just need the NFC process on the Zephyr board for receiving the private AES key during the commissioning phase. 

Best regards,
Frank


BLE Advertising raw data via scan response - bt_le_adv_start

frv
 

Hi,


I don't know what I'm doing wrong when trying to advertise raw data via the scan_response function parameter in bt_le_adv_start, probably overlooking something stupid, but I don't get this to work at least if I try to use the bd1 as parameter in the "bt_le_adv_start" function :



       struct bt_data bd[] = { BT_DATA_BYTES(0x00, 0x22, 0x0a, 0x01, 0x02, 0x03, 0x0a, 0x33), };

        u8_t bdData[] = {0x22, 0x0a, 0x01, 0x02, 0x03, 0x0a, 0x33};

        struct bt_data bd1[0];
        bd1[0].type = 0x0;
        bd1[0].data = bdData;
        bd1[0].data_len = sizeof(bdData);

        printk("size of data = %d\n", sizeof(bdData));
        //printk("data = %s\n length = %d", bd[0].data, bd[0].data_len);

        err = bt_le_adv_start(BT_LE_ADV_CONN_NAME, ad, ARRAY_SIZE(ad), bd, ARRAY_SIZE(bd));
        if (err) {
                printk("Advertising failed to start (err %d)\n", err);
                return;
        }

However it works when constructing the data via BT_DATA_BYTES thus via  using the bd data variable (see first line of coding) ...

Any idea what I'm doing wrong?

Thanks in advance,
Best regards,
Frank



Build improperly does a partial discard of 'const' defined variables

David Leach
 

I have run across a build problem that appears to impact Arm platforms. The problem involves improper discarding of ‘const’ defined variables that are only referenced within a single file getting partially optimized out by the final linker stage. The map file shows the symbol in the Discard section but there is code still referencing that variable so the result is that the variable is located at address 0… all const variables that have this problem are located at address zero because the final linker stage didn’t fixup the address with a proper location.

 

This problem can be seen in the ‘hello world’ sample by looking at what the linker does with _main_thread defined in init.c. The map file shows it as a discarded symbol but it is still in the elf file and you can inspect it with gdb and see that it is at address 0.

 

The final link stage links some of the libraries using the –whole-archive flag and some of the others using the –no-whole-archive flag so as an experiment I linked all libraries using just the whole-archive flag and it appeared to properly place the const variable.

 

Also note that this doesn’t seem to be a problem when building for x86 targets.

 

I added a bug report on this: https://github.com/zephyrproject-rtos/zephyr/issues/12905

 

 

David Leach

 

NXP Semiconductors

phone: +1.210.241.6761

Email: david.leach@...

 

 

** PROPRIETARY & COMPANY-CONFIDENTIAL **

 


Increasing minimum Zephyr Python version?

Marti Bolivar <marti@...>
 

Hi everyone,

I recently saw this while running test cases for west in Shippable:

DEPRECATION: Python 3.4 support has been deprecated. pip 19.1 will be
the last one supporting it. Please upgrade your Python as Python 3.4
won't be maintained after March 2019

At what point do we think we might want to move up to at least 3.5?
Are there any developers of Python code in the Zephyr tree who feel
hamstrung by limitations in Python 3.4?

Thanks,
Marti


https://scan.coverity.com/ is back online in read-only mode

Nashif, Anas
 

Hi,

 

The service is back in read-only mode. If you have any issues assigned to you, please take the chance to look at the details of the issue and fix as soon as possible.

List of the open coverity issues is available here:

 

https://github.com/zephyrproject-rtos/zephyr/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3ACoverity

 

 

 

Thanks,

Anas

 

 

 


Zephyr/BLE stack: Problem pairing/bonding more than one device, whilst the first device is still connected.

Declan Traill <declan.traill@...>
 

Hi Zephyr group,

 

    We have found on our Zephyr system that the first device (Android or iOS) pairs/bonds with not problems, but a second (or third etc) device fails to pair/bond most of the time.
Sometimes it works ok & both devices become paired/bonded and stay connected, but most of the time it fails and the second device is disconnected as soon as the pairing key has been entered on the device.

Here is some debug output for when the pairing/bonding of the first device works, and then when it fails for the second device:

 

WHEN IT WORKS (FOR THE FIRST DEVICE):

 

[ble_p] [INF] ble_p_connected: 1/4, 00:00:46:00:00:01 (public) is NOT bonded

passkey display 520717

[] [INF] rvmn_ui_bt_auth_pairing_complete: 00:00:46:00:00:01 (public), bonded:1

[] [ERR] rvmn_ui_bt_auth_pairing_complete: not bonded

 

 

WHEN IT DOESN’T WORK (FOR THE SECOND DEVICE):

 

ble_p] [INF] ble_p_connected: 2/4, d4:61:9d:ee:41:53 (public) is NOT bonded

passkey display 183049

[ble_p] [INF] ble_p_disconnected: 2/4, d4:61:9d:ee:41:53 (public) is NOT bonded

[ble_p] [ERR] ble_p_disconnected: 1/4, d4:61:9d:ee:41:53 (public) NOT

[ble_p] [DBG] ble_p_disconnected: d4:61:9d:ee:41:53 (public), reason 0x08: BT_HCI_ERR_CONN_TIMEOUT

 

 

 

I investigated the cause of the disconnection in the Zephyr BLE stack, and found it to be caused by trx_done  not being TRUE when the isr() function is called (in ctrl.c) whilst in STATE_RX  _radio.state:

 

The trx_done is set based on the value of NRF_RADIO->EVENTS_END.

It seems that when the second device tries to pair, we get a BLE isr() occur whilst in STATE_RX, but NRF_RADIO->EVENTS_END is not set.
Thus it appears to not have completed a Tx/Rx in the Radio?

Why is this happening, and is there some configuration/setting we can change to fix this, or is it a Zephyr BLE stack bug?

 

 

 

Here is the code:

 

 

u32_t radio_is_done(void)

{

       if (NRF_RADIO->EVENTS_END != 0) {

              /* On packet END event increment last packet end time value.

              * Note: this depends on the function being called exactly once

              * in the ISR function.

              */

              last_pdu_end_us += EVENT_TIMER->CC[2];

              return 1;

       } else {

              return 0;

       }

}

 

#else /* !CONFIG_BT_CTLR_SW_SWITCH_SINGLE_TIMER */

u32_t radio_is_done(void)

{

       return (NRF_RADIO->EVENTS_END != 0);

}

#endif /* !CONFIG_BT_CTLR_SW_SWITCH_SINGLE_TIMER */

 

 

 

static void isr(void)

{

       u8_t trx_done;

       u8_t crc_ok;

       u8_t devmatch_ok;

       u8_t devmatch_id;

       u8_t irkmatch_ok;

       u8_t irkmatch_id;

       u8_t rssi_ready;

 

       DEBUG_RADIO_ISR(1);

 

       /* Read radio status and events */

       trx_done = radio_is_done();

       if (trx_done) {

 

#if defined(CONFIG_BT_CTLR_PROFILE_ISR)

              /* sample the packet timer here, use it to calculate ISR latency

              * and generate the profiling event at the end of the ISR.

              */

              radio_tmr_sample();

#endif /* CONFIG_BT_CTLR_PROFILE_ISR */

 

              crc_ok = radio_crc_is_valid();

              devmatch_ok = radio_filter_has_match();

              devmatch_id = radio_filter_match_get();

              irkmatch_ok = radio_ar_has_match();

              irkmatch_id = radio_ar_match_get();

              rssi_ready = radio_rssi_is_ready();

       } else {

              crc_ok = devmatch_ok = irkmatch_ok = rssi_ready = 0;

              devmatch_id = irkmatch_id = 0xFF;

       }

 

       /* Clear radio status and events */

       radio_status_reset();

       radio_tmr_status_reset();

       radio_filter_status_reset();

       radio_ar_status_reset();

       radio_rssi_status_reset();

 

#if defined(CONFIG_BT_CTLR_GPIO_PA_PIN) || \

    defined(CONFIG_BT_CTLR_GPIO_LNA_PIN)

       radio_gpio_pa_lna_disable();

#endif /* CONFIG_BT_CTLR_GPIO_PA_PIN || CONFIG_BT_CTLR_GPIO_LNA_PIN */

 

       switch (_radio.state) {

       case STATE_TX:

              isr_radio_state_tx();

              break;

 

       case STATE_RX:

              isr_radio_state_rx(trx_done, crc_ok, devmatch_ok, devmatch_id,

                              irkmatch_ok, irkmatch_id, rssi_ready);

              break;

 

       case STATE_ABORT:

       case STATE_STOP:

       case STATE_CLOSE:

              isr_radio_state_close();

              break;

 

       case STATE_NONE:

              /* Ignore Duplicate Radio Disabled IRQ due to forced stop

              * using Radio Disable task.

              */

              break;

 

       default:

              LL_ASSERT(0);

              break;

       }

 

       DEBUG_RADIO_ISR(0);

}

 

 

At the start of the function isr_radio_state_rx, trx_done is tested, and if not true, _radio.state is set to STATE_CLOSE, then the connection is closed

 

static inline void isr_radio_state_rx(u8_t trx_done, u8_t crc_ok,

                                 u8_t devmatch_ok, u8_t devmatch_id,

                                 u8_t irkmatch_ok, u8_t irkmatch_id,

                                 u8_t rssi_ready)

{

       u32_t err;

       u8_t  rl_idx;

 

       if (!((trx_done) || ((SILENT_CONNECTION) &&

                          (_radio.role == ROLE_SLAVE)))) {

              _radio.state = STATE_CLOSE;

              radio_disable();

 

              return;

       }

 

 

 

static inline void isr_radio_state_close(void)

{

       u32_t dont_close = 0;

 

       switch (_radio.role) {

       case ROLE_ADV:

              dont_close = isr_close_adv();

              break;

 

       case ROLE_SCAN:

              dont_close = isr_close_scan();

              break;

 

       case ROLE_SLAVE:

       case ROLE_MASTER:

              isr_close_conn();

              break;

 

 

This is the function called from code above, resulting in the connection being closed with a BT_HCI_ERR_CONN_TIMEOUT

 

static inline void isr_close_conn(void)

{

       u16_t ticks_drift_plus;

       u16_t ticks_drift_minus;

       u16_t latency_event;

       u16_t elapsed_event;

       u8_t reason_peer;

       u16_t lazy;

       u8_t force;

 

       /* Local initiated terminate happened */

       if (_radio.conn_curr == 0) {

              return;

       }

 

       /* Master transmitted ack for the received terminate ind or

       * Slave received terminate ind.

       */

       reason_peer = _radio.conn_curr->llcp_terminate.reason_peer;

       if (reason_peer && ((_radio.role == ROLE_SLAVE) ||

                         _radio.conn_curr->master.terminate_ack)) {

              terminate_ind_rx_enqueue(_radio.conn_curr, reason_peer);

 

              connection_release(_radio.conn_curr);

              _radio.conn_curr = NULL;

 

              return;

       }

 

       ticks_drift_plus = 0;

       ticks_drift_minus = 0;

       latency_event = _radio.conn_curr->latency_event;

       elapsed_event = latency_event + 1;

 

       /* calculate drift if anchor point sync-ed */

       if (_radio.packet_counter &&

           (!SILENT_CONNECTION || (_radio.packet_counter != 0xFF))) {

              if (_radio.role == ROLE_SLAVE) {

                     u32_t start_to_address_expected_us;

                     u32_t start_to_address_actual_us;

                     u32_t window_widening_event_us;

                     u32_t preamble_to_addr_us;

 

                     /* calculate the drift in ticks */

                     start_to_address_actual_us = radio_tmr_aa_restore() -

                                              radio_tmr_ready_get();

                     window_widening_event_us =

                           _radio.conn_curr->slave.window_widening_event_us;

#if defined(CONFIG_BT_CTLR_PHY)

                     preamble_to_addr_us =

                           addr_us_get(_radio.conn_curr->phy_rx);

#else /* !CONFIG_BT_CTLR_PHY */

                     preamble_to_addr_us = addr_us_get(0);

#endif /* !CONFIG_BT_CTLR_PHY */

                     start_to_address_expected_us = RADIO_TICKER_JITTER_US +

                           (RADIO_TICKER_JITTER_US << 1) +

                           preamble_to_addr_us +

                           window_widening_event_us;

                     if (start_to_address_actual_us <=

                         start_to_address_expected_us) {

                           ticks_drift_plus = HAL_TICKER_US_TO_TICKS(

                                  window_widening_event_us);

                           ticks_drift_minus = HAL_TICKER_US_TO_TICKS(

                                  (start_to_address_expected_us -

                                  start_to_address_actual_us));

                     } else {

                           ticks_drift_plus = HAL_TICKER_US_TO_TICKS(

                                  start_to_address_actual_us);

                           ticks_drift_minus = HAL_TICKER_US_TO_TICKS(

                                  RADIO_TICKER_JITTER_US +

                                  (RADIO_TICKER_JITTER_US << 1) +

                                  preamble_to_addr_us);

                     }

 

                     /* Reset window widening, as anchor point sync-ed */

                     _radio.conn_curr->slave.window_widening_event_us = 0;

                     _radio.conn_curr->slave.window_size_event_us = 0;

 

                     /* apply latency if no more data */

                     if (_radio.conn_curr->pkt_tx_head) {

                           struct pdu_data *pdu_data_tx;

 

                           pdu_data_tx = (void *)

                                  _radio.conn_curr->pkt_tx_head->pdu_data;

                           if (pdu_data_tx->len ||

                               _radio.conn_curr->packet_tx_head_offset) {

                                  _radio.conn_curr->latency_event = 0;

                           }

                     } else if (_radio.conn_curr->slave.latency_enabled) {

                           _radio.conn_curr->latency_event =

                                  _radio.conn_curr->latency;

                     }

              } else if (reason_peer) {

                     _radio.conn_curr->master.terminate_ack = 1;

              }

 

              /* Reset connection failed to establish procedure */

              _radio.conn_curr->connect_expire = 0;

       }

 

       /* check connection failed to establish */

       else if (_radio.conn_curr->connect_expire) {

              if (_radio.conn_curr->connect_expire > elapsed_event) {

                     _radio.conn_curr->connect_expire -= elapsed_event;

              } else {

                     terminate_ind_rx_enqueue(_radio.conn_curr,

                                         BT_HCI_ERR_CONN_FAIL_TO_ESTAB);

 

                     connection_release(_radio.conn_curr);

                     _radio.conn_curr = NULL;

 

                     return;

              }

       }

 

       /* if anchor point not sync-ed, start supervision timeout, and break

       * latency if any.

       */

       else {

              /* Start supervision timeout, if not started already */

              if (!_radio.conn_curr->supervision_expire) {

                     _radio.conn_curr->supervision_expire =

                           _radio.conn_curr->supervision_reload;

              }

       }

 

       /* check supervision timeout */

       force = 0;

       if (_radio.conn_curr->supervision_expire) {

              if (_radio.conn_curr->supervision_expire > elapsed_event) {

                     _radio.conn_curr->supervision_expire -= elapsed_event;

 

                     /* break latency */

                     _radio.conn_curr->latency_event = 0;

 

                     /* Force both master and slave when close to

                     * supervision timeout.

                     */

                     if (_radio.conn_curr->supervision_expire <= 6) {

                           force = 1;

                     }

                     /* use randomness to force slave role when anchor

                     * points are being missed.

                     */

                     else if (_radio.role == ROLE_SLAVE) {

                           if (latency_event != 0) {

                                  force = 1;

                           } else {

                                  force = _radio.conn_curr->slave.force & 0x01;

 

                                  /* rotate force bits */

                                  _radio.conn_curr->slave.force >>= 1;

                                  if (force) {

                                         _radio.conn_curr->slave.force |=

                                                ((u32_t)1 << 31);

                                  }

                           }

                     }

              } else {

                     terminate_ind_rx_enqueue(_radio.conn_curr,

                                         BT_HCI_ERR_CONN_TIMEOUT);

 

                     connection_release(_radio.conn_curr);

                     _radio.conn_curr = NULL;

 

                     return;

              }

       }

 

   Thanks for any help you can provide…

 

Regards,

Declan Traill
Embedded Firmware Engineer
declan.traill@...

SETEC Pty Ltd
19 Henderson Road, Knoxfield 3180, Victoria, Australia
Phone: +61 3 9763 0962
Fax: +61 3 9763 8789
Direct: +61 3 9213 8458
setec.com.au | teambmpro.com

SETEC on Facebook     SETEC on Instagram     SETEC on LinkedIn     SETEC on YouTube
SETEC Celebrating 50 Years



Email from setec.com.au does not necessarily represent the official policy of SETEC Pty Ltd.
See Email Disclaimer 20060629 for details.



Re: warning: TEST_RANDOM_GENERATOR

alpi@...
 

Hi,
The native_posix board does not use the Bluetooth simulator.
Its random generator is deterministic, but can be seeded ( --seed=<random_seed>) to enable reproducible tests(*1).

The nrf52_bsim board (*2) does use the Bluetooth simulator (BabbleSim, a.k.a. bsim (*3)), and has another random generator (a model of the nRF5x RNG HW) which is also deterministic and can be seeded.

What these 2 Zephyr targets have in common is that both are based on the POSIX architecture. So the result of building targeting these boards is actually a native executable for the host computer, which the developer can run and debug like a normal Linux program.
Apart from this, the nrf52_bsim RADIO HW models, use the BabbleSim physical layer simulator to simulate the radio activity, and communicate with other simulated devices.

1 https://docs.zephyrproject.org/latest/boards/posix/native_posix/doc/board.html#peripherals
2 https://docs.zephyrproject.org/latest/boards/posix/nrf52_bsim/doc/board.html
3 https://babblesim.github.io

BR
Alberto

-----Original Message-----
From: Paul Sokolovsky [mailto:paul.sokolovsky@...]
Sent: Wednesday 30 January 2019 08:22
To: Alberto Escolar Piedras (ALPI) <ALPI@...>; devel@...
Subject: Re: [Zephyr-devel] warning: TEST_RANDOM_GENERATOR

Hello Alberto,

On Wed, 30 Jan 2019 07:15:41 +0000
"Alberto Escolar Piedras (ALPI)" <ALPI@...> wrote:

Regarding "predictable random number generator", that's interesting
idea for some kinds of testing, but I'm personally not aware of us
using such advanced and cunning test methods in Zephyr.
That's the native posix one ;)
D'oh, I stand corrected. Now I remember it, Bluetooth simulation support, right?

[]

--
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: warning: TEST_RANDOM_GENERATOR

Paul Sokolovsky
 

Hello Alberto,

On Wed, 30 Jan 2019 07:15:41 +0000
"Alberto Escolar Piedras (ALPI)" <ALPI@...> wrote:

Regarding "predictable random number generator", that's interesting
idea for some kinds of testing, but I'm personally not aware of us
using such advanced and cunning test methods in Zephyr.
That's the native posix one ;)
D'oh, I stand corrected. Now I remember it, Bluetooth simulation
support, right?

[]

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


Code Freeze for 1.14 on Friday Feb 1st

Kumar Gala
 

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.

Thanks

- k