Re: access_cb callback not called for long (> MTU-3 bytes) characteristics

[Gilles Boccon-Gibod]

I'm at apache-mynewt-core,0.9.9.

So that's the latest. I'll try to modify bletiny as suggested earlier and
see if I can reproduce the issue in that context.

Thanks.

On Mon, Dec 5, 2016 at 4:44 PM, Sterling Hughes  wrote:

> Hi Gilles,
>
> What does your project.state file say?  If 0-latest != 0.9.9, then you
> should try newt upgrade.  Up until recently, 0-latest pointed to our 0.9
> release, but now it points to 0.9.9, which is the first beta of 1.0.
>
> If project.state says 0.9.0, then issue:
>
> newt upgrade -v
>
> And it should prompt you to upgrade.
>
> Sterling
>
>
> On 5 Dec 2016, at 16:36, Gilles Boccon-Gibod wrote:
>
> My project uses this version of mynewt:
>>
>> repository.apache-mynewt-core:
>>
>> type: github
>>
>> vers: 0-latest
>>
>> user: apache
>>
>> repo: incubator-mynewt-core
>> Is there a newer version I should try?
>>
>> -- Gilles
>>
>> On Mon, Dec 5, 2016 at 3:42 PM, Christopher Collins 
>> wrote:
>>
>> Hi Gilles,
>>>
>>> On Mon, Dec 05, 2016 at 02:57:40PM -0800, Gilles Boccon-Gibod wrote:
>>>
 I am running a simple BLE app on an nRF52 DK board.
 In it simplest mode, the app advertises a GATT server with a
 WriteNoResponse characteristic.
 When I write to this characteristic from a GATT client (a mac in my

>>> case),
>>>
 my access callback is properly invoked, and I can get the characteristic
 value when this value is "normal" (i.e no more than MTU-3 bytes).
 For testing, I set the MTU to 23 with:
 ble_att_set_preferred_mtu(23);

 I can verify that writing a 20 byte value works fine, as I get a
 callback
 with ctxt->op == BLE_GATT_ACCESS_OP_WRITE_CHR

 However, if I write a value that's 21 bytes or more, the callback is

>>> never
>>>
 invoked.
 At the GATT level, writing a long attribute involves different GATT
 commands, namely BLE_ATT_OP_PREP_WRITE_REQ and
 BLE_ATT_OP_EXEC_WRITE_REQ,
 instead of the one-shot BLE_ATT_OP_WRITE_REQ.
 If I enable DEBUG logging, I can see that the BLE_ATT_OP_EXEC_WRITE_REQ

>>> is
>>>
 received and processed, but there's no callback to my code.

>>>
>>> Unfortunately, I can't seem to replicate that behavior.  Which version
>>> of Mynewt are you using?  I tested this with the develop branch.  The
>>> latest official release (0.9.0) is quite old, so I am a little less
>>> confident about that one :).
>>>
>>> To test this, I used the bletiny sample app with the following
>>> modifictions:
>>> * Increase size of the "Security test, static value" characteristic
>>>   to 40 bytes (was: 1 byte).
>>> * Change this characteristics flags to:
>>> BLE_GATT_CHR_F_READ | BLE_GATT_CHR_F_WRITE_NO_RSP
>>>   (was:
>>> BLE_GATT_CHR_F_READ | BLE_GATT_CHR_F_WRITE |
>>> BLE_GATT_CHR_F_WRITE_ENC)
>>>
>>> Here is the procedure I used:
>>> * Set preferred MTU on both devices to 23.
>>> * Peripheral begins advertising.
>>> * Central connects.
>>> * Central initiates MTU negotiation.
>>> * Central performs a 40-byte long write
>>>
>>> Here is the GDB backtrace on the peripheral showing the callback getting
>>> executed:
>>>
>>> #0  gatt_svr_chr_access_sec_test (conn_handle=1, attr_handle=33,
>>> ctxt=0x2f80 , arg=0x0) at gatt_svr.c:218
>>> #1  0x000144b6 in ble_gatts_val_access (conn_handle=,
>>> attr_handle=, offset=,
>>> gatt_ctxt=0x2f80 , om=0x2fe0
>>> , access_cb=0xad35 ,
>>> cb_arg=0x0)
>>> at ble_gatts.c:348
>>> #2  0x000144fc in ble_gatts_chr_val_access (conn_handle=,
>>> attr_handle=, att_op=, offset=>> out>,
>>> om=0x2fe0 , arg=0x24bc
>>> <__compound_literal.7+24>) at ble_gatts.c:374
>>> #3  0xf41c in ble_att_svr_write (conn_handle=conn_handle@entry=1,
>>> entry=, om=om@entry=0x2fe0 ,
>>> out_att_err=out_att_err@entry=0x2fdb  "",
>>> offset=0) at ble_att_svr.c:527
>>> #4  0x000107de in ble_att_svr_prep_write (err_handle=,
>>> prep_list=0x2fdc , conn_handle=1)
>>> at ble_att_svr.c:2371
>>> #5  ble_att_svr_rx_exec_write (conn_handle=,
>>> rxom=) at ble_att_svr.c:2608
>>> #6  0xda88 in ble_att_rx (conn_handle=, om=0x2000102c
>>> ) at ble_att.c:461
>>> #7  0x00016dfc in ble_hs_hci_evt_acl_process (om=0x0) at
>>> ble_hs_hci_evt.c:664
>>> #8  0x0001524e in ble_hs_process_rx_data_queue () at ble_hs.c:199
>>> #9  0xbcbe in os_eventq_run (evq=evq@entry=0x200035b8 )
>>> at os_eventq.c:147
>>> #10 0x81ec in bletiny_task_handler (arg=) at
>>> main.c:1556
>>> #11 0x in ?? ()
>>>
>>> Here is the bletiny log on the peripheral (there was some contention for
>>> the console buffer in the middle so part of it looks garbled):
>>>
>>>
>>> b set mtu=23
>>> b set addr=0a:45:00:11:22:33
>>> b set adv_data uuid16=0x1811 name=micosa-1 

access_cb callback not called for long (> MTU-3 bytes) characteristics

[Gilles Boccon-Gibod]

I am running a simple BLE app on an nRF52 DK board.
In it simplest mode, the app advertises a GATT server with a
WriteNoResponse characteristic.
When I write to this characteristic from a GATT client (a mac in my case),
my access callback is properly invoked, and I can get the characteristic
value when this value is "normal" (i.e no more than MTU-3 bytes).
For testing, I set the MTU to 23 with:
ble_att_set_preferred_mtu(23);

I can verify that writing a 20 byte value works fine, as I get a callback
with ctxt->op == BLE_GATT_ACCESS_OP_WRITE_CHR

However, if I write a value that's 21 bytes or more, the callback is never
invoked.
At the GATT level, writing a long attribute involves different GATT
commands, namely BLE_ATT_OP_PREP_WRITE_REQ and BLE_ATT_OP_EXEC_WRITE_REQ,
instead of the one-shot BLE_ATT_OP_WRITE_REQ.
If I enable DEBUG logging, I can see that the BLE_ATT_OP_EXEC_WRITE_REQ is
received and processed, but there's no callback to my code.

Here's what the log looks like (this is for a 21 bytes value, with the MTU
set at 23):

1687:[ts=13179676ssb, mod=64 level=1] mtu update event; conn_handle=1 cid=4
mtu=23

...


58955:[ts=460585900ssb, mod=4 level=0] ble_hs_hci_evt_acl_process():
handle=1 pb=2 len=27 data=
0x17 0x00 0x04 0x00 0x16 0x16 0x00 0x00 0x00 0x01 0x02 0x03 0x04 0x05 0x06
0x07 0x08 0x09 0x0a
0x0b 0x0c 0x0d 0x0e 0x0f 0x10 0x11 0x12
58961:[ts=460632772ssb, mod=4 level=0] rxed att command: prep write req;
conn=1 handle=0x0016 o
ffset=0
58963:[ts=460648396ssb, mod=4 level=0] txed att command: prep write rsp;
conn=1 handle=0x0016 o
ffset=0
58966:[ts=460671832ssb, mod=4 level=0] host tx hci data; handle=1 length=27
58968:[ts=460687456ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x1b
0x00 0x17 0x00 0x04
0x00 0x17 0x16 0x00 0x00 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
0x0a 0x0b 0x0c 0x0d
0x0e 0x0f 0x10 0x11 0x12
58976:[ts=460749952ssb, mod=4 level=0] ble_hs_hci_evt_acl_process():
handle=1 pb=2 len=6 data=0
x02 0x00 0x04 0x00 0x18 0x00
58979:[ts=460773388ssb, mod=4 level=0] rxed att command: exec write req;
conn=1 flags=0x00
58981:[ts=460789012ssb, mod=4 level=0] host tx hci data; handle=1 length=5
58983:[ts=460804636ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x05
0x00 0x01 0x00 0x04
0x00 0x19
58986:[ts=460828072ssb, mod=4 level=0] Number of Completed Packets:
num_handles=1
58988:[ts=460843696ssb, mod=4 level=0] handle:1 pkts:1
58991:[ts=460867132ssb, mod=4 level=0] Number of Completed Packets:
num_handles=1
58993:[ts=460882756ssb, mod=4 level=0] handle:1 pkts:1

Re: [VOTE] Release Apache Mynewt 1.0.0-b1-incubating-rc2

[Christopher Collins]

(The email I'm responding is from general@. I'm replying in dev@, as all
my comments concern Mynewt specifically.  For those who don't follow
general@, in the original email, Justin voted +1 on 1.0.0-b1-rc2, but he
raised a few issues that I believe warrant a closer look.)

Hi Justin,

Thanks for taking a look.  I want to address the three issues you
raised.  I reordered them slightly, as issues 1 and 3 are closely
related.

On Mon, Dec 05, 2016 at 11:58:58AM +1100, Justin Mclean wrote:
[...]
> A couple of minor things re compilation which other people may run into:
> 1. It would be good to have better compile instructions especially for the 
> core package. 
> 3. A newt build all in core does nothing, but a newt test all goes off and 
> compiles and runs the tests. Is that expected? How do you just build core?

Yes - I believe this has been a point of confusion in some earlier
releases as well.  I think Mynewt might be atypical this regard, and
we should address this in the core README file.  Specifically, core is
not something that can be built directly; it is a collection of
libraries and sample applications that a user's project depends on.

The "newt build all" command doesn't do anything in a bare
apache-mynewt-core repo because there are no targets to build.  A target
is the top-level Mynewt entity that actually gets built; it ties a BSP
and an application together.  To get started, a user should also acquire
the blinky repository by using the "newt new" command.  Blinky includes
a sample target for running the blinky application in a simulated
environment.

For the next release, I think we should clarify this in the core README
file.  We should make it very clear to the user what they have
downloaded, and indicate how to proceed.

> 2. It seems that blinky expects gcc-5 in /usr/local/bin/ and I only had gcc-6 
> installed and an older version of gcc in /usr/bin/gcc

Hmm, this is indeed a problem.  On OS X, /usr/bin/gcc is not actually
gcc; it's clang.  I don't recall the details, but I believe there was a
time when clang was incompatible with Mynewt.  "gcc-5" is the name of
the gcc 5.x binary that home brew installs, so that is what newt looks
for.

I just tried running "newt test all" using clang, and it mostly works.
There are a few warnings that get reported, but they should be easy to
fix.  My thought it is that we should fix the warnings and change the
compiler definition such that the "gcc" binary (i.e., clang) is used in
OS X.  It's unfortunate that this ambiguity exists, but I think it's
preferable to just use clang than to impose these gcc version headaches
on the user.

Thanks,
Chris

Re: MBEDTLS Error after 'newt install -v'

[Kevin Townsend]

Updating the project.yml file to point to 0.0.1 resolved this, and a 
clean setup now pulls master instead of develop.


I agree minimum version checks would be extremely useful, though, since 
the newt/newtmgr tools and apache-mynewt-core are quite tightly coupled.



On 05/12/16 18:29, Kevin Townsend wrote:

Hi Chris,

Thanks for the reply. I usually pull the tools and mynewt core at the 
same time. We're running the latest version of both repos from master, 
or at least that's what I thought ... it seems when I did a 'newt 
install -v' we ended up in 'develop' in repos/apache-mynewt-core


This is most likely an artifact with our local mynewt project.yml or 
project.state file or something similar in our internal repo:


repository.apache-mynewt-core:
type: github
vers: 0-dev
user: apache
repo: incubator-mynewt-core

Apparently this should be 0.0.1 now? 
https://github.com/apache/incubator-mynewt-core/blob/master/repository.yml


K.


On 05/12/16 18:24, Christopher Collins wrote:

Hi Kevin,

This issue tends to happen if you are using a version of newt that is
incompatible with your core repo.  You mentioned you are using the
master branch of core; is it possible that you are using develop of the
newt repo?

Specifically, I think this issue is caused by this commit from last
week (newt repo): 0241d2f38e8236f03d6f20d5c7198d4a0a4cb169

I mentioned in an email last week that newt and core would need to be
upgraded together after this change.  Emails like that aren't
particularly useful, because they are only interesting to people who are
already experiencing issues!

One feature that newt needs is the ability to require minimum versions
of the core repo.  Then, compatibility-breaking changes would still be a
nuissance, but at least it would be obvious what the problem is.

Chris

On Mon, Dec 05, 2016 at 06:11:24PM +0100, Kevin Townsend wrote:
I was updating some local dev systems, and with a clean install and 
then

running 'newt install -v' we now get the following error when we try to
build the bootloader:

/LOCAL_FOLDER/repos/apache-mynewt-core/crypto/mbedtls/include/mbedtls/config.h:2522:10: 


error: #include expects "FILENAME" or 
   #include MBEDTLS_USER_CONFIG_FILE
^

This is new, but unexpected since nothing has changed in the last week
or so in the master branch of the repo, and the last change to 'boot'
was 26 days ago so I'm not missing something in our local slightly
modified bootloader code.

Has something recently changed with the mbedtls library that I'm not
seeing quickly looking at the git history in master?

Just commenting the offending line out causes problems elsewhere so
there seems to be a missing config file:

https://github.com/apache/incubator-mynewt-core/blob/master/crypto/mbedtls/include/mbedtls/config.h#L2522 



 #if defined(YOTTA_CFG_MBEDTLS_USER_CONFIG_FILE)
 #include YOTTA_CFG_MBEDTLS_USER_CONFIG_FILE
 #elif defined(MBEDTLS_USER_CONFIG_FILE)
 //#include MBEDTLS_USER_CONFIG_FILE
 #endif

That just kicks the problems further down the field:

 ctr_drbg.c:425:5: error: implicit declaration of function 'fopen'
 [-Werror=implicit-function-declaration]
   if( ( f = fopen( path, "wb" ) ) == NULL )
   ^
 ctr_drbg.c:425:13: error: assignment makes pointer from integer
 without a cast [-Werror]
   if( ( f = fopen( path, "wb" ) ) == NULL )
   ^
 ctr_drbg.c:440:5: error: implicit declaration of function 'fclose'
 [-Werror=implicit-function-declaration]
   fclose( f );
   ^
 ctr_drbg.c: In function 'mbedtls_ctr_drbg_update_seed_file':
 ctr_drbg.c:450:13: error: assignment makes pointer from integer
 without a cast [-Werror]
   if( ( f = fopen( path, "rb" ) ) == NULL )
   ^
 ctr_drbg.c:453:5: error: implicit declaration of function 'fseek'
 [-Werror=implicit-function-declaration]
   fseek( f, 0, SEEK_END );
   ^
 ctr_drbg.c:453:18: error: 'SEEK_END' undeclared (first use in this
 function)
   fseek( f, 0, SEEK_END );
^
 ctr_drbg.c:453:18: note: each undeclared identifier is reported 
only

 once for each function it appears in
 ctr_drbg.c:454:5: error: implicit declaration of function 'ftell'
 [-Werror=implicit-function-declaration]
   n = (size_t) ftell( f );
   ^
 ctr_drbg.c:455:18: error: 'SEEK_SET' undeclared (first use in this
 function)
   fseek( f, 0, SEEK_SET );
^
 cc1: all warnings being treated as errors

Any idea what might be causing the issue here? I'm looking at the
mbedtls source and don't see any recent pushes there, etc.

Re: MBEDTLS Error after 'newt install -v'

[Kevin Townsend]

Hi Chris,

Thanks for the reply. I usually pull the tools and mynewt core at the 
same time. We're running the latest version of both repos from master, 
or at least that's what I thought ... it seems when I did a 'newt 
install -v' we ended up in 'develop' in repos/apache-mynewt-core


This is most likely an artifact with our local mynewt project.yml or 
project.state file or something similar in our internal repo:


repository.apache-mynewt-core:
type: github
vers: 0-dev
user: apache
repo: incubator-mynewt-core

Apparently this should be 0.0.1 now? 
https://github.com/apache/incubator-mynewt-core/blob/master/repository.yml


K.


On 05/12/16 18:24, Christopher Collins wrote:

Hi Kevin,

This issue tends to happen if you are using a version of newt that is
incompatible with your core repo.  You mentioned you are using the
master branch of core; is it possible that you are using develop of the
newt repo?

Specifically, I think this issue is caused by this commit from last
week (newt repo): 0241d2f38e8236f03d6f20d5c7198d4a0a4cb169

I mentioned in an email last week that newt and core would need to be
upgraded together after this change.  Emails like that aren't
particularly useful, because they are only interesting to people who are
already experiencing issues!

One feature that newt needs is the ability to require minimum versions
of the core repo.  Then, compatibility-breaking changes would still be a
nuissance, but at least it would be obvious what the problem is.

Chris

On Mon, Dec 05, 2016 at 06:11:24PM +0100, Kevin Townsend wrote:

I was updating some local dev systems, and with a clean install and then
running 'newt install -v' we now get the following error when we try to
build the bootloader:

/LOCAL_FOLDER/repos/apache-mynewt-core/crypto/mbedtls/include/mbedtls/config.h:2522:10:
error: #include expects "FILENAME" or 
   #include MBEDTLS_USER_CONFIG_FILE
^

This is new, but unexpected since nothing has changed in the last week
or so in the master branch of the repo, and the last change to 'boot'
was 26 days ago so I'm not missing something in our local slightly
modified bootloader code.

Has something recently changed with the mbedtls library that I'm not
seeing quickly looking at the git history in master?

Just commenting the offending line out causes problems elsewhere so
there seems to be a missing config file:

https://github.com/apache/incubator-mynewt-core/blob/master/crypto/mbedtls/include/mbedtls/config.h#L2522

 #if defined(YOTTA_CFG_MBEDTLS_USER_CONFIG_FILE)
 #include YOTTA_CFG_MBEDTLS_USER_CONFIG_FILE
 #elif defined(MBEDTLS_USER_CONFIG_FILE)
 //#include MBEDTLS_USER_CONFIG_FILE
 #endif

That just kicks the problems further down the field:

 ctr_drbg.c:425:5: error: implicit declaration of function 'fopen'
 [-Werror=implicit-function-declaration]
   if( ( f = fopen( path, "wb" ) ) == NULL )
   ^
 ctr_drbg.c:425:13: error: assignment makes pointer from integer
 without a cast [-Werror]
   if( ( f = fopen( path, "wb" ) ) == NULL )
   ^
 ctr_drbg.c:440:5: error: implicit declaration of function 'fclose'
 [-Werror=implicit-function-declaration]
   fclose( f );
   ^
 ctr_drbg.c: In function 'mbedtls_ctr_drbg_update_seed_file':
 ctr_drbg.c:450:13: error: assignment makes pointer from integer
 without a cast [-Werror]
   if( ( f = fopen( path, "rb" ) ) == NULL )
   ^
 ctr_drbg.c:453:5: error: implicit declaration of function 'fseek'
 [-Werror=implicit-function-declaration]
   fseek( f, 0, SEEK_END );
   ^
 ctr_drbg.c:453:18: error: 'SEEK_END' undeclared (first use in this
 function)
   fseek( f, 0, SEEK_END );
^
 ctr_drbg.c:453:18: note: each undeclared identifier is reported only
 once for each function it appears in
 ctr_drbg.c:454:5: error: implicit declaration of function 'ftell'
 [-Werror=implicit-function-declaration]
   n = (size_t) ftell( f );
   ^
 ctr_drbg.c:455:18: error: 'SEEK_SET' undeclared (first use in this
 function)
   fseek( f, 0, SEEK_SET );
^
 cc1: all warnings being treated as errors

Any idea what might be causing the issue here? I'm looking at the
mbedtls source and don't see any recent pushes there, etc.

Re: MBEDTLS Error after 'newt install -v'

[Christopher Collins]

Hi Kevin,

This issue tends to happen if you are using a version of newt that is
incompatible with your core repo.  You mentioned you are using the
master branch of core; is it possible that you are using develop of the
newt repo?

Specifically, I think this issue is caused by this commit from last
week (newt repo): 0241d2f38e8236f03d6f20d5c7198d4a0a4cb169

I mentioned in an email last week that newt and core would need to be
upgraded together after this change.  Emails like that aren't
particularly useful, because they are only interesting to people who are
already experiencing issues!

One feature that newt needs is the ability to require minimum versions
of the core repo.  Then, compatibility-breaking changes would still be a
nuissance, but at least it would be obvious what the problem is.

Chris

On Mon, Dec 05, 2016 at 06:11:24PM +0100, Kevin Townsend wrote:
> I was updating some local dev systems, and with a clean install and then 
> running 'newt install -v' we now get the following error when we try to 
> build the bootloader:
> 
> /LOCAL_FOLDER/repos/apache-mynewt-core/crypto/mbedtls/include/mbedtls/config.h:2522:10:
>  
> error: #include expects "FILENAME" or 
>   #include MBEDTLS_USER_CONFIG_FILE
>^
> 
> This is new, but unexpected since nothing has changed in the last week 
> or so in the master branch of the repo, and the last change to 'boot' 
> was 26 days ago so I'm not missing something in our local slightly 
> modified bootloader code.
> 
> Has something recently changed with the mbedtls library that I'm not 
> seeing quickly looking at the git history in master?
> 
> Just commenting the offending line out causes problems elsewhere so 
> there seems to be a missing config file:
> 
> https://github.com/apache/incubator-mynewt-core/blob/master/crypto/mbedtls/include/mbedtls/config.h#L2522
> 
> #if defined(YOTTA_CFG_MBEDTLS_USER_CONFIG_FILE)
> #include YOTTA_CFG_MBEDTLS_USER_CONFIG_FILE
> #elif defined(MBEDTLS_USER_CONFIG_FILE)
> //#include MBEDTLS_USER_CONFIG_FILE
> #endif
> 
> That just kicks the problems further down the field:
> 
> ctr_drbg.c:425:5: error: implicit declaration of function 'fopen'
> [-Werror=implicit-function-declaration]
>   if( ( f = fopen( path, "wb" ) ) == NULL )
>   ^
> ctr_drbg.c:425:13: error: assignment makes pointer from integer
> without a cast [-Werror]
>   if( ( f = fopen( path, "wb" ) ) == NULL )
>   ^
> ctr_drbg.c:440:5: error: implicit declaration of function 'fclose'
> [-Werror=implicit-function-declaration]
>   fclose( f );
>   ^
> ctr_drbg.c: In function 'mbedtls_ctr_drbg_update_seed_file':
> ctr_drbg.c:450:13: error: assignment makes pointer from integer
> without a cast [-Werror]
>   if( ( f = fopen( path, "rb" ) ) == NULL )
>   ^
> ctr_drbg.c:453:5: error: implicit declaration of function 'fseek'
> [-Werror=implicit-function-declaration]
>   fseek( f, 0, SEEK_END );
>   ^
> ctr_drbg.c:453:18: error: 'SEEK_END' undeclared (first use in this
> function)
>   fseek( f, 0, SEEK_END );
>^
> ctr_drbg.c:453:18: note: each undeclared identifier is reported only
> once for each function it appears in
> ctr_drbg.c:454:5: error: implicit declaration of function 'ftell'
> [-Werror=implicit-function-declaration]
>   n = (size_t) ftell( f );
>   ^
> ctr_drbg.c:455:18: error: 'SEEK_SET' undeclared (first use in this
> function)
>   fseek( f, 0, SEEK_SET );
>^
> cc1: all warnings being treated as errors
> 
> Any idea what might be causing the issue here? I'm looking at the 
> mbedtls source and don't see any recent pushes there, etc.
> 

Re: MBEDTLS Error after 'newt install -v'

[Kevin Townsend]

Just as a follow up, for some reason a clean install set me to 'develop' 
not 'master', though it isn't clear to me why yet ... but this resolves 
the issue with the missing config file:


 * cd repos
 * cd apache-mynewt-core
 * git branch # To show that I'm on develop not master which is what I
   expected (could be a local issue on my end!)
 * git checkout master
 * cd ../..
 * newt build bootloader


On 05/12/16 18:11, Kevin Townsend wrote:


I was updating some local dev systems, and with a clean install and 
then running 'newt install -v' we now get the following error when we 
try to build the bootloader:


/LOCAL_FOLDER/repos/apache-mynewt-core/crypto/mbedtls/include/mbedtls/config.h:2522:10: 
error: #include expects "FILENAME" or 

 #include MBEDTLS_USER_CONFIG_FILE
  ^

This is new, but unexpected since nothing has changed in the last week 
or so in the master branch of the repo, and the last change to 'boot' 
was 26 days ago so I'm not missing something in our local slightly 
modified bootloader code.


Has something recently changed with the mbedtls library that I'm not 
seeing quickly looking at the git history in master?


Just commenting the offending line out causes problems elsewhere so 
there seems to be a missing config file:


https://github.com/apache/incubator-mynewt-core/blob/master/crypto/mbedtls/include/mbedtls/config.h#L2522

#if defined(YOTTA_CFG_MBEDTLS_USER_CONFIG_FILE)
#include YOTTA_CFG_MBEDTLS_USER_CONFIG_FILE
#elif defined(MBEDTLS_USER_CONFIG_FILE)
//#include MBEDTLS_USER_CONFIG_FILE
#endif

That just kicks the problems further down the field:

ctr_drbg.c:425:5: error: implicit declaration of function 'fopen'
[-Werror=implicit-function-declaration]
 if( ( f = fopen( path, "wb" ) ) == NULL )
 ^
ctr_drbg.c:425:13: error: assignment makes pointer from integer
without a cast [-Werror]
 if( ( f = fopen( path, "wb" ) ) == NULL )
 ^
ctr_drbg.c:440:5: error: implicit declaration of function 'fclose'
[-Werror=implicit-function-declaration]
 fclose( f );
 ^
ctr_drbg.c: In function 'mbedtls_ctr_drbg_update_seed_file':
ctr_drbg.c:450:13: error: assignment makes pointer from integer
without a cast [-Werror]
 if( ( f = fopen( path, "rb" ) ) == NULL )
 ^
ctr_drbg.c:453:5: error: implicit declaration of function 'fseek'
[-Werror=implicit-function-declaration]
 fseek( f, 0, SEEK_END );
 ^
ctr_drbg.c:453:18: error: 'SEEK_END' undeclared (first use in this
function)
 fseek( f, 0, SEEK_END );
  ^
ctr_drbg.c:453:18: note: each undeclared identifier is reported
only once for each function it appears in
ctr_drbg.c:454:5: error: implicit declaration of function 'ftell'
[-Werror=implicit-function-declaration]
 n = (size_t) ftell( f );
 ^
ctr_drbg.c:455:18: error: 'SEEK_SET' undeclared (first use in this
function)
 fseek( f, 0, SEEK_SET );
  ^
cc1: all warnings being treated as errors

Any idea what might be causing the issue here? I'm looking at the 
mbedtls source and don't see any recent pushes there, etc.

Re: Newbie & running into an error during setup

[Fabio Utzig]

On Sun, Dec 4, 2016, at 10:55 PM, Mohammad Afaneh wrote:
> Thanks, Chris.
> 
> I'm running:
> - OS X 10.12.1 (macOS Sierra)

Hi Mohammad,

Not sure you are aware but you can build newt/mynewt on OS X too. I'm
myself using Sierra for development. You just need to install some
dependencies like go and gcc-arm-embedded. Easily done with homebrew:

$ brew install go
$ brew cask install gcc-arm-embedded

Cheers,
Fabio Utzig