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 wrote: > It seems like the best/quickest solution is to not erase the empty area. >

Re: newtmgr image upload nrf51dk disconnects with reason=8

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

Re: newtmgr image upload nrf51dk disconnects with reason=8

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 > >

Re: newtmgr image upload nrf51dk disconnects with reason=8

Another option is not erasing every time, and or a separate erase command. Then its kinda of ugly you get disconnected during erase or first attempt at upload, but after you just reconnect and upload again. On Fri, Apr 21, 2017 at 9:29 PM, Simon Ratner wrote: > > itvl_min and

Re: newtmgr image upload nrf51dk disconnects with reason=8

> 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,

Re: newtmgr image upload nrf51dk disconnects with reason=8

Hi Jacob, 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. In this case, that number would be the

Re: newtmgr image upload nrf51dk disconnects with reason=8

ble_gap_conn_find tells you the settings that are actually being used. If you just want to change one parameter in an established connection, you would copy all but one of the values from the returned desc into the update parameters. You would probably call ble_gap_conn_find immediately before

Re: newtmgr image upload nrf51dk disconnects with reason=8

find returns ble_gap_conn_desc which is the post negotiated values.. Im not sure it helps me know what the original max/mins we negotiated were. These are based on the advertised values right? Itd be nice to have a helper function to just update the one I want, much like in advertising where they

Re: newtmgr image upload nrf51dk disconnects with reason=8

On Thu, Apr 20, 2017 at 09:43:12PM -0700, Jacob Rosenthal wrote: > supervision_timeout = 300 appears to have done it! Any good way to find the > existing params change just the 1 I actually want to change? You can use ble_gap_conn_find() to determine the current connection parameters. > Maybe

Re: newtmgr image upload nrf51dk disconnects with reason=8

supervision_timeout = 300 appears to have done it! Any good way to find the existing params change just the 1 I actually want to change? Maybe nrf51 devices should look up supervision_timeout and either send an error code or even request parameter update automatically? static int

Re: newtmgr image upload nrf51dk disconnects with reason=8

Not sure I am answering the right question here as I am sort of jumping in the middle, but with the NRF51 when you erase the flash the CPU is halted. At least, that is what the documentation states. The joy :-) > On Apr 20, 2017, at 4:16 PM, marko kiiskila wrote: > > Does

Re: newtmgr image upload nrf51dk disconnects with reason=8

Hello: They are both related (in a way). When you increase the slave latency the supervision timeout sort of increases along with it (in a manner so speaking). The minimum supervision timeout is this: (1 + connSlaveLatency) * connInterval * 2. So if you increase the slave latency you need to

Re: newtmgr image upload nrf51dk disconnects with reason=8

I believe the setting to tweak is the slave latency, and have some empirical evidence to back that up. Increasing supervision timeout doesn't help if the timeout is at the link manager level (because of a blocking call, say), while increasing slave latency allows the peripheral to take more than

Re: newtmgr image upload nrf51dk disconnects with reason=8

Hi Jacob, On Thu, Apr 20, 2017 at 02:21:01PM -0700, Jacob Rosenthal wrote: > I think the default intervals are here, which should be sufficiently over > 20ms > /** 30 ms. */ > #define BLE_GAP_ADV_FAST_INTERVAL1_MIN (30 * 1000 / BLE_HCI_ADV_ITVL) > //48 > > /** 60 ms. */ > #define

Re: newtmgr image upload nrf51dk disconnects with reason=8

Not sure about the advertising interval part but you can update the connection parameters using ble_gap_update_params() function. bletiny does have an example in case you would want to check that out. Also, after reading a bit, it seems that it’s up to the central whether to accept the

Re: newtmgr image upload nrf51dk disconnects with reason=8

I took out the interrupts and it the disconnect still happens actually. Random googling found this: https://devzone.nordicsemi.com/question/1183/nrf51822-flash-erase-error/?answer=1281#post-id-1281 "If you need to also erase pages while in a connection, you need to make sure the connection

Re: newtmgr image upload nrf51dk disconnects with reason=8

hts on what to do about flash erase disconnecting? > >> > >> > >> On Thu, Apr 20, 2017 at 10:39 AM, Alan Graves < > agra...@deltacontrols.com> > >> wrote: > >> > >>> Reminds me of that old Wendy's TV commercial: > >>> "

Re: newtmgr image upload nrf51dk disconnects with reason=8

017 at 10:39 AM, Alan Graves <agra...@deltacontrols.com> >> wrote: >> >>> Reminds me of that old Wendy's TV commercial: >>> "Where's the deadbeef?" >>> >>> ALan >>> >>> -Original Message- >>> From: marko kiiskila

Re: newtmgr image upload nrf51dk disconnects with reason=8

>> Reminds me of that old Wendy's TV commercial: >> "Where's the deadbeef?" >> >> ALan >> >> -Original Message- >> From: marko kiiskila [mailto:ma...@runtime.io] >> Sent: Wednesday, April 19, 2017 5:00 PM >> To: dev@mynewt

Re: newtmgr image upload nrf51dk disconnects with reason=8

OK. thanks, I understand that much better. I totally forgot about increasing the stack size.. Separately I figured out by commenting things out that cbor_encode_text_stringz is what was crashing it, and increased the main stack size. Which makes sense. Now Im back to what started this, with err 8.

Re: newtmgr image upload nrf51dk disconnects with reason=8

> On Apr 19, 2017, at 4:33 PM, Jacob Rosenthal wrote: > > On Wed, Apr 19, 2017 at 11:19 AM, marko kiiskila wrote: > >> Just general comments, I hope I’m not saying things which are >> too obvious. >> > More specific would be even better :) I dont

Re: newtmgr image upload nrf51dk disconnects with reason=8

On Wed, Apr 19, 2017 at 04:33:05PM -0700, Jacob Rosenthal wrote: > On Wed, Apr 19, 2017 at 11:19 AM, marko kiiskila wrote: > > > Just general comments, I hope I’m not saying things which are > > too obvious. > > > More specific would be even better :) I dont think my gdb is up

Re: newtmgr image upload nrf51dk disconnects with reason=8

On Wed, Apr 19, 2017 at 11:19 AM, marko kiiskila wrote: > Just general comments, I hope I’m not saying things which are > too obvious. > More specific would be even better :) I dont think my gdb is up to par Either g_os_run_list or one of the task structures is getting

Re: newtmgr image upload nrf51dk disconnects with reason=8

Just general comments, I hope I’m not saying things which are too obvious. Either g_os_run_list or one of the task structures is getting smashed. As you know you tasks beforehand, you can walk through them manually to figure which one it is. Usually culprit is stack overflow, so once you find out

Re: newtmgr image upload nrf51dk disconnects with reason=8

Anyone have thoughts on debugging the scheduler crash? That point gets hit constantly, so breaking there is tough, break commands and logging also appears to mess with bluetooth timing as I cant get a connect when I do that. On Mon, Apr 17, 2017 at 10:49 AM, Jacob Rosenthal

Re: newtmgr image upload nrf51dk disconnects with reason=8

Hr. I Tried BLE_LL_CFG_FEAT_DATA_LEN_EXT, and also commenting out the erase, but (even rolling back those changes) Im suddenly seeing a crash in the logs now. 1345:[ts=10507780ssb, mod=4 level=0] Number of ComUnhandled interrupt (3), exception sp 0x2998 1345: r0:0x24c0 r1:0x0001

Re: newtmgr image upload nrf51dk disconnects with reason=8

I wonder if this issue is related to other controllers that we have had issues with. Try disabling Data Length Extension. Set BLE_LL_CFG_FEAT_DATA_LEN_EXT in net/nimble/controller/syscfg.yml to 0 Let us know if that changes anything. > On Apr 16, 2017, at 6:13 PM, Jacob Rosenthal

Re: newtmgr image upload nrf51dk disconnects with reason=8

Hi Jacob, On Sun, Apr 16, 2017 at 03:47:24PM -0700, Jacob Rosenthal wrote: > I got a linux partition and newtmgr working finally, However the upload > command fails after writing one packet. The logs appear to show > BLE_HS_ENOTSUP , but I just cant find where that could becoming from! any > help

newtmgr image upload nrf51dk disconnects with reason=8

I got a linux partition and newtmgr working finally, However the upload command fails after writing one packet. The logs appear to show BLE_HS_ENOTSUP , but I just cant find where that could becoming from! any help appreciated :) Jacobs-MacBook-Air:chippd3 jacobrosenthal$ newt target show