Re: Problem with GATT service definition

[James Howarth]

Thanks Chris, that fixed it!

Cheers
James


On Wed, May 18, 2016 at 8:40 PM, Christopher Collins 
wrote:

> On Wed, May 18, 2016 at 08:28:16PM -0700, James Howarth wrote:
> > Hi Chris,
> >
> > You are 100% right, and I realized after I had just it send, it was a
> > copy/paste error.
>
> No worries.  I think the problem is that bleprph is trying to allocate
> more attributes than it is configured for.  Bleprph's default
> configuration cuts it really close.  I would try increasing the
> max_attrs setting from 32 to something more comfortable (e.g., 48).
> This will give some extra room for more characteristics in the future.
> This setting is configured in main() with the following line:
>
> cfg.max_attrs = 48;
>
> Chris
>
>

Re: Problem with GATT service definition

[Christopher Collins]

On Wed, May 18, 2016 at 08:28:16PM -0700, James Howarth wrote:
> Hi Chris,
> 
> You are 100% right, and I realized after I had just it send, it was a
> copy/paste error.

No worries.  I think the problem is that bleprph is trying to allocate
more attributes than it is configured for.  Bleprph's default
configuration cuts it really close.  I would try increasing the
max_attrs setting from 32 to something more comfortable (e.g., 48).
This will give some extra room for more characteristics in the future.
This setting is configured in main() with the following line:

cfg.max_attrs = 48;

Chris

Re: Problem with GATT service definition

[James Howarth]

Hi Chris,

You are 100% right, and I realized after I had just it send, it was a
copy/paste error.

With the code you have there, I still have the issue I described - I just
copied and tested it.

Cheers
James


On Wed, May 18, 2016 at 8:23 PM, Christopher Collins 
wrote:

> Hi James,
>
> On Wed, May 18, 2016 at 07:40:50PM -0700, James Howarth wrote:
> > #define GATT_SVR_CHR_TXPWR_TXPWRLVL_SET 0x2A08
> > 
> >
> >   },
> >
> > [3] = {
> > /*** Service: TXPWR */
> > .type = BLE_GATT_SVC_TYPE_PRIMARY,
> > .uuid128 = BLE_UUID16(GATT_SVR_SVC_TXPWR_UUID),
> > .characteristics = (struct ble_gatt_chr_def[]) { {
> > .uuid128 = BLE_UUID16(GATT_SVR_CHR_TXPWR_TXPWRLVL),
> > .access_cb = gatt_svr_chr_txpwrlvl_cb,
> > .flags = BLE_GATT_CHR_F_READ,
> > }, {
> > .characteristics = (struct ble_gatt_chr_def[]) { {
> > .uuid128 = BLE_UUID16(GATT_SVR_CHR_TXPWR_TXPWRLVL_SET),
> > .access_cb = gatt_svr_chr_txpwrlvl_cb,
> > .flags = BLE_GATT_CHR_F_READ,
> > }, {
> > 0, /* No more characteristics in this service. */
> > } },
> > },
> >
> >   {
> > 0, /* No more services. */
> > },
> > };
>
> Are you sure that is the code you used?  I would not expect that to
> compile due to extra ".characteristics = ..." line.  If that is indeed
> the correct code, then try removing that line (and shame on gcc :)) as
> follows:
>
>  [3] = {
>  /*** Service: TXPWR */
>  .type = BLE_GATT_SVC_TYPE_PRIMARY,
>  .uuid128 = BLE_UUID16(GATT_SVR_SVC_TXPWR_UUID),
>  .characteristics = (struct ble_gatt_chr_def[]) { {
>  .uuid128 = BLE_UUID16(GATT_SVR_CHR_TXPWR_TXPWRLVL),
>  .access_cb = gatt_svr_chr_txpwrlvl_cb,
>  .flags = BLE_GATT_CHR_F_READ,
>  }, {
>  .uuid128 = BLE_UUID16(GATT_SVR_CHR_TXPWR_TXPWRLVL_SET),
>  .access_cb = gatt_svr_chr_txpwrlvl_cb,
>  .flags = BLE_GATT_CHR_F_READ,
>  }, {
>  0, /* No more characteristics in this service. */
>  } },
>  },
>
>{
>  0, /* No more services. */
>  },
>  };
>
> Chris
>

Problem with GATT service definition

[James Howarth]

Hi,

I am trying to create a modify the BLE GATT service TXPWR to allow me to
set the power as well as read.  Not to spec, but bear with me here.

*1)  This works: *

 },

[3] = {
/*** Service: TXPWR */
.type = BLE_GATT_SVC_TYPE_PRIMARY,
.uuid128 = BLE_UUID16(GATT_SVR_SVC_TXPWR_UUID),
.characteristics = (struct ble_gatt_chr_def[]) { {
.uuid128 = BLE_UUID16(GATT_SVR_CHR_TXPWR_TXPWRLVL),
.access_cb = gatt_svr_chr_txpwrlvl_cb,
.flags = BLE_GATT_CHR_F_READ,
}, {
0, /* No more characteristics in this service. */
} },
},

  {
0, /* No more services. */
},
};



*2)  Adding an additional characteristic to this service definition
compiles, but seems to be stuck trying to register services on an internal
loop.  *

#define GATT_SVR_CHR_TXPWR_TXPWRLVL_SET 0x2A08


  },

[3] = {
/*** Service: TXPWR */
.type = BLE_GATT_SVC_TYPE_PRIMARY,
.uuid128 = BLE_UUID16(GATT_SVR_SVC_TXPWR_UUID),
.characteristics = (struct ble_gatt_chr_def[]) { {
.uuid128 = BLE_UUID16(GATT_SVR_CHR_TXPWR_TXPWRLVL),
.access_cb = gatt_svr_chr_txpwrlvl_cb,
.flags = BLE_GATT_CHR_F_READ,
}, {
.characteristics = (struct ble_gatt_chr_def[]) { {
.uuid128 = BLE_UUID16(GATT_SVR_CHR_TXPWR_TXPWRLVL_SET),
.access_cb = gatt_svr_chr_txpwrlvl_cb,
.flags = BLE_GATT_CHR_F_READ,
}, {
0, /* No more characteristics in this service. */
} },
},

  {
0, /* No more services. */
},
};

*Here's the output out of the serial port:*

registered service 0x1800 with handle=1
4:[ts=4000ssb, mod=64 level=1] registering characteristic 0x2a00 with
def_handle=2 val_handle=3
12:[ts=12000ssb, mod=64 level=1] registering characteristic 0x2a01 with
def_handle=4 val_handle=5
22:[ts=22000ssb, mod=64 level=1] registering characteristic 0x2a02 with
def_handle=6 val_handle=7
30:[ts=3ssb, mod=64 level=1] registering characteristic 0x2a03 with
def_handle=8 val_handle=9
39:[ts=39000ssb, mod=64 level=1] registering characteristic 0x2a04 with
def_handle=10 val_handle=11
48:[ts=48000ssb, mod=64 level=1] registered service 0x1801 with handle=12
54:[ts=54000ssb, mod=64 level=1] registering characteristic 0x2a05 with
def_handle=13 val_handle=14
64:[ts=64000ssb, mod=64 level=1] registered service 0x1811 with handle=16
70:[ts=7ssb, mod=64 level=1] registering characteristic 0x2a47 with
def_handle=17 val_handle=18
79:[ts=79000ssb, mod=64 level=1] registering characteristic 0x2a46 with
def_handle=19 val_handle=20
89:[ts=89000ssb, mod=64 level=1] registering characteristic 0x2a48 with
def_handle=22 val_handle=23
97:[ts=97000ssb, mod=64 level=1] registering characteristic 0x2a45 with
def_handle=24 val_handle=25
107:[ts=107000ssb, mod=64 level=1] registering characteristic 0x2a44 with
def_handle=27 val_handle=28
116:[ts=116000ssb, mod=64 level=1] registered service 0x1804 with handle=29
122:[ts=122000ssb, mod=64 level=1] registering characteristic 0x2a07 with
0:[ts=0ssb,
mod=64 level=1] registered service 0x1800 with handle=1
4:[ts=4000ssb, mod=64 level=1] registering characteristic 0x2a00 with
def_handle=2 val_handle=3
12:[ts=12000ssb, mod=64 level=1] registering characteristic 0x2a01 with
def_handle=4 val_handle=5
22:[ts=22000ssb, mod=64 level=1] registering characteristic 0x2a02 with
def_handle=6 val_handle=7
30:[ts=3ssb, mod=64 level=1] registering characteristic 0x2a03 with
def_handle=8 val_handle=9
39:[ts=39000ssb, mod=64 level=1] registering characteristic 0x2a04 with
def_handle=10 val_handle=11
48:[ts=48000ssb, mod=64 level=1] registered service 0x1801 with handle=12
54:[ts=54000ssb, mod=64 level=1] registering characteristic 0x2a05 with
def_handle=13 val_handle=14
64:[ts=64000ssb, mod=64 level=1] registered service 0x1811 with handle=16
70:[ts=7ssb, mod=64 level=1] registering characteristic 0x2a47 with
def_handle=17 val_handle=18
79:[ts=79000ssb, mod=64 level=1] registering characteristic 0x2a46 with
def_handle=19 val_handle=20
89:[ts=89000ssb, mod=64 level=1] registering characteristic 0x2a48 with
def_handle=22 val_handle=23
97:[ts=97000ssb, mod=64 level=1] registering characteristic 0x2a45 with
def_handle=24 val_handle=25
107:[ts=107000ssb, mod=64 level=1] registering characteristic 0x2a44 with
def_handle=27 val_handle=28
116:[ts=116000ssb, mod=64 level=1] registered service 0x1804 with handle=29
122:[ts=122000ssb, mod=64 level=1] registering characteristic 0x2a07 with
0:[ts=0ssb,
mod=64 level=1] registered service 0x1800 with handle=1


Any ideas appreciated.

Cheers
James

Reboot Log

[Vipul Rahane]

Hello,

I have a rough design of the reboot log ready along with the code. It consists 
of logging the timestamp, reboot count, image version and reason.

Possible reasons:
Soft reboot: Reboot issued by the developer/user
Hard reboot: Reboot caused by loss in battery power, pulling off the plug, etc. 
Basically any reboot caused by an unknown reason.
Gen core: Reboot caused by core generated either by an assert or a core 
generate command manually by a developer/user(Future use)

Storage mechanism:

Current: Flash using fcb backend
Advantages: 
- Has an interface already, so easy to implement

Disadvantages: 
- The entire sector of the flash needs to be erased when it gets full which 
would clear the reboot log. 
- Different MCUs have different sector sizes which might/might not be available 
for use. Eg: Depending on the availability reserving 64k in the flash map 
for the system log itself sounds like a waste of flash space. 
- We cannot break the flash space into smaller chunks to be used by the fcb.
- The flash sectors that would be used would have to be specified for each 
BSP(Hard coded).

Possible solutions:

1. Flash using config backend
Advantages: 
- Has an interface as well, somewhat easy.
- Entire sector would not be needed for reserving for reboot/system log.

Disadvantages or work needed:
- New functions supporting reading old config entries(15-20) and keeping them 
around.
- A bit unusual to think about (hacky).

2. Fcb could somehow be more intelligent about underlying sectors. 
Advantages:
- Not too hacky and could be used by anyone who uses fcb.

Disadvantages:
- The way fcb is currently implemented, it takes care of very specific 
functions at a sector level and hence supports read/write/erase at a sector 
level. If we add this, it would do something more than just these basic 
functions.

I am open for both ideas. Any more ideas are welcome.

Regards,
Vipul Rahane

Re: common BSP API,

[p...@wrada.com]

Fantastic.  The more consistent this is the better.

On 5/17/16, 6:29 PM, "marko kiiskila"  wrote:

>Hi,
>
>I was chatting with Will about this offline; there¹s no header file
>describing API exported by BSPs.
>
>This includes function prototypes like os_bsp_init() (currently declared
>in libs/os), bsp_imgr_current_slot() (currently declared individually on
>every BSP¹s bsp/bsp.h), bsp_flash_dev() (currently declared in
>hal/hal_flash_int.h),
>_sbrk() (declared inside C-files, both with ones implementing the
>function,
>and the one using it).
>
>As you can see, they¹re all over.
>
>I was going to collect these under hal/hal_bsp.h.
>
>I assume this¹ll be ok for all?
>‹
>M