Date   

Re: Using SPI_SLAVE on STM32

Armando Visconti
 

Hello Thomasz,

Quick update before leaving for the week.

I took the patches suggested by you and I prepared
a very simple test environment. I have an issue
though: it seems that I'm not able to consume data
at the proper speed and OVR error is found in SR.

Just for testing I tried to comment the error out and
what I see is that I receive 1 byte evry 3.

I think I can slow down the spi master, but I think that
we would need to add DMA handling to stm32 spi. Is there
any plan?

Thanks,
Armando

On 05/04/2018 03:00 PM, Tomasz Bursztyka wrote:
It has not been rebased against latest SPI API changes, thus why it
can't be merged. But it's a fine PR besides that.
Tomasz

Thx Tomasz,

On 05/04/2018 02:08 PM, Tomasz Bursztyka wrote:
Hi,

Check this PR: https://github.com/zephyrproject-rtos/zephyr/pull/52
00
You probably need the first patch, and the second is an example how
to
do it. Note however the API has changed a bit, you'll have to
check.
It seems quite old. Why hasn't it been merged yet?
Is there something wrong that prevent it?





Re: IPv6 addresses

Diana Rivera
 

Hi Jukka,

Thanks for your answer. If SLAAC is enabled by default, how are you then able to know the device's IPv6 address so that so that it can be set as the PEER_ADDR of another device?

I've been also trying to run the OpenThread shell by simply enabling CONFIG_OPENTHREAD_SHELL=y in the Kconfig file, but it doesn't seem to be having any effect. What is the proper way to run this shell?

Once again. Thank you for your answer.

Best regards,
Diana


Re: problems building a BME680 app: zephyr_prebuilt.elf uses VFP register arguments ....

Abderrezak Mekkaoui <ab.mekka@...>
 

Hi All,

Just in case this is helpful. To build and correctly run my app, I needed to add the following configuration variables to my prj.conf:

CONFIG_FLOAT=y
CONFIG_NEWLIB_LIBC=y

Nothing else is needed because everything is defined with the board (nrf52840_pca10056).

Adding CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y would enable float fprinting for debugging.
Thanks for your help.
Abderrezak

On 5/7/2018 12:04 PM, Abderrezak Mekkaoui wrote:
Hi All,
I am having problems porting a BME680 app to Zephyr. This app uses a pre-compiled library (libalgobsec.a) provided by Bosch.
It builds and runs correctly on mynewt (using the exact same tool chain and the same flags). After solving few issues related to stdint I am struggling with the last issues possibly related incompatibilities between different libraries.
I think I am using the right compiler and linker flags (see below) but I may be wrong.
Any hints/help would be greatly appreciated.
Regards
Abderrezak

P.S. I have other apps that  build and run correctly using the same tool chain (but use the default zephyr flags and have no need for an external binary library). I am using a custom nrf52840 based board.



###########################################################################################################################################################
CMakelists.txt (latest flag settings, many other combinations all failed)

target_link_libraries(app libalgobsec.a)
target_link_libraries(app libm.a)

set(FPU_FOR_cortex-m4      fpv4-sp-d16)
target_link_libraries(app m.a)
zephyr_cc_option(-DFLOAT_ABI_HARD -mcpu=cortex-m4 -mthumb-interwork -mthumb -mabi=aapcs -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fno-exceptions -ffunction-sections -fdata-sections )
zephyr_ld_options(-static -specs=nosys.specs -lgcc -Wl,--gc-sections -nostartfiles -mthumb -mabi=aapcs -mfloat-abi=hard -mfpu=fpv4-sp-d16 -DFLOAT_ABI_HARD -lalgobsec -lm)
#

###########################################################################################################################################################
Error messages (only few lines)

/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_popcountsi2.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_popcountsi2.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_udivmoddi4.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/program files (x86)/gnu tools arm embedded/7.0 2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/thumb/v7e-m\libgcc.a(_udivmoddi4.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp2_data.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_exp2_data.o)
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: zephyr\zephyr_prebuilt.elf uses VFP register arguments, c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_fabs.o) does not
c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific data of file c:/progra~2/gnutoo~1/70922~1.020/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib\libm.a(lib_a-sf_fabs.o)


Re: IPv6 addresses

Jukka Rissanen
 

Hi Diana,

the static IP address configuration is fully optional and is only meant
to make testing a bit easier. So if you want to have auto IPv6
addresses, then just do not set CONFIG_NET_APP_MY_IPV6_ADDR option.

SLAAC is enabled by default. Please create a github issue if you find
bugs in it.


Cheers,
Jukka

On Fri, 2018-05-11 at 11:39 +0200, Diana Rivera wrote:
Hello,

I am currently working on an OpenThread application based on
echo_client and echo_server. I have noticed that the devices' IPv6
addresses are set in the configuration file through
CONFIG_NET_APP_MY_IPV6_ADDR.
I was wondering if there is another way to set the devices' IPv6
addresses without having to modify the configuration file every time?

Zephyr's documentation mentions the possibility to use SLAAC. Could
you please point me in the right direction to use it instead of
having to set static IPv6 addresses?

Thank you in advance,
Diana


IPv6 addresses

Diana Rivera
 

Hello,

I am currently working on an OpenThread application based on echo_client and echo_server. I have noticed that the devices' IPv6 addresses are set in the configuration file through CONFIG_NET_APP_MY_IPV6_ADDR.
I was wondering if there is another way to set the devices' IPv6 addresses without having to modify the configuration file every time?

Zephyr's documentation mentions the possibility to use SLAAC. Could you please point me in the right direction to use it instead of having to set static IPv6 addresses?

Thank you in advance,
Diana


Re: Read connection RSSI always return -127

Carles Cufi
 

Hi there,

 

Strange, this should work as expected. I haven’t tested it myself but will do if you cannot figure it out.

 

Have you enabled the CONFIG_BT_CTLR_CONN_RSSI option in Kconfig?

 

Regards,

 

Carles

 

From: devel@... <devel@...> On Behalf Of ???
Sent: 10 May 2018 03:35
To: devel@...
Subject: [Zephyr-devel] Read connection RSSI always return -127

 

Hello,

I wrote the same question on user forum but haven't got any response so I'm writing this on devel forum, too.

I'm developing HCI UART dongle using nRF52840 based on Zephyr v1.11 branch.
Everything works fine now except for reading RSSI on connected device.

HCI commands were successfully executed but always return -127.

< HCI Command: Read RSSI (0x05|0x0005) plen 2            #488 [hci1] 620.325803
        Handle: 0
> HCI Event: Command Complete (0x0e) plen 7              #489 [hci1] 620.326563
      Read RSSI (0x05|0x0005) ncmd 1
        Status: Success (0x00)
        Handle: 0
        RSSI: -127 dBm (0x81)

It is the same on nRF52840_pca10056 reference board.

Here are contents of prj.conf file.

CONFIG_CONSOLE=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_NRF5_BAUD_RATE=1000000
CONFIG_UART_NRF5_FLOW_CONTROL=y
CONFIG_MAIN_STACK_SIZE=512
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512
CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=16
CONFIG_BT_TINYCRYPT_ECC=y
CONFIG_BT_CTLR_DTM_HCI=y
CONFIG_BT_CTLR_ASSERT_HANDLER=n
CONFIG_BT_HCI_ACL_FLOW_CONTROL=y
CONFIG_BT_CTLR_DATA_LENGTH=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_GPIO_LNA=y
CONFIG_BT_CTLR_GPIO_LNA_PIN=28
CONFIG_BT_CTLR_GPIO_PA=y
CONFIG_BT_CTLR_GPIO_PA_PIN=3
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_CONN_RSSI=y

Is there anything that I need to configure in project setting?

Regards,

Hyoungwook Jeon

 


Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Johan Hedberg
 

Hi Kai,

Please check the PR I referenced earlier. I've added a patch there to
convert mesh_demo to use settings. It was actually the other way around
that it made sense to do the calls: first settings_load() and then
bt_mesh_provision(). That way we can catch an -EALREADY return from
bt_mesh_provision() which tells us that calling configure() should not
be done.

Johan

On Fri, May 11, 2018, Kai Ren wrote:
Thanks for the reply!

The problem I suffered is that: when I run mesh_demo on microbit, I can't restore SEQ after a reset, when means that if a GenericOnOff client reset unexpected, I need to make this client catch up the SEQ on GenericOnOff server. 

I saw that there are two functions which seem to be store and restore SEQ,

void board_seq_update( u32_t seq);

static u32_t get_seq( void );

but get_seq() is called in board initial, but I don't find any piece about board_seq_update().

I agree with you, mesh_demo doesn't need persistent storage because its netkey, devkey and appkey are already in flash memory, but one thing need to be solved is SEQ. 


Also, if you run it on the BBC micro:bit be sure to remove
the direct flash access from src/microbit.c.
What does it mean? 

Kai


Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Kai Ren
 

Thanks for the reply!

The problem I suffered is that: when I run mesh_demo on microbit, I can't restore SEQ after a reset, when means that if a GenericOnOff client reset unexpected, I need to make this client catch up the SEQ on GenericOnOff server. 

I saw that there are two functions which seem to be store and restore SEQ,

void board_seq_update(u32_t seq);

static u32_t get_seq(void);

but get_seq() is called in board initial, but I don't find any piece about board_seq_update().

I agree with you, mesh_demo doesn't need persistent storage because its netkey, devkey and appkey are already in flash memory, but one thing need to be solved is SEQ. 
Also, if you run it on the BBC micro:bit be sure to remove
the direct flash access from src/microbit.c.
What does it mean? 

Kai




Re: #BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Johan Hedberg
 

Hi Kai,

On Fri, May 11, 2018, Kai Ren wrote:
I noticed that zephyr start to support persistent storage for
provisioning data like:
{ "Net", net_set },
{ "IV", iv_set },
{ "Seq", seq_set },
{ "RPL", rpl_set },
{ "NetKey", net_key_set },
{ "AppKey", app_key_set },
Also note that the remaining state storing is coming as part of the
following PR:

https://github.com/zephyrproject-rtos/zephyr/pull/7428

Essentially everything is in place there now, but I still need to think
a little about how to handle IV Update - we may need to store in some
circumstances information about how many hours the node has been in a
certain state.

And I know that it's already added in the sample of
./sample/bluetooth/mesh/, I know that this sample need a provisioner
to provision it. I'm curious that does the persistent storage function
can be used by the sample of ./sample/bluetooth/mesh_demo/ because
this sample is an example of self-provisioning.
I think there might be some conflicts, or at least interesting
artifacts, since mesh_demo calls itself bt_mesh_provision() and
restoring values from flash does essentially the same thing. That said,
I'm not sure what the benefit would be? Perhaps to restore the Seq and
RPL? You could try it, but be sure to call settings_load() only after
bt_mesh_provision() so that stored values overwrite the ones hard-coded
in the app. Also, if you run it on the BBC micro:bit be sure to remove
the direct flash access from src/microbit.c.

Johan


#BluetoothMesh persistent storage for provisioning data #bluetoothmesh

Kai Ren
 

Hello,

I noticed that zephyr start to support persistent storage for provisioning data like:
{ "Net", net_set },
{ "IV", iv_set },
{ "Seq", seq_set },
{ "RPL", rpl_set },
{ "NetKey", net_key_set },
{ "AppKey", app_key_set },

And I know that it's already added in the sample of ./sample/bluetooth/mesh/, I know that this sample need a provisioner to provision it. I'm curious that does the persistent storage function can be used by the sample of ./sample/bluetooth/mesh_demo/ because this sample is an example of self-provisioning.
Thanks.

Regards,
Kai


Re: Can't download in chuncks using https

christian tavares
 

I was able to resolve this problem by configuring the server to send smaller fragments than it was sending


Re: new PR adding initial dts support for nrf52 gpio, needs reviewer(s)

Carles Cufi
 

Hi Marc,

 

Thanks very much for your PR. Since you cannot add reviewers yourself I have added them for you.

 

Regards,

 

Carles

 

From: <devel@...> on behalf of Marc Reilly <marc.reilly@...>
Date: Thursday, 10 May 2018 at 10:28
To: "devel@..." <devel@...>
Subject: [Zephyr-devel] new PR adding initial dts support for nrf52 gpio, needs reviewer(s)

 

Hi,

I've just added PR #7444 (https://github.com/zephyrproject-rtos/zephyr/pull/7444), but I'm not sure who to ask as reviewer(s). So, I'd like to make an appeal to anyone who is interested in bringing nrf52 devices into using device tree to have a look and give some advice.

Its a small change, but already it means for example that nrf boards could use the "gpio-leds" dt binding to generate some defines for leds.

Next steps are to support pin selection for common drivers like uart, spi, i2c, etc. as well as pin selection for interrupts etc.

All and any feedback will be much appreciated..

I also invite anyone to ask me to review theirs, although I'm still a novice here.

 

Cheers

Marc

 

 


new PR adding initial dts support for nrf52 gpio, needs reviewer(s)

Marc Reilly
 

Hi,

I've just added PR #7444 (https://github.com/zephyrproject-rtos/zephyr/pull/7444), but I'm not sure who to ask as reviewer(s). So, I'd like to make an appeal to anyone who is interested in bringing nrf52 devices into using device tree to have a look and give some advice.

Its a small change, but already it means for example that nrf boards could use the "gpio-leds" dt binding to generate some defines for leds.

Next steps are to support pin selection for common drivers like uart, spi, i2c, etc. as well as pin selection for interrupts etc.

All and any feedback will be much appreciated..
I also invite anyone to ask me to review theirs, although I'm still a novice here.

Cheers
Marc



Read connection RSSI always return -127

전형욱
 

Hello,

I wrote the same question on user forum but haven't got any response so I'm writing this on devel forum, too.

I'm developing HCI UART dongle using nRF52840 based on Zephyr v1.11 branch.
Everything works fine now except for reading RSSI on connected device.

HCI commands were successfully executed but always return -127.

< HCI Command: Read RSSI (0x05|0x0005) plen 2            #488 [hci1] 620.325803
        Handle: 0
> HCI Event: Command Complete (0x0e) plen 7              #489 [hci1] 620.326563
      Read RSSI (0x05|0x0005) ncmd 1
        Status: Success (0x00)
        Handle: 0
        RSSI: -127 dBm (0x81)
It is the same on nRF52840_pca10056 reference board.

Here are contents of prj.conf file.
CONFIG_CONSOLE=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_NRF5_BAUD_RATE=1000000
CONFIG_UART_NRF5_FLOW_CONTROL=y
CONFIG_MAIN_STACK_SIZE=512
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512
CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_MAX_CONN=16
CONFIG_BT_TINYCRYPT_ECC=y
CONFIG_BT_CTLR_DTM_HCI=y
CONFIG_BT_CTLR_ASSERT_HANDLER=n
CONFIG_BT_HCI_ACL_FLOW_CONTROL=y
CONFIG_BT_CTLR_DATA_LENGTH=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_GPIO_LNA=y
CONFIG_BT_CTLR_GPIO_LNA_PIN=28
CONFIG_BT_CTLR_GPIO_PA=y
CONFIG_BT_CTLR_GPIO_PA_PIN=3
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_CONN_RSSI=y

Is there anything that I need to configure in project setting?

Regards,

Hyoungwook Jeon



1.12 merge window closing soon

Maureen Helm
 

The Zephyr 1.12 release feature merge window is due to close soon. Our original schedule had this milestone set for today, but the TSC agreed to extend the merge window by one week to allow a few remaining 1.12 roadmap features to make it in. These features include OpenAMP (#3065) and full persistent storage for Bluetooth (#7073).

 

If you have any new features in the works that you would like to get into the 1.12 release, please submit a PR as soon as possible. After the feature merge window closes on Friday May 18, we will only merge bug fixes and documentation until the release. Please also help out by reviewing PRs from other contributors. Even if you do not have merge privileges, it is a big help if you review and vote on PRs.

 

Thanks for all your contributions!

 

Schedule:

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

 

Roadmap:

https://github.com/zephyrproject-rtos/zephyr/projects/9

 


Can't download in chuncks using https

christian tavares
 

I'm developing an http_client library, this library needs to download a flash image on the server and install the image on the card.
When I download the flash image from the server if it is larger than the request_buf of the http_client_set_tls function, an error occurs to save the encrypted packets on the stack. I would like to know if you have a way to download the larger image by checking the encryption in pieces?
I've been researching a lot how to solve this case, but I have not found a solution. I'll be grateful if anyone can find a solution. Below I am sending what happens.

[https/client] [DBG] on_status: (0x2000d1c4): HTTP response status OK
[https/client] [DBG] print_header_field: (0x2000d1c4): [12] X-Powered-By
[https/client] [DBG] print_header_field: (0x2000d1c4): [7] Express
[https/client] [DBG] print_header_field: (0x2000d1c4): [13] Accept-Ranges
[https/client] [DBG] print_header_field: (0x2000d1c4): [5] bytes
[https/client] [DBG] print_header_field: (0x2000d1c4): [13] Cache-Control
[https/client] [DBG] print_header_field: (0x2000d1c4): [17] public, max-age=0
[https/client] [DBG] print_header_field: (0x2000d1c4): [13] Last-Modified
[https/client] [DBG] print_header_field: (0x2000d1c4): [29] Thu, 08 Mar 2018 19:14:53 GMT
[https/client] [DBG] print_header_field: (0x2000d1c4): [4] ETag
[https/client] [DBG] print_header_field: (0x2000d1c4): [21] W/"60000-16207099be3"
[https/client] [DBG] print_header_field: (0x2000d1c4): [12] Content-Type
[https/client] [DBG] print_header_field: (0x2000d1c4): [24] application/octet-stream
[https/client] [DBG] print_header_field: (0x2000d1c4): [14] Content-Length
[https/client] [DBG] print_header_field: (0x2000d1c4): [6] 393216
[https/client] [DBG] print_header_field: (0x2000d1c4): [4] Date
[https/client] [DBG] print_header_field: (0x2000d1c4): [29] Tue, 08 May 2018 21:02:56 GMT
[https/client] [DBG] print_header_field: (0x2000d1c4): [10] Connection
[https/client] [DBG] print_header_field: (0x2000d1c4): [5] close
[https/client] [DBG] on_headers_complete: (0x2000d1c4): Headers complete
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f714
[net/app] [DBG] _net_app_ssl_mux: (0x2000d1c4): Receiving encrypted data in pkt 0x2000f714 (len 576)
[net/app] [DBG] my_debug: (0x2000d1c4): ssl_tls.c:3572: |1| bad message length
[net/app] [DBG] my_debug: (0x2000d1c4): ssl_tls.c:3783: |1| mbedtls_ssl_read_record_layer() returned -29184 (-0x7200)
[net/app] [DBG] my_debug: (0x2000d1c4): ssl_tls.c:6944: |1| mbedtls_ssl_read_record() returned -29184 (-0x7200)
[net/app] [ERR] _net_app_ssl_mainloop: mbedtls_ssl_read returned -0x7200 (SSL - An invalid SSL record was received)
[net/app] [ERR] _net_app_ssl_mainloop: Closing connection -0x7200 (SSL - An invalid SSL record was received)
[net/app] [ERR] tls_client_handler: TLS mainloop startup failed (-29184)
[net/app] [DBG] tls_client_handler: (0x2000d1c4): Shutting down TLS handler
[https/client] [DBG] http_closed: (0x2000d1c4): [0x2000d118] connection closed
[net/app] [DBG] _net_app_tls_handler_stop: (0x2000d1c4): TLS thread 0x2000d1c4 stopped
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f768
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f714
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f6c0
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f66c
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f618
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f5c4
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f570
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f51c
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f4c8
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f474
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f420
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f3cc
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f378
[net/app] [DBG] _net_app_tls_received: (0x2000be5c): Encrypted data received in pkt 0x2000f324

Here shows the size that defined the variables used by the functions:

RESULT_BUF_SIZE = MBEDTLS_SSL_MAX_CONTENT_LEN (1500) 
#define HTTPS_STACK_SIZE (4096)
NET_STACK_DEFINE(HTTPS, https_stack, HTTPS_STACK_SIZE, HTTPS_STACK_SIZE);
NET_APP_TLS_POOL_DEFINE(ssl_pool, 10);
#define TCP_RECV_BUFFER_SIZE 1024 
#define APP_TIMEOUT K_SECONDS(10)

static u8_t https_result_buf[RESULT_BUF_SIZE];

ret = http_client_init(&ctx->http_client.http_ctx,
                                  UPDATEHUB_SERVER,
                                UPDATEHUB_PORT, NULL,
                                   APP_TIMEOUT);

ret = http_client_set_tls(&ctx->http_client.http_ctx,
                                       https_result_buf,
                                       RESULT_BUF_SIZE,
                                         NULL,
                                        NULL,
                                       setup_cert,
                                        NULL,
                                        NULL,
                                     &ssl_pool,
                                      https_stack,
                                     HTTPS_STACK_SIZE);

ret = http_client_send_req(&ctx->http_client.http_ctx,
                                              &ctx->http_client.req,
                                            install_update_cb ,
                                            ctx->http_client.tcp_buffer,
                                            TCP_RECV_BUFFER_SIZE, ctx,
                                              APP_TIMEOUT);

The install_update_cb function is responsible for downloading parts of the image and saving this image in flash area 1.

For a better view, I am sending the link from the library. The call occurs in function "updatehub_install_update"
https://github.com/OSSystems/zephyr/blob/master/subsys/updatehub/updatehub.c


Re: Kconfig changes on master

Carles Cufi
 

Hi there,

 

CMake is the build system, Kconfig is the configuration system. Kconfig is run by CMake as one of the first things it does in order to figure out what needs to be built and how.

 

More information can be found here:

http://docs.zephyrproject.org/application/application.html#cmake-details

http://docs.zephyrproject.org/application/application.html#application-configuration

 

Regards,

 

Carles

 

From: jack ma <assangema@...>
Sent: 08 May 2018 12:29
To: Cufi, Carles <carles.cufi@...>
Cc: devel@...; users@...
Subject: Re: [Zephyr-devel] Kconfig changes on master

 

Hi,

What is the relationship  cmake and kconfig ?  both of them can be used to configure Zephyr ?

Are they alternative or dependent?

 

Thanks.

 

2018-05-08 4:02 GMT+08:00 Cufi, Carles <carles.cufi@...>:

Hi all,

We have just merged PR #7293 [1], and this has a few implications for developers and users. With the end goal being removing the dependency to the C implementation of the different Kconfig tools in order to provide native support on all operating systems, including Windows, Ulf has contributed a Python "menuconfig" implementation that is now the only frontend available for browsing the Kconfig tree.

In practice this means:

 * The gconfig and xconfig targets have been removed
 * The menuconfig target now uses a Python implementation with curses as its backend
 * There is a new Python requirement on Windows (windows-curses) that is part of requirements.txt

If anyone in the community wants to look into providing a graphical user interface for Kconfig to replace the ones that have been removed, a good starting point would be to:

 * Use Qt and the PyQt [2] or PySide [3](recently announced for Qt 5) bindings
 * Use scripts/kconfig/menuconfig.py as a reference on how to access the Kconfig tree data from Python

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/7293
[2] https://wiki.python.org/moin/PyQt
[3] https://wiki.qt.io/PySide



 


Re: Kconfig changes on master

jack ma
 

Hi,
What is the relationship  cmake and kconfig ?  both of them can be used to configure Zephyr ?
Are they alternative or dependent?

Thanks.

2018-05-08 4:02 GMT+08:00 Cufi, Carles <carles.cufi@...>:

Hi all,

We have just merged PR #7293 [1], and this has a few implications for developers and users. With the end goal being removing the dependency to the C implementation of the different Kconfig tools in order to provide native support on all operating systems, including Windows, Ulf has contributed a Python "menuconfig" implementation that is now the only frontend available for browsing the Kconfig tree.

In practice this means:

 * The gconfig and xconfig targets have been removed
 * The menuconfig target now uses a Python implementation with curses as its backend
 * There is a new Python requirement on Windows (windows-curses) that is part of requirements.txt

If anyone in the community wants to look into providing a graphical user interface for Kconfig to replace the ones that have been removed, a good starting point would be to:

 * Use Qt and the PyQt [2] or PySide [3](recently announced for Qt 5) bindings
 * Use scripts/kconfig/menuconfig.py as a reference on how to access the Kconfig tree data from Python

Regards,

Carles

[1] https://github.com/zephyrproject-rtos/zephyr/pull/7293
[2] https://wiki.python.org/moin/PyQt
[3] https://wiki.qt.io/PySide







Re: Extending Error Codes

Zięcik, Piotr <piotr.ziecik@...>
 

-----Original Message-----
From: Cufi, Carles
Sent: Monday, May 07, 2018 11:57 AM
To: Zięcik, Piotr <Piotr.Ziecik@nordicsemi.no>; Puzdrowski, Andrzej <Andrzej.Puzdrowski@nordicsemi.no>; devel@lists.zephyrproject.org
Subject: RE: [Zephyr-devel] Extending Error Codes

Hi.

I do not think that per-module error codes are good idea.
I agree. I think a single set of generic error codes that are flexible enough to convey the message are a better approach.
That still leaves out how to extend errno.h for both newlib and minimal.

Should we have an extended errno-zephyr.h for Zephyr somewhere in include/?
Hi.

I have looked into the error list available in ./lib/libc/minimal/include/errno.h and it looks that there are plenty of errors defined, however most of these defines are rather high-level.
If this is not enough, I could recommend following the Linux approach, which in my opinion is pretty simple and gives some flexibility:

We can divide the error lists in 2 parts, listed in 2 different files. The first file, will cover generic, high level errors (and could be provided by libc).
The second file will be zephyr-specific. There should be also single errno.h header, which will include both libc and zephyr headers.

What do you think?

Best Regards,
Piotr Zięcik.


Re: Usage of generated dts *_GPIO_FLAGS

Diego Sueiro
 

Hi Erwan,

Having direct match between generated FLAGS/INT_CONF aliases and application symbols would be a good idea.
Though not sure which should converge to the other.
INT_CONF (Interrupt configuration I guess) is more restrictive than FLAGS.
Impacted field is used to configure GPIO in general, not interrupt only, so a more generic name might be a better choice.

I agree with you about using a more generic name (FLAGS). So basically we will need to update the "samples/basic/button/src/main.c" (SW0_GPIO_INT_CONF ->SW0_GPIO_FLAGS) application and move all SW0_GPIO_INT_CONF definitions from board.h to the respective dts file?

Does anyone have a better idea?


Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/

On 4 May 2018 at 09:34, Erwan Gouriou <erwan.gouriou@...> wrote:
Hi Diego,


Having direct match between generated FLAGS/INT_CONF aliases and application symbols would be a good idea.
Though not sure which should converge to the other.
INT_CONF (Interrupt configuration I guess) is more restrictive than FLAGS.
Impacted field is used to configure GPIO in general, not interrupt only, so a more generic name might be a better choice.

Erwan


On 4 May 2018 at 07:33, Diego Sueiro <diego.sueiro@...> wrote:
Hello,

I'd like to know what is the usage of the *_GPIO_FLAGS macro.

For example in "dts/bindings/gpio/nxp,kinetis-gpio.yaml" file:

cell_string: GPIO
"#cells":
  - pin
  - flags

And "boards/arm/frdm_k64f/frdm_k64f.dts" file we have
gpios = <&gpioa 4 GPIO_INT_ACTIVE_LOW>;

This will generate in "zephyr/include/generated/generated_dts_board.h":
#define GPIO_KEYS_1_GPIO_CONTROLLER "GPIO_0"
#define GPIO_KEYS_1_GPIO_FLAGS_0    0
#define GPIO_KEYS_1_GPIO_PIN_0      4
#define GPIO_KEYS_1_LABEL       "User SW3"
#define GPIO_KEYS_1_GPIO_FLAGS      GPIO_KEYS_1_GPIO_FLAGS_0
#define GPIO_KEYS_1_GPIO_PIN        GPIO_KEYS_1_GPIO_PIN_0
#define SW0_GPIO_CONTROLLER     GPIO_KEYS_1_GPIO_CONTROLLER
#define SW0_GPIO_FLAGS          GPIO_KEYS_1_GPIO_FLAGS
#define SW0_GPIO_PIN            GPIO_KEYS_1_GPIO_PIN
#define SW0_LABEL           GPIO_KEYS_1_LABEL

In this example SW0_GPIO_FLAGS is not "consumed" by any source code, but  "samples/basic/button/src/main.c" application is using SW0_GPIO_CONTROLLER, SW0_GPIO_PIN and SW0_GPIO_INT_CONF.

I think we should name this gpio dts cell as "int_conf" instead of "flags", this way the dts configuration will be used in the button application, for example.



Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/



3481 - 3500 of 8033