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:
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.
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.
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 SETEC Pty Ltd
Email from setec.com.au does not necessarily represent
the official policy of SETEC Pty Ltd.
|
|
Re: warning: TEST_RANDOM_GENERATOR
alberto.piedras@...
Hi,
toggle quoted messageShow quoted text
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: D'oh, I stand corrected. Now I remember it, Bluetooth simulation support, right?Regarding "predictable random number generator", that's interestingThat's the native posix one ;) [] -- 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: D'oh, I stand corrected. Now I remember it, Bluetooth simulationRegarding "predictable random number generator", that's interestingThat's the native posix one ;) 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
|
|
Re: warning: TEST_RANDOM_GENERATOR
Paul Sokolovsky
Hello Andrei,
On Tue, 29 Jan 2019 13:35:19 +0000 "Andrei Gansari" <andrei.gansari@...> wrote: Hello everyone,We want to have a "random generator" device be present in Zephyr setup, which various subsystems then can use (instead of failing). So, TEST_RANDOM_GENERATOR is a fallback choice which is always available. For example, it's available in qemu_* boards, which otherwise don't have a "real" randomgen. That's why you see TEST_RANDOM_GENERATOR in many networking samples - the only way to make networking samples accessing to *anyone* is to make sure they run with qemu networking. 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. If we want[] -- 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
|
|
warning: TEST_RANDOM_GENERATOR
Andrei Gansari
Hello everyone,
I have a question regarding TEST_RANDOM_GENERATOR. When building networking samples for boards with entropy devices is get the warning: warning: TEST_RANDOM_GENERATOR (defined at subsys/random/Kconfig:8) was assigned the value 'y' but got the value 'n'.
We find in subsys/random/Kconfig TEST_RANDOM_GENERATOR depends on !ENTROPY_HAS_DRIVER ENTROPY_DEVICE_RANDOM_GENERATOR depends on ENTROPY_HAS_DRIVER
Most networking samples have set TEST_RANDOM_GENERATOR=y and as I understand it's for pseudo-random number generation. Boards that have entropy devices (ENTROPY_HAS_DRIVER) will disable TEST_RANDOM_GENERATOR.
When setting TEST_RANDOM_GENERATOR we just want a random generator or we want a predictable/intuitive random number generator? If we want both type of generators, then we could remove ENTROPY_HAS_DRIVER check on TEST_RANDOM_GENERATOR?
Is this an issue?
Andrei G.
|
|
More datails about HAL architecture
Francesco Franchina <cescus92@...>
Hello everyone!
I'm new to Zephyr and I'm considering to use it to build my next wearable project that will be based on the nRF5 SoC. Having studied a bit the architecture of features of the project it seems a pretty good choice to me but I still have a doubt that I could not solve reading the documentation and looking around in the web. I've read about the policy of adopting the HALs of different vendors but I didn't understand: 1) Are there some development policies that ensure that they will not interfere with my code? (e.g. do they mess with interrupts, registers or tasks?) 2) Do they behave consistently across all the supported board or I should expect some slightly different behaviors? Thanks in advance for your time! Francesco
|
|
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool
Carles Cufi
Hi Luiz,
toggle quoted messageShow quoted text
-----Original Message-----If by "attached" you mean that projects in the manifest are locked at a particular SHA, then that is exactly what we will do upstream (https://github.com/zephyrproject-rtos/zephyr/blob/master/west.yml#L37). That is not to say that some downstreams may choose to free float on the tip of a branch, but this is *not* going to be the case for upstream Zephyr. I will edit the body of the issue to make that clear. Regards, Carles
|
|
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool
Luiz Augusto von Dentz
Hi Carles,
On Tue, Jan 29, 2019 at 11:40 AM Cufi, Carles <Carles.Cufi@...> wrote: Well I didn't have to go as far since someone already commented similar thing: https://github.com/zephyrproject-rtos/zephyr/issues/6770#issuecomment-445496706 So attached vs detached approach, there seems to be quite many on the camp that we need to have the repositories attached while some considered the detached approach a must have. As individual contributor I think using the attached approach is a must, specially if one wants to actually run sanity checks which sometimes is necessary e.g. when you are actually writing a test case which depends on a feature from a different repository. I encourage you to read through the (admittedly quite long) list of comments there and continue the conversation. -- Luiz Augusto von Dentz
|
|
Re: Introducing west, Zephyr's meta-tool
Carles Cufi
Hi all,
toggle quoted messageShow quoted text
West is now merged to master. The documentation build has completed but the new set of documents have not yet been published to docs.zephyrproject.org. As soon as those are updated online (should take a few hours) you can refer to: https://docs.zephyrproject.org/latest/getting_started/getting_started.html and https://docs.zephyrproject.org/latest/tools/west/index.html for the west documentation. Thanks to everybody who has contributed or given feedback so far! Regards, Carles
-----Original Message-----
|
|
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool
Carles Cufi
Hi Jamie, Luiz,
toggle quoted messageShow quoted text
-----Original Message-----There are a number of reasons why we don't use Git submodules, all of which are described in the GitHub issue describing multi-repo: https://github.com/zephyrproject-rtos/zephyr/issues/6770 I encourage you to read through the (admittedly quite long) list of comments there and continue the conversation. Regards, Carles
|
|
USB audio
#nrf52840
marcus
Hi,
I am wondering about any plans regarding USB audio and isochronous endpoints. See github issue: https://github.com/zephyrproject-rtos/zephyr/issues/12775
|
|
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool
lairdjm
Hi Carles,
Note that we have not at any point considered moving away from GitHub. The plan is to adapt to what the service offers and try to find a solution that works well with it. This is also one of the reasons we are first introducing west without actually splitting the ext/ folder into multiple external repos: we want to expose users to west before we start doing more radical changes. Well good, though Im not sure what problem does west solves then? For https://public-inbox.org/git/338901fc-6dc8-2684-c116-393e603f85e9@suse.de/t/I agree with Luiz here, what does west provide that submodules doesn't provide? Why do I and others now need yet another piece of software to build Zephyr code (python)? Thanks, Jamie
|
|
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool
Luiz Augusto von Dentz
Hi Carles,
On Mon, Jan 28, 2019 at 10:54 PM Cufi, Carles <Carles.Cufi@...> wrote: From these alternatives I only see 4 really working in practice, but it is limited to repositories being in github in which case the PR requests can perhaps be generated from a single clone and github could then forward to each individual project but still tracking on the original. For other options even if west learn how to properly separate each PR the user still needs its own repository for each of those if they are hosted in github which would have to be tracked individually, or in case it is not hosted in github it may have to deal with mailing list, gerrit, etc. Note that we have not at any point considered moving away from GitHub. The plan is to adapt to what the service offers and try to find a solution that works well with it. This is also one of the reasons we are first introducing west without actually splitting the ext/ folder into multiple external repos: we want to expose users to west before we start doing more radical changes.Well good, though Im not sure what problem does west solves then? For pulling it sounds like submodules is the preferable solution (to linux folks at least): https://public-inbox.org/git/338901fc-6dc8-2684-c116-393e603f85e9@suse.de/t/ Ideas and feedback welcome! -- Luiz Augusto von Dentz
|
|
Re: USB ECM buffer size
Andrei
Hi Nicolas,
On Mon, Jan 28, 2019 at 04:54:12PM +0100, nicolas lantz wrote: Hi,Could you make a proper commit and send Pull Request on github? Best regards Andrei Emeltchenko
|
|
Andrew Gu
Hi, I am making a program in a slave (peripheral) device. I can get a master (central) device connect to the slave (peripheral) device. But, how can I make the slave device to get the device name of the master device after the connection is on? I tried to use bt_gatt_read, but did not have any luck. My code is below. Can anyone help? Thanks in advance.
struct bt_conn *default_conn = NULL; struct bt_gatt_read_params conn_param;
char devname[64];
u8_t conn_param_read_cb(struct bt_conn *conn, u8_t err, struct bt_gatt_read_params *params, const void *data, u16_t length) {
if (err) return 0;
memset(devname, 0, 64);
memcpy(devname, data, length);
return 0;
}
void connected(struct bt_conn *conn, u8_t err) {
if (err) return;
default_conn = bt_conn_ref(conn);
conn_param.func = conn_param_read_cb; conn_param.handle_count = 1;
conn_param.single.handle = sys_le16_to_cpu(0x2a00); //BT_UUID_GAP_DEVICE_NAME
conn_param.single.offset = 0;
bt_gatt_read(conn, &conn_param);
return;
}
|
|
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool
Carles Cufi
Hi Luiz,
toggle quoted messageShow quoted text
-----Original Message-----You can see that dealing with Pull Requests is listed as an unresolved issue in the description here: https://github.com/zephyrproject-rtos/zephyr/issues/6770 There are several possibilities to deal with this, but first and since that you mention Google repo let me make an important distinction. With repo you typically (though not always) track the tip of master on multiple repositories. With west, although that is also possible, we will require specific SHAs for all repos (projects) that are not the main zephyr repo (i.e. the manifest repo). Options we have (informally, in calls and chats) considered: 1. Send 2 PRs to the 2 repos affected (say for example zephyr + mbedtls), where the branch name used matches. Then CI running in zephyr could look at all repositories listed in the manifest and check if an outstanding PR for it exists with the same GitHub username and branch name. 2. Send the PR to the external project (mbedtls in our example) and another PR to zephyr with the manifest modified so that it points to the fork and branch name of the project's PR. When those are merged, CI could then replace the contents of the manifest with the proper SHA. 3. Introduce some sort of per-PR ChangeId that CI knows how to parse. 4. GitHub adds support for cross-repository PRs. There have been multiple hints that this is coming, but obviously we cannot know when, if ever, this feature will be available. Note that we have not at any point considered moving away from GitHub. The plan is to adapt to what the service offers and try to find a solution that works well with it. This is also one of the reasons we are first introducing west without actually splitting the ext/ folder into multiple external repos: we want to expose users to west before we start doing more radical changes. Ideas and feedback welcome! Thanks, Carles
|
|
Re: [Zephyr-users] Introducing west, Zephyr's meta-tool
Luiz Augusto von Dentz
Hi Carles,
toggle quoted messageShow quoted text
How about pull request, how does west deals with them? Or it doesn't and which case we have to deal with individual git repositories and issue git push ourselves? This looks like repo which I never liked.
On Mon, Jan 28, 2019 at 10:43 AM Cufi, Carles <carles.cufi@...> wrote:
--
Luiz Augusto von Dentz
|
|