[jira] [Commented] (MYNEWT-701) Low power timer support for nimble controller
[ https://issues.apache.org/jira/browse/MYNEWT-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15950022#comment-15950022 ] William San Filippo commented on MYNEWT-701: The basics: The nordic chips support two basic timers: RTC timers and non-RTC timers (which I will simply to refer to as timers hereafter). The RTC timers are lower power than timers so it desirable to use them instead of the other timers in the chip. The initial controller version used a timer set to count at 1MHz. This was done because it made the code quite simple to convert bluetooth timing to timer ticks (microseconds to ticks and ticks to microseconds was a no-op). The RTC timers only count at 32.768 kHz (well, I guess you could put a different crystal but typically 32.768 kHz crystals are used). Another change associated with the low power timer code is to turn on the HFXO (high-frequency crystal oscillator) only when needed. Actually, this gives you the largest current consumption gain as the difference between a RTC timer and timer is about 10uA and the HFXO is about 250 uA (if I am recalling the chip specification correctly). A note about the usecs to ticks conversion routine: The routine I decided to use is one where there is no need to do a divide. This is not perfectly accurate however and can be off by 1 full tick for certain values as the code does not add in the residual to correct for this. The routine takes about 10usecs on the nrf51 and if you add the residual it takes 16 usecs. This routine calculates a “floor” value, so if you care about the remainder you can either modify the routine to get that remainder or you can convert back to microseconds and subtract it from the microsecond value you converted into ticks. The controller does this for connection event timing as it needs to be more accurate than one 32.768 tick. After adding this code I have been debating having two different routines (one that is faster and one that is more exact) but for now there is only the one routine. And btw, the routine to do it exactly takes a long time on the nrf51 and based on how the controller was written there was not enough time to use the more exact routine (the controller needs to do things within the 150 usec IFS time). How to enable/disable: We decided to add the code in such a manner that the old way of doing things is still in the code. This allows the least amount of disruption while also allowing folks to give this code a spin. To enable the code you will need to do set the following syscfg variables. Note that you can do this in your target or BSP: 1) Set the crystal frequency to 32768. OS_CPUTIME_FREQ: 32768 2) Set the crystal setting time. This is going to be crystal/board dependent and is something you will have to characterize for your product. I need to do a bit more research to get the correct number to use for the nordic development kits. I chose 1500 usecs (1.5 msecs) as the default. This number cannot be zero! BLE_XTAL_SETTLE_TIME: 1500 3) Change the timer used for CPUTIME, disable the old timer and enable the RTC timer NRF52: OS_CPUTIME_TIMER_NUM: 5 TIMER_0: 0 TIMER_5: 1 NRF51: OS_CPUTIME_TIMER_NUM: 3 TIMER_0: 0 TIMER_3: 1 Here are some sample target excerpts: Sample nrf51 target: syscfg.vals: BLE_XTAL_SETTLE_TIME: 1500 OS_CPUTIME_FREQ: 32768 OS_CPUTIME_TIMER_NUM: 3 TIMER_0: 0 TIMER_3: 1 Sample nrf52 target: syscfg.vals: BLE_XTAL_SETTLE_TIME: 1500 OS_CPUTIME_FREQ: 32768 OS_CPUTIME_TIMER_NUM: 5 TIMER_0: 0 TIMER_5: 1 Further improvements: 1) The nordic chips allow for a faster RXEN/TXEN time. This was not added to this version of code but could be added in the future to improve power consumption. 2) The old code which uses 1 usec timing could also include the code to turn on/off the HFXO. This was not added as we wanted to keep the old code unchanged. The basic idea here is this though: if you want more accurate timing and you have a device that is not battery operated, you are better off using the 1MHz timer. I think this makes for a smaller code footprint as well although I have not characterized this. 3) Determine the actual settling time on the development boards. > Low power timer support for nimble controller > - > > Key: MYNEWT-701 > URL: https://issues.apache.org/jira/browse/MYNEWT-701 > Project: Mynewt > Issue Type: New Feature > Components: Nimble >Affects Versions: v1_0_0_rel >Reporter: William San Filippo >Assignee: William San Filippo > Fix For: v1_1_0_rel > > > Add low power timer support for the nimble controller. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-698) Unhandled exception in controller (in ble_ll_conn_end)
[ https://issues.apache.org/jira/browse/MYNEWT-698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15949841#comment-15949841 ] ASF subversion and git services commented on MYNEWT-698: Commit 612f8efe462f27641cc4fd87993f7a3a079ec67b in incubator-mynewt-core's branch refs/heads/nrf_cputime from [~wes3] [ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=612f8ef ] MYNEWT-698: Unhandled exception in controller in ble_ll_conn_end Not sure what happened but only some of the fix was committed in the prior commit. This is the actual fix for this issue. > Unhandled exception in controller (in ble_ll_conn_end) > -- > > Key: MYNEWT-698 > URL: https://issues.apache.org/jira/browse/MYNEWT-698 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Affects Versions: v1_0_0_rel >Reporter: William San Filippo >Assignee: William San Filippo > Fix For: v1_1_0_rel > > > The controller is generating an unhandled exception inside the function > ble_ll_conn_end(). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-701) Low power timer support for nimble controller
[ https://issues.apache.org/jira/browse/MYNEWT-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15949844#comment-15949844 ] ASF subversion and git services commented on MYNEWT-701: Commit 3c7859538a63df76d170fb5cc30cac902f13a7b0 in incubator-mynewt-core's branch refs/heads/nrf_cputime from [~wes3] [ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=3c78595 ] MYNEWT-701: Low power timer support This commit adds low power timer support to the controller for the nordic chips. Please see the Jira ticket for more information. > Low power timer support for nimble controller > - > > Key: MYNEWT-701 > URL: https://issues.apache.org/jira/browse/MYNEWT-701 > Project: Mynewt > Issue Type: New Feature > Components: Nimble >Affects Versions: v1_0_0_rel >Reporter: William San Filippo >Assignee: William San Filippo > Fix For: v1_1_0_rel > > > Add low power timer support for the nimble controller. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-696) NMP datetime response uses inconsistent format
[ https://issues.apache.org/jira/browse/MYNEWT-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15949838#comment-15949838 ] ASF subversion and git services commented on MYNEWT-696: Commit cb97248bcd5c05bac0b8177095d0a638bea4221c in incubator-mynewt-core's branch refs/heads/nrf_cputime from [~ccollins476] [ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=cb97248 ] MYNEWT-696 NMP datetime rsp uses inconsistent fmt If the time was set with a time zone, the datetime response includes the time zone at the end of the string. Otherwise, no time zone is present. This inconsistency makes parsing more difficult. The fix is to report UTC as the time zone if none was explicitly specified. > NMP datetime response uses inconsistent format > -- > > Key: MYNEWT-696 > URL: https://issues.apache.org/jira/browse/MYNEWT-696 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > If the time was set with a time zone, the datetime response includes the time > zone at the end of the string. Otherwise, no time zone is present. > This inconsistency makes parsing more difficult. The fix is to report UTC as > the time zone if none was explicitly specified. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-701) Low power timer support for nimble controller
William San Filippo created MYNEWT-701: -- Summary: Low power timer support for nimble controller Key: MYNEWT-701 URL: https://issues.apache.org/jira/browse/MYNEWT-701 Project: Mynewt Issue Type: New Feature Components: Nimble Affects Versions: v1_0_0_rel Reporter: William San Filippo Assignee: William San Filippo Fix For: v1_1_0_rel Add low power timer support for the nimble controller. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-700) BLE Host - Race condition: disconnect + att-tx
[ https://issues.apache.org/jira/browse/MYNEWT-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15949625#comment-15949625 ] ASF subversion and git services commented on MYNEWT-700: Commit 9b6c2847d4fef37e2cbe47b5dfc4b8c8e3a7 in incubator-mynewt-core's branch refs/heads/develop from [~ccollins476] [ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=9b6c284 ] MYNEWT-700 BLE Host - Race condition: discon + att Some parts of the ATT code assume a peer is still connected after an initial check. This assumption leads to a race condition when a task other than the host task is doing the transmitting (e.g., tx of unsolicited notification). It is possible that the peer gets disconnected after the tx function is called, but before it completes. When this occurs, an assertion fails (ble_att_conn_chan_find()). The fix is to remove this assumption. Always check that the connection / channel lookup succeeds before accessing the returned pointers. > BLE Host - Race condition: disconnect + att-tx > -- > > Key: MYNEWT-700 > URL: https://issues.apache.org/jira/browse/MYNEWT-700 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > Some parts of the ATT code assume a peer is still connected after an initial > check. This assumption leads to a race condition when a task other than the > host task is doing the transmitting (e.g., tx of unsolicited notification). > It is possible that the peer gets disconnected after the tx function is > called, but before it completes. When this occurs, an assertion fails > (ble_att_conn_chan_find()). > The fix is to remove this assumption. Always check that the connection / > channel lookup succeeds before accessing the returned pointers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-700) BLE Host - Race condition: disconnect + att-tx
Christopher Collins created MYNEWT-700: -- Summary: BLE Host - Race condition: disconnect + att-tx Key: MYNEWT-700 URL: https://issues.apache.org/jira/browse/MYNEWT-700 Project: Mynewt Issue Type: Bug Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel Some parts of the ATT code assume a peer is still connected after an initial check. This assumption leads to a race condition when a task other than the host task is doing the transmitting (e.g., tx of unsolicited notification). It is possible that the peer gets disconnected after the tx function is called, but before it completes. When this occurs, an assertion fails (ble_att_conn_chan_find()). The fix is to remove this assumption. Always check that the connection / channel lookup succeeds before accessing the returned pointers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-699) recreate linker files which show how to build olimex bsp to run from RAM
Marko Kiiskila created MYNEWT-699: - Summary: recreate linker files which show how to build olimex bsp to run from RAM Key: MYNEWT-699 URL: https://issues.apache.org/jira/browse/MYNEWT-699 Project: Mynewt Issue Type: Bug Affects Versions: v1_0_0_rel Reporter: Marko Kiiskila Assignee: Marko Kiiskila I removed them as unused, without realizing that our tutorials talk refer them. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
