You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Jacob Rosenthal <ja...@gmail.com> on 2017/06/09 22:37:19 UTC

Re: newtmgr image upload nrf51dk disconnects with reason=8

This was resolved with
https://github.com/apache/incubator-mynewt-core/pull/281
https://github.com/apache/incubator-mynewt-newt/pull/60

On Mon, Apr 24, 2017 at 11:00 PM, Jacob Rosenthal <ja...@gmail.com>
wrote:

> It seems like the best/quickest solution is to not erase the empty area.
> That way we dont have to figure out how and when to renegotiate the
> connection and we also get an erase command for 'free' as the first upload
> will fail but fail having successfully erased the sector. We need to do
> several connections and reconnects anyway with split loader topology so
> *shrug*.
>
> Looks like this was planned anyway as theres what looks like a todo there
> "XXX only erase if needed."
>
> I can do the PR, but ideally someone familiar with imgmgr or flash could
> comment on some status I can check to know if we need to erase or not.
>
>
> On Sat, Apr 22, 2017 at 1:38 PM, Christopher Collins <ch...@runtime.io>
> wrote:
>
>> On Fri, Apr 21, 2017 at 09:29:59PM -0700, Simon Ratner wrote:
>> > > itvl_min and itvl_max specify the range of connection interval values
>> that
>> > > you're willing to accept. The controller chooses the value in that
>> range
>> > > that it likes best. If you want an exact interval, then specify the
>> same
>> > > number for both fields.
>> >
>> > Note that iOS will reject such a request, see their accessory design
>> > guidelines.
>> > For one, itvl_max must be at least 20ms bigger than itvl_min.
>>
>> Thanks, that is good to know.  I should also take this opportunity to
>> correct something I wrote above.  I said it is up to the slave
>> controller to select its preferred interval from the range specified by
>> the host.  This is wrong.  The slave sends both the min and max interval
>> values to the master, and the master chooses the interval to use (or
>> rejects the request entirely).  So this is how iOS can impose the
>> restriction you mentioned even though the iphone is acting as the master
>> (central).  Sorry for the misinformation.
>>
>> Chris
>>
>
>