Re: Running Newt on nrf51 boards with 0.9.0 and 0-dev

[Wayne Keenan]

Hi Will,

Ok, thanks for letting me know.  Boards 2&3 are 'hidden' behind the mbed
CMSIS-DAP interface and I also didn't want to resort to using additional
h/w (a non-dev user wouldn't have) in order to erase or program them; prior
to programming board 1 am using:

JLinkExe -device nrf51 -if swd -speed 4000

erase

q


.
All the best
Wayne

On 2 June 2016 at 23:12, will sanfilippo  wrote:

> Hey Wayne:
>
> We dont “officially” support the boards you mention as they are not in the
> supported BSPs. If you have an “official" nrf51dk that would be the best to
> get started on as we do support that currently.
>
> Unfortunately, bletiny is a bit of a misnomer; it is not so tiny, and
> depending on which version you are trying to build it may be too large to
> fit in our current image slot; bleprph should work though. We may have a
> work-around for nrf51 bletiny soon but for now I would use bleprph.
>
> BTW, are you sure you have erased the devices you are trying to load the
> code on? There are protection mechanisms that you must disable in order for
> our newt tool to be able to erase/program flash.
>
>
>
> > On Jun 2, 2016, at 2:04 PM, Wayne Keenan  wrote:
> >
> > Hi,
> >
> > I've been trying to get the bletiny and bleprph apps running on a few
> types
> > of nrf51 boards but not having much luck.
> >
> > The 3 types are:
> >
> > 1. PCA1 -  QFAA G0  (The stubby little USB dingle with the built-in
> > Jsegger J-link)
> > 2. PCA10024 -  QFAA G0 (The mbed enabled board, using a hex file )
> > 3. BBC:Microbit  -   QFAA M0
> >
> > I've tried with bsp set to 'nrf51dk-16kbram' and 'nrf51dk'
> > I am uploading the Newt boot loader app too.
> >
> >
> > In order to upload to #2 & #3 (as they appear as USB drives) I've tried
> > converting the elf binaries to a combined hex file in two different ways:
> >
> > A)
> >
> > arm-none-eabi-objcopy -O ihex bin/bletiny/apps/bletiny.elf app.hex
> > arm-none-eabi-objcopy -O ihex bin/nrf51_boot/apps/boot/boot.elf boot.hex
> >
> > mergehex -m app.hex boot.hex  -o microbit_firmware.hex
> >
> > B)
> >
> > srec_cat boot.hex -intel app.hex -intel  -o  combined.hex -intel
> >
> >
> > I'm pretty sure for #3 that it's possible to flash the entire address
> range
> > of the nrf51  as the micro:bit's default firmware download from the web
> is
> > a > 500k hex file; which without lifting the hood it implies to me it has
> > the SoftDevice, App and Bootloader.
> >
> > I'm not having much luck, I probably need to add some load/start address
> > info during objcopy and/or some address altering flags using srec_cat (?)
> >
> > Are these boards and the methods currently supported?   I guess they
> should
> > be but I've buttered fingered something somewhere.
> >
> > Or perhaps should I be using the 'official' nrf51dk ?
> >
> >
> > All the best
> > Wayne
>
>

Re: MIPS 32 M4K - os specific code to run mynewt

[Pradeep Sanjeewa]

Hi Will,

I want to understand how this code is generated looking at the datasheet as
well as the block diagram of the processor.
Yes, let's make this the starting point.
I'm completely OK with that.

Regards,
Sanjeewa

On Fri, Jun 3, 2016 at 9:28 AM, will sanfilippo  wrote:

> Pradeep:
>
> Is there anything specific in that file you have questions about or is it
> the entire file? By the way, I am not sure I would have chosen this as the
> best place to start, but if you feel it is, I can help walk you through it.
>
> Will
>
> > On Jun 2, 2016, at 6:28 PM, Pradeep Sanjeewa 
> wrote:
> >
> > Hi All,
> >
> > I'm porting mynewt to pic architecture. I'm using bluetooth starter kit
> > where there
> > is a pic32mx270f256d mcu (mips 32 m4k processor core). Currently, I'm
> > developing
> > os spefic code for mips 32 m4k processor.
> > I'm referring to cortex-m4 (
> >
> https://github.com/apache/incubator-mynewt-core/blob/develop/hw/bsp/nrf52dk/src/arch/cortex_m4/gcc_startup_nrf52.s
> > ).
> > This code segment is developed by Nordic.
> > Can someone help me to understand this code segment?
> > And how the code segment was developed looking at the data sheet.
> > It will be truely helpful for me to work on mips 32 m4k.
> >
> > Regards,
> > Sanjeewa
>
>

Running Newt on nrf51 boards with 0.9.0 and 0-dev

[Wayne Keenan]

Hi,

I've been trying to get the bletiny and bleprph apps running on a few types
of nrf51 boards but not having much luck.

The 3 types are:

1. PCA1 -  QFAA G0  (The stubby little USB dingle with the built-in
Jsegger J-link)
2. PCA10024 -  QFAA G0 (The mbed enabled board, using a hex file )
3. BBC:Microbit  -   QFAA M0

I've tried with bsp set to 'nrf51dk-16kbram' and 'nrf51dk'
I am uploading the Newt boot loader app too.


In order to upload to #2 & #3 (as they appear as USB drives) I've tried
converting the elf binaries to a combined hex file in two different ways:

A)

arm-none-eabi-objcopy -O ihex bin/bletiny/apps/bletiny.elf app.hex
arm-none-eabi-objcopy -O ihex bin/nrf51_boot/apps/boot/boot.elf boot.hex

mergehex -m app.hex boot.hex  -o microbit_firmware.hex

B)

srec_cat boot.hex -intel app.hex -intel  -o  combined.hex -intel


I'm pretty sure for #3 that it's possible to flash the entire address range
of the nrf51  as the micro:bit's default firmware download from the web is
a > 500k hex file; which without lifting the hood it implies to me it has
the SoftDevice, App and Bootloader.

I'm not having much luck, I probably need to add some load/start address
info during objcopy and/or some address altering flags using srec_cat (?)

Are these boards and the methods currently supported?   I guess they should
be but I've buttered fingered something somewhere.

Or perhaps should I be using the 'official' nrf51dk ?


All the best
Wayne

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc3

[will sanfilippo]

[X] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...


Will

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc3

[Christopher Collins]

On Mon, May 30, 2016 at 11:34:24AM -0700, Christopher Collins wrote:
> [X] +1 Release this package
> [ ]  0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...

Chris

Re: BLE_GATT_CHR_F_NOTIFY and pinkey

[Wayne Keenan]

Hi,


>
> 2. It is too difficult to get all the configuration settings correct.
> I'm wondering if we should have the application pass its service table
> to ble_hs_init().  That way, the correct values for max_services,
> max_attrs, and max_client_configs can all be derived from the table.
> One complication here is that the application is currently allowed to
> register its services in several steps (multiple calls to
> ble_gatts_register_svcs(), each time passing a different table).  I
> suppose the options are to either a) remove support for multistage
> registration, or b) maintain the current configuration behavior, and
> make the new service table method optional.
>
>
Please don't remove the multistage registration feature, it's very useful
for dynamically creating services from a scripting language.

Thanks
Wayne

Re: BLE_GATT_CHR_F_NOTIFY and pinkey

[Stephane D'Alu]

On 06/02/2016 05:53 PM, Christopher Collins wrote:

On Thu, Jun 02, 2016 at 02:25:33PM +0200, Stephane D'Alu wrote:

Adding the "| BLE_GATT_CHR_F_NOTIFY" result in an error when setting
advertisement, which seems to be: pinkey missing.

105:[ts=102480ssb, mod=64 level=3] error enabling advertisement; rc=6
111:[ts=108336ssb, mod=4 level=0] Command Complete: cmd_pkts=1 ogf=0x0
ocf=0x0 status=5

I'm using bleprph (0.9-dev) as template, which is already using
BLE_GATT_CHR_F_NOTIFY for it's Alert service, and I haven't seen such
pinkey requirement. Any idea on what is wrong?


Hi Stephane,

Unfortunately, it appears you are the victim of a few red herrings :).
I will attempt to explain what is going on below.  First, the solution
is to increase the max_client_configs setting by at least two, e.g.,

 cfg.max_client_configs = 8;

I believe this change will make the problem go away.


Bingo!


> [...]

Finally, your email sparked a few thoughts.  These are just some musings
that need some more thought, but it will help me to write them down, so
I hope you'll humor me and allow me to do so :).

1. We need better diagnostics.  It would be great if a message was
printed to the debug log indicating exactly what failed when you
attempted to advertise.

2. It is too difficult to get all the configuration settings correct.
I'm wondering if we should have the application pass its service table
to ble_hs_init().  That way, the correct values for max_services,
max_attrs, and max_client_configs can all be derived from the table.
One complication here is that the application is currently allowed to
register its services in several steps (multiple calls to
ble_gatts_register_svcs(), each time passing a different table).  I
suppose the options are to either a) remove support for multistage
registration, or b) maintain the current configuration behavior, and
make the new service table method optional.



I also have some difficulties to size max_attrs and max_services.

Can I propose c)  Having a web-page for nimble stack 
configuration/tuning, and a set of macro that describe the formula used 
to compute the various configuration parameters according to the number 
of services/characteristics/notifications-indications/



Thanks

--
Stephane D'Alu

Re: BLE_GATT_CHR_F_NOTIFY and pinkey

[Christopher Collins]

On Thu, Jun 02, 2016 at 02:25:33PM +0200, Stephane D'Alu wrote:
> Adding the "| BLE_GATT_CHR_F_NOTIFY" result in an error when setting 
> advertisement, which seems to be: pinkey missing.
> 
> 105:[ts=102480ssb, mod=64 level=3] error enabling advertisement; rc=6
> 111:[ts=108336ssb, mod=4 level=0] Command Complete: cmd_pkts=1 ogf=0x0 
> ocf=0x0 status=5
> 
> I'm using bleprph (0.9-dev) as template, which is already using 
> BLE_GATT_CHR_F_NOTIFY for it's Alert service, and I haven't seen such 
> pinkey requirement. Any idea on what is wrong?

Hi Stephane,

Unfortunately, it appears you are the victim of a few red herrings :).
I will attempt to explain what is going on below.  First, the solution
is to increase the max_client_configs setting by at least two, e.g.,

cfg.max_client_configs = 8;

I believe this change will make the problem go away.

As for the cause of the errors:

> 105:[ts=102480ssb, mod=64 level=3] error enabling advertisement; rc=6

The nimble host uses its own set of error codes, separate from the HCI
error codes.  Your confusion is understandable, as we haven't documented
the host error codes anywhere!  This is something we'll need to get on
right away.  The host error codes are defined in
net/nimble/host/include/host/ble_hs.h.  An error code of 6 indicates
memory exhaustion.  In this case, the host did not pre-allocate enough
client characteistic configuration descriptors (CCCDs) for a single
connection, so it prevented the application from performing a
connectable advertisement.

You need to increase max_client_configs by 2 (rather than 1) because the
host maintains a cache of CCCDs that aren't tied to any connection.  The
formula is:

subscribable-charactericteristics * (max-connections + 1)

Where "subscribable-characteristics" is the number of characteristics
supporting notifications or indications.

The other error:

> 111:[ts=108336ssb, mod=4 level=0] Command Complete: cmd_pkts=1 ogf=0x0 
> ocf=0x0 status=5

This is caused by a bug in the hci debug output code.  The event being
logged here is the no-op that the controller sends on startup.  The
no-op is the only event which does not have a status field.  The debug
code assumes all events have statuses, and it prints a bogus value here.
This should be an easy fix, and I'll look at it shortly.

Finally, your email sparked a few thoughts.  These are just some musings
that need some more thought, but it will help me to write them down, so
I hope you'll humor me and allow me to do so :).

1. We need better diagnostics.  It would be great if a message was
printed to the debug log indicating exactly what failed when you
attempted to advertise.

2. It is too difficult to get all the configuration settings correct.
I'm wondering if we should have the application pass its service table
to ble_hs_init().  That way, the correct values for max_services,
max_attrs, and max_client_configs can all be derived from the table.
One complication here is that the application is currently allowed to
register its services in several steps (multiple calls to
ble_gatts_register_svcs(), each time passing a different table).  I
suppose the options are to either a) remove support for multistage
registration, or b) maintain the current configuration behavior, and
make the new service table method optional.

Thanks,
Chris

BLE_GATT_CHR_F_NOTIFY and pinkey

[Stephane D'Alu]

I was trying to add a simple service with notification:

So I added to gatt_svr_svcs
{
/*** Service: Battery */
.type = BLE_GATT_SVC_TYPE_PRIMARY,
.uuid128 = BLE_UUID16(GATT_SVR_SVC_BATTERY),
.characteristics = (struct ble_gatt_chr_def[]) { {
.uuid128 = BLE_UUID16(GATT_SVR_CHR_BATTERY_LEVEL),
.access_cb = gatt_svr_chr_access_battery,
.flags = BLE_GATT_CHR_F_READ | BLE_GATT_CHR_F_NOTIFY,
}, {
0, /* No more characteristics in this service. */
} },
},

Adding the "| BLE_GATT_CHR_F_NOTIFY" result in an error when setting 
advertisement, which seems to be: pinkey missing.


105:[ts=102480ssb, mod=64 level=3] error enabling advertisement; rc=6
111:[ts=108336ssb, mod=4 level=0] Command Complete: cmd_pkts=1 ogf=0x0 
ocf=0x0 status=5


I'm using bleprph (0.9-dev) as template, which is already using 
BLE_GATT_CHR_F_NOTIFY for it's Alert service, and I haven't seen such 
pinkey requirement. Any idea on what is wrong?


Sincerly

--
Stephane D'Alu