Re: Controlled shutdown

[Christopher Collins]

Hi Vipul,

On Tue, Oct 09, 2018 at 12:01:46PM -0700, Vipul Rahane wrote:
> Sorry for the late reply. 

No problem!

> I really like the idea. Thank you for doing this Chris. A much needed
> feature. A possible use case just came to my mind.
> 
> One module might have to be shutdown before shutting down others for
> example: Sensors using I2C/SPI would have to be shut down before
> shutting down the underlying interfaces.
> 
> This is kind of similar to pkg.init levels. I wanted to understand if
> you had any kind of priority in mind.

That is exactly what I had in mind.  I have submitted the relevant PRs
for this feature here:

Newt: https://github.com/apache/mynewt-newt/pull/218
Core: https://github.com/apache/mynewt-core/pull/1447
Nimble: https://github.com/apache/mynewt-nimble/pull/216

The newt PR describes the syntax for configuring a package's sysdown
functions:

pkg.down:
: 
e.g.,

pkg.down:
ble_hs_shutdown: 200

As with sysinit, sysdown functions are excuted in ascending order of
stage number.  When there are two or more identical stage numbers, the
functions are executed in lexicographic order according to their C
function name.

Thanks,
Chris

Re: Controlled shutdown

[Vipul Rahane]

Hey,

Sorry for the late reply. I really like the idea. Thank you for doing this 
Chris. A much needed feature. A possible use case just came to my mind.

One module might have to be shutdown before shutting down others for example: 
Sensors using I2C/SPI would have to be shut down before shutting down the 
underlying interfaces.

This is kind of similar to pkg.init levels. I wanted to understand if you had 
any kind of priority in mind.

Regards,
Vipul Rahane

> On Oct 1, 2018, at 10:44 AM, Andrzej Kaczmarek 
>  wrote:
> 
> Hi Chris,
> 
> On Mon, Oct 1, 2018 at 7:39 PM Christopher Collins  wrote:
> 
>> Hi Andrzej,
>> 
>> On Sun, Sep 30, 2018 at 08:27:19PM +0200, Andrzej Kaczmarek wrote:
>>> I guess device can be powered off simply as a power saving option or
>>> shipping mode so perhaps 'reason' parameter could be added to shutdown
>>> call. I do not know if it really matters to any package whether we
>> shutdown
>>> to reset device or just to power it off, but single extra parameter won't
>>> hurt.
>> 
>> Good idea.
>> 
>>> Return codes feel like a bit more intuitive way to do this. You don't
>>> really need to use branching in shutdown code, I think of two other ways
>> to
>>> do this:
>>> 1. create array of pointers to functions and then main shutdown code can
>>> call each function and examine return codes (or, a bit more complicated
>>> way, create new section where these pointers are places and shutdown code
>>> can also iterate them as array)
>> 
>> Another good idea.  I will try it out and report back!
>> 
>>> 2. just return logical "or" of all return codes from all shutdown
>> functions
>>> - zero means shutdown is complete, non-zero means it's in progress (you
>> can
>>> make it a bitmask in case there's need to distinguish few status codes)
>> 
>> I am having a hard time seeing how this would work.  A logical-or of the
>> return codes would only tell us if at least one subprocedure is still in
>> progress.  This is not enough information; we need to know exactly how
>> many are still in progress so that we can determine when they have all
>> completed (i.e., when the counter reaches 0).  Are you envisioning a
>> solution that does not require a counter?
>> 
> 
> Ah, you're absolutely right. I forgot that we need to know how many
> subprocedures are pending. So this option is not a solution here.
> 
> Chris
>> 
> 
> Best,
> Andrzej

Re: NimBLE Extended Scan

[Łukasz Rymanowski]

Hi Marc,

On Tue, 9 Oct 2018 at 09:59, Marc BT  wrote:
>
> Hi Łukasz,
>
> Thanks for quick reply and a quick update.
>
> I followed the guideline ...got a bit confused on the logging of the rtt2pty 
> tool:
> ../tools-rtt2pty/rtt2pty -b btmonitor
> Using jlinkarm found at /opt/SEGGER/JLink/libjlinkarm.so
> Connected to:
>   J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 12 2018 11:44:41
>   S/N: 683623237
> Searching for RTT control block...
> Failed to find matching up-buffer
>

That would mean BLE_MONITOR_RTT: 1 is not set as in the tutorial.
Could you please double check, rebuild, flash and try one more time?

> Running it without the -b btmonitor I could get a pty port.
>
> Monitoring showed some logging, not like the one from the codecoup btmon link 
> but a starting point.
>
> 021819 Extended adv: 'conn' incomplete rssi=-60 txpower=127, pphy=1, sphy=1, 
> sid=10, addr_type=0 addr=66:55:44:33:22:11
> 021822  length_data=229 
> data=0x19:0x09:0x48:0x65:0x6c:0x6c:0x6f:0x2c:0x20:0x49:0x27:0x6d:0x20:0x61:0x64:0x76:0x65:0x72:0x74:0x69:0x7
> 
> 021853 Extended adv: 'conn' complete rssi=-60 txpower=127, pphy=1, sphy=1, 
> sid=10, addr_type=0 addr=66:55:44:33:22:11
> 021856  length_data=15 
> data=0x69:0x6e:0x67:0x20:0x39:0x19:0x09:0x48:0x65:0x6c:0x6c:0x6f:0x2c:0x20:0x49
>  fields:
> 021859
> 021859 Extended adv: 'conn' incomplete rssi=-53 txpower=127, pphy=1, sphy=1, 
> sid=10, addr_type=0 addr=66:55:44:33:22:11
> 021862  length_data=229 
> data=0x19:0x09:0x48:0x65:0x6c:0x6c:0x6f:0x2c:0x20:0x49:0x27:0x6d:0x20:0x61:0x64:0x76:0x65:0x72:0x74:0x69:0x7
> 
> 
> 021861 received advertisement; event_type=4 rssi=-82 addr_type=1 
> addr=f1:80:b4:61:d2:c6 length_data=29 
> data=0x02:0x0a:0x04:0x19:0x09:0x45:0x78:0x70:0x65:0x72:0x74:0x26:0x4d:0x69:0x6c:0x6b:0x5f:0x46:0x31:0x38:0x30:0x42:0x34:0x36:0x31:0x44:0x32:0x43:0x35
>  fields:
> 021868 name(complete)=Expert_F180B461D2C5
> 021869 tx_pwr_lvl=4
>
> Time to start further debugging
>

Note that printing lot of data on the console might break your
scanning, especially long chaining.
Have a look at command  `set-scan-opts` which can help you to limit
number of bytes to print out.
Also there is an option to filter out legacy advertising.


> Thank,
> Marc

Best
Łukasz

>
> >Hello Marc,
> >
> >There is no additional configuration needed as long as you are using 1M PHY.
> >Would be good to get some logs and best would be to have btmon logs:
> >https://www.codecoup.pl/blog/support-for-btmon-in-mynewt/
> >
> >Best
> >Łukasz
> >>On Mon, 8 Oct 2018 at 12:29, Marc BT  wrote:
> >>
> >> Hello all,
> >>
> >> I'm trying to configure two Nordic nRF52840-DK boards, one as advertiser 
> >> (Extended Advertise),
> the other as scanner (Extended Scan).
> >>
> >> Compile settings (newt target amend ):
> >>
> >>   *   BLE_EXT_ADV = 1
> >>   *   BLE_EXT_ADV_MAX_SIZE = 700
> >>
> >>  I've used a TI kit to verify the existence of Extended Advertising.
> >>
> >> The  board configured as Extended Advertiser works, the advertising 
> >> packets can be seen
> on the TI board.
> >> The board configured as Extended Scanner doesn't return any advertising 
> >> events.
> >>
> >> The HCI commands to setup the Extended Scan don't return any status error.
> >>
> >> Am I missing some compile switches ?
> >>
> >> Kind regards,
> >> Marc
>
> 
> From: Marc BT
> Sent: Monday, October 8, 2018 12:13 PM
> To: dev@mynewt.apache.org
> Subject: NimBLE Extended Scan
>
> Hello all,
>
> I'm trying to configure two Nordic nRF52840-DK boards, one as advertiser 
> (Extended Advertise), the other as scanner (Extended Scan).
>
> Compile settings (newt target amend ):
>
>   *   BLE_EXT_ADV = 1
>   *   BLE_EXT_ADV_MAX_SIZE = 700
>
>  I've used a TI kit to verify the existence of Extended Advertising.
>
> The  board configured as Extended Advertiser works, the advertising packets 
> can be seen on the TI board.
> The board configured as Extended Scanner doesn't return any advertising 
> events.
>
> The HCI commands to setup the Extended Scan don't return any status error.
>
> Am I missing some compile switches ?
>
> Kind regards,
> Marc