[jira] [Resolved] (MYNEWT-398) boot_serial needs to process the new image list command
[ https://issues.apache.org/jira/browse/MYNEWT-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marko Kiiskila resolved MYNEWT-398. --- Resolution: Fixed Fix Version/s: v1_0_0_rel It does respond to image list command with format that newtmgr can display. > boot_serial needs to process the new image list command > --- > > Key: MYNEWT-398 > URL: https://issues.apache.org/jira/browse/MYNEWT-398 > Project: Mynewt > Issue Type: Bug >Reporter: Marko Kiiskila > Fix For: v1_0_0_rel > > > It only responds to old-format request. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-709) nffs - Occasional unit test failures
Christopher Collins created MYNEWT-709:
--
Summary: nffs - Occasional unit test failures
Key: MYNEWT-709
URL: https://issues.apache.org/jira/browse/MYNEWT-709
Project: Mynewt
Issue Type: Bug
Components: NFFS
Reporter: Christopher Collins
Assignee: Christopher Collins
Fix For: v1_1_0_rel
{noformat}
03/31/2017, 18:42:11.997Executing test:
/home/jenkins/workspace/0-testall-sim/newt_ci_templates/bin/targets/unittest/fs_nffs_test/app/fs/nffs/test/fs_nffs_test.elf
03/31/2017, 18:42:13.802Test failure (fs/nffs/test):
03/31/2017, 18:42:13.803[pass] nffs_test_suite/nffs_test_unlink
03/31/2017, 18:42:13.804[pass] nffs_test_suite/nffs_test_mkdir
03/31/2017, 18:42:13.805[pass] nffs_test_suite/nffs_test_rename
03/31/2017, 18:42:13.805[pass] nffs_test_suite/nffs_test_truncate
03/31/2017, 18:42:13.806[pass] nffs_test_suite/nffs_test_append
03/31/2017, 18:42:13.807[pass] nffs_test_suite/nffs_test_read
03/31/2017, 18:42:13.808[pass] nffs_test_suite/nffs_test_open
03/31/2017, 18:42:13.809[pass] nffs_test_suite/nffs_test_overwrite_one
03/31/2017, 18:42:13.809[pass] nffs_test_suite/nffs_test_overwrite_two
03/31/2017, 18:42:13.810[pass] nffs_test_suite/nffs_test_overwrite_three
03/31/2017, 18:42:13.811[pass] nffs_test_suite/nffs_test_overwrite_many
03/31/2017, 18:42:13.812[pass] nffs_test_suite/nffs_test_long_filename
03/31/2017, 18:42:13.813[pass] nffs_test_suite/nffs_test_large_write
03/31/2017, 18:42:13.813[pass] nffs_test_suite/nffs_test_many_children
03/31/2017, 18:42:13.814[pass] nffs_test_suite/nffs_test_gc
03/31/2017, 18:42:13.815[pass] nffs_test_suite/nffs_test_wear_level
03/31/2017, 18:42:13.816[pass] nffs_test_suite/nffs_test_corrupt_scratch
03/31/2017, 18:42:13.817[pass]
nffs_test_suite/nffs_test_incomplete_block
03/31/2017, 18:42:13.817[FAIL] nffs_test_suite/nffs_test_corrupt_block
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.818[FAIL] nffs_test_suite/nffs_test_corrupt_block
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.819[FAIL] nffs_test_suite/nffs_test_corrupt_block
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.820[pass] nffs_test_suite/nffs_test_large_unlink
03/31/2017, 18:42:13.821
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.821[pass] nffs_test_suite/nffs_test_large_system
03/31/2017, 18:42:13.822
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.823[pass] nffs_test_suite/nffs_test_lost_found
03/31/2017, 18:42:13.824
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.824[pass] nffs_test_suite/nffs_test_readdir
03/31/2017, 18:42:13.825
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.826[pass] nffs_test_suite/nffs_test_split_file
03/31/2017, 18:42:13.827
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.828[pass] nffs_test_suite/nffs_test_gc_on_oom
03/31/2017, 18:42:13.828
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.829[pass] nffs_test_suite/nffs_test_unlink
03/31/2017, 18:42:13.830
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.831[pass] nffs_test_suite/nffs_test_mkdir
03/31/2017, 18:42:13.832
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.832[pass] nffs_test_suite/nffs_test_rename
03/31/2017, 18:42:13.833
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.834[pass] nffs_test_suite/nffs_test_truncate
03/31/2017, 18:42:13.835
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.835[pass] nffs_test_suite/nffs_test_append
[jira] [Updated] (MYNEWT-708) Lock scheduler during init
[
https://issues.apache.org/jira/browse/MYNEWT-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-708:
---
Description:
Now that main() runs after the OS is started, tasks may preempt the main task
as soon as they are created. If such a task expects all packages to have been
initialized, then a crash or other unpredictable behavior will occur.
Here is an example crash that happens when the BLE link layer task runs before
the host package is fully initialized:
{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0 __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1 0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2 0xea5e in ble_ll_hci_send_noop () at
net/nimble/controller/src/ble_ll_hci.c:106
#3 0xa438 in ble_ll_task (arg=) at
net/nimble/controller/src/ble_ll.c:1008
#4 0x in ?? ()
{noformat}
was:
Now that main() runs after the OS is started, tasks may preempt the main task
as soon as they are created. If such a task expects all packages to have been
initialized, then a crash or other unpredictable behavior will occur.
Here is an example crash that happens when the BLE link layer task runs before
the host package is fully initialized:
{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0 __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1 0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2 0xea5e in ble_ll_hci_send_noop () at
net/nimble/controller/src/ble_ll_hci.c:106
#3 0xa438 in ble_ll_task (arg=) at
net/nimble/controller/src/ble_ll.c:1008
#4 0x in ?? ()
(gdb)
#0 __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1 0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2 0xea5e in ble_ll_hci_send_noop () at
net/nimble/controller/src/ble_ll_hci.c:106
#3 0xa438 in ble_ll_task (arg=) at
net/nimble/controller/src/ble_ll.c:1008
#4 0x in ?? ()
{noformat}
> Lock scheduler during init
> --
>
> Key: MYNEWT-708
> URL: https://issues.apache.org/jira/browse/MYNEWT-708
> Project: Mynewt
> Issue Type: Bug
>Reporter: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> Now that main() runs after the OS is started, tasks may preempt the main task
> as soon as they are created. If such a task expects all packages to have
> been initialized, then a crash or other unpredictable behavior will occur.
> Here is an example crash that happens when the BLE link layer task runs
> before the host package is fully initialized:
> {noformat}
> Program received signal SIGTRAP, Trace/breakpoint trap.
> __assert_func (file=, line=, func= out>, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
> 137asm("bkpt");
> (gdb) whe
> #0 __assert_func (file=, line=,
> func=, e=) at
> kernel/os/src/arch/cortex_m4/os_fault.c:137
> #1 0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at
> net/nimble/transport/ram/src/ble_hci_ram.c:91
> #2 0xea5e in ble_ll_hci_send_noop () at
> net/nimble/controller/src/ble_ll_hci.c:106
> #3 0xa438 in ble_ll_task (arg=) at
> net/nimble/controller/src/ble_ll.c:1008
> #4 0x in ?? ()
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MYNEWT-708) Lock scheduler during init
Christopher Collins created MYNEWT-708:
--
Summary: Lock scheduler during init
Key: MYNEWT-708
URL: https://issues.apache.org/jira/browse/MYNEWT-708
Project: Mynewt
Issue Type: Bug
Reporter: Christopher Collins
Fix For: v1_1_0_rel
Now that main() runs after the OS is started, tasks may preempt the main task
as soon as they are created. If such a task expects all packages to have been
initialized, then a crash or other unpredictable behavior will occur.
Here is an example crash that happens when the BLE link layer task runs before
the host package is fully initialized:
{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0 __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1 0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2 0xea5e in ble_ll_hci_send_noop () at
net/nimble/controller/src/ble_ll_hci.c:106
#3 0xa438 in ble_ll_task (arg=) at
net/nimble/controller/src/ble_ll.c:1008
#4 0x in ?? ()
(gdb)
#0 __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1 0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2 0xea5e in ble_ll_hci_send_noop () at
net/nimble/controller/src/ble_ll_hci.c:106
#3 0xa438 in ble_ll_task (arg=) at
net/nimble/controller/src/ble_ll.c:1008
#4 0x in ?? ()
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MYNEWT-707) Add API to retrieve public and static random addresses from chip specific locations
[ https://issues.apache.org/jira/browse/MYNEWT-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15955799#comment-15955799 ] ASF subversion and git services commented on MYNEWT-707: Commit 95c7d3e5f951e381bd8dbfc82335a3a3384d9f56 in incubator-mynewt-core's branch refs/heads/develop from [~wes3] [ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=95c7d3e ] MYNEWT-707: Add API to retrieve public and random static address Please read the Jira ticket for more information on how to use these API. The controller now calls ble_hw_get_public_addr() and will use that address for its public address. The global device address has not been hidden yet since some apps rely on the ability to modify it. > Add API to retrieve public and static random addresses from chip specific > locations > --- > > Key: MYNEWT-707 > URL: https://issues.apache.org/jira/browse/MYNEWT-707 > 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 > > > This ticket will add API to retrieve a public address and random static > address from "chip specific" locations. Here are the API and how they will > work for the nordic chips, which are currently the only supported BLE chips. > This ticket does not address storing/retrieving these values from flash or > configuration areas. > 1) The ble_hw_get_public_addr function will do the following: > * If the user has overridden the default public address (the syscfg variable) > with a non-zero public address, that address will be returned by this > function. > * If the default public address in the syscfg is all zero, the code will read > FICR and check if the device address type in the FICR is public. If so, it > means the nordic chip was factory programmed with a public address and this > will be used. > * If both of the above checks fail, the code will read UICR[0] and UICR[1] to > see if a public address has been programmed into the UICR. We are doing this > to make it easy for folks to program their development kits with public > addresses so they do not have to hardcode them. UICR[0] will contain the > least significant 4 bytes of the device address. UICR[1] will contain the > most significant two bytes. The upper 16 bits of this word should be set to > 0. The API will presume that this is a valid public device address as long as > the upper 16-bits of this 32-bit word are all zero. We will also check to see > if this is a valid public address (see below). If both UICR[0] and UICR[1] > are zero, this will not be considered a valid public address. > 2) The ble_hw_get_static_addr() will do the following: > * Read the FICR to see if there is a random address in the FICR. This is the > default programming of the nrf51dk and nrf52dk. Unless you have them program > a public device address in the FICR, it will have a random address. > * If the chip does not have a random address the API returns -1. > * If the chip has a random address the upper two bits will be set to 1 (which > denotes random static address). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-702) BLE Host - duplicate connection update entries
[ https://issues.apache.org/jira/browse/MYNEWT-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-702. Resolution: Fixed > BLE Host - duplicate connection update entries > -- > > Key: MYNEWT-702 > URL: https://issues.apache.org/jira/browse/MYNEWT-702 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > If the application calls ble_gap_update_params() while an update connection > procedure for that connection is already in progress, the existing entry gets > re-inserted in the ble_gap_update_entries list. This yields a cycle in the > list, causing the host task to loop endlessly during iteration. > More details: > # Host initiates a connection update procedure; creates an entry and inserts > it into the list (ble_gap_update_entries). > # Host attempts to initiate a second connection update procedure for the same > connection. Since an existing update procedure is ongoing, this attempt > fails with a status code of BLE_HS_EALREADY. > # On detecting the error, the ble_gap_update_params() function tries to clean > up (goto done). Part of this cleanup involves freeing the update entry that > got allocated earlier in the function but never got inserted into the list. > In this case, no entry was allocated, but it looks like one was, because the > entry pointer was used to detect a duplicate entry. Consequently, the entry > is freed but never removed from the list! > # The host initiates a third connection update procedure for the same > connection. This time, no duplicate is detected because the entry in the > list got corrupted when it was freed, making its connection handle value > indeterminate. The host allocates the same entry from the pool, populates > it, and inserts it into the list. Now the same entry is in the list twice, > creating a cycle. When the host iterates this list, it loops forever. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-696) NMP datetime response uses inconsistent format
[ https://issues.apache.org/jira/browse/MYNEWT-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-696. Resolution: Fixed > 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-707) Add API to retrieve public and static random addresses from chip specific locations
William San Filippo created MYNEWT-707: -- Summary: Add API to retrieve public and static random addresses from chip specific locations Key: MYNEWT-707 URL: https://issues.apache.org/jira/browse/MYNEWT-707 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 This ticket will add API to retrieve a public address and random static address from "chip specific" locations. Here are the API and how they will work for the nordic chips, which are currently the only supported BLE chips. This ticket does not address storing/retrieving these values from flash or configuration areas. 1) The ble_hw_get_public_addr function will do the following: * If the user has overridden the default public address (the syscfg variable) with a non-zero public address, that address will be returned by this function. * If the default public address in the syscfg is all zero, the code will read FICR and check if the device address type in the FICR is public. If so, it means the nordic chip was factory programmed with a public address and this will be used. * If both of the above checks fail, the code will read UICR[0] and UICR[1] to see if a public address has been programmed into the UICR. We are doing this to make it easy for folks to program their development kits with public addresses so they do not have to hardcode them. UICR[0] will contain the least significant 4 bytes of the device address. UICR[1] will contain the most significant two bytes. The upper 16 bits of this word should be set to 0. The API will presume that this is a valid public device address as long as the upper 16-bits of this 32-bit word are all zero. We will also check to see if this is a valid public address (see below). If both UICR[0] and UICR[1] are zero, this will not be considered a valid public address. 2) The ble_hw_get_static_addr() will do the following: * Read the FICR to see if there is a random address in the FICR. This is the default programming of the nrf51dk and nrf52dk. Unless you have them program a public device address in the FICR, it will have a random address. * If the chip does not have a random address the API returns -1. * If the chip has a random address the upper two bits will be set to 1 (which denotes random static address). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-680) Analyze Privacy Erratas BT 5.0 Vol 1, Part C, 9.3
[ https://issues.apache.org/jira/browse/MYNEWT-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15954926#comment-15954926 ] Łukasz Rymanowski commented on MYNEWT-680: -- Start working on Errata 6356 - LE Privacy Mode > Analyze Privacy Erratas BT 5.0 Vol 1, Part C, 9.3 > - > > Key: MYNEWT-680 > URL: https://issues.apache.org/jira/browse/MYNEWT-680 > Project: Mynewt > Issue Type: Sub-task > Components: ble, Nimble >Reporter: Łukasz Rymanowski >Assignee: Łukasz Rymanowski > > Verify what is missing and implement -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-680) Analyze Privacy Erratas BT 5.0 Vol 1, Part C, 9.3
[ https://issues.apache.org/jira/browse/MYNEWT-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15954917#comment-15954917 ] Łukasz Rymanowski commented on MYNEWT-680: -- Some patches related to LE Directed Advertising has been merged with PR #220 > Analyze Privacy Erratas BT 5.0 Vol 1, Part C, 9.3 > - > > Key: MYNEWT-680 > URL: https://issues.apache.org/jira/browse/MYNEWT-680 > Project: Mynewt > Issue Type: Sub-task > Components: ble, Nimble >Reporter: Łukasz Rymanowski >Assignee: Łukasz Rymanowski > > Verify what is missing and implement -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-706) High duty cycle non connectable
Łukasz Rymanowski created MYNEWT-706: Summary: High duty cycle non connectable Key: MYNEWT-706 URL: https://issues.apache.org/jira/browse/MYNEWT-706 Project: Mynewt Issue Type: Sub-task Reporter: Łukasz Rymanowski Assignee: Łukasz Rymanowski Priority: Minor implemented: https://github.com/apache/incubator-mynewt-core/pull/219 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
