Any thoughts on this? Also, Theres a simple solution while a more complex one is discussed. The current code erases every time no matter what, theres even a code comment there about it. https://github.com/apache/incubator-mynewt-core/blob/afa6d53254cbf444a3f44cc1851f0b038227edb6/mgmt/imgmgr/src/imgmgr.c#L322
The update process already includes at least one reset and reconnect (after test/confirm), so adding another reconnect after first firmware upload resets as it erases is 'fine'. Im not sure how to get started on that myself. Thoughts on this? On Tue, Apr 25, 2017 at 6:51 PM, Will San Filippo <w...@micosa.net> wrote: > Hello: > > Recently there has been some discussion around image upload, erasing > flash, and connection supervision timeouts. We have recently noticed a case > where it appears that due to erasing the flash the connection will time out > (supervision timeout). Changing the supervision timeout, slave latency, etc > will not guarantee success (although may make it less likely to occur). > > We are currently evaluating fixes for this issue so in the meantime just > be aware that this could occur. > > For those who want the gory details: > > What I think is happening is the following. A connection event starts at > the correct time (it is not delayed by the flash erase) but at some point > prior to getting the ADDRESS event a flash erase starts. The ADDRESS event > is used internally to capture a timer value which records the start of the > PDU. A slave will reset its anchor point when it receives a PDU as long as > the access address matches. So what I think is happening is that the > ADDRESS event and timer capture gets delayed because the CPU is halted > during the flash erase causing the anchor point to get reset to an invalid > time. The slave (peripheral) then wakes up at the incorrect time for all > connection events from that point forward causing an eventual supervision > timeout. > > I realize that some might say to just drop the PDU if the timing is off. > This would probably go a long way to making it much less likely to occur > but there is still a chance that the connection will time out. The only way > to guarantee this not occurring is to synchronize flash erase with radio > events (something the current nimble stack does not do).
