Date   

UART DFU from nRF9160 to nRF52840

ljaynes87@...
 

I am looking to DFU an nrf52840 over UART from an nRF9160. The board is set up similar to the Thingy:91. The firmware will be downloaded over LTE on the 9160 and will need to be sent over to the 52840 via UART. Would be best place to start be the smp_svr sample? I know the sample instructions suggest using the mcumgr Command-Line Tool but I need to do this from the 9160. Does the smp_svr provide support for the 9160 to run the DFU commands and start an update on the 52840?


Re: API meeting: agenda

Carles Cufi
 

Hi all,

I'd like to amend the agenda for today's meeting with the following PRs which have been waiting for resolution for a while:

- PR: Validate pin ordinals in wrapper functions
- https://github.com/zephyrproject-rtos/zephyr/pull/20115

- PR: Add discussion of terms that define API behavior
- https://github.com/zephyrproject-rtos/zephyr/pull/21678

Regards,

Carles

-----Original Message-----
From: devel@... <devel@...> On
Behalf Of Cufi, Carles via Lists.Zephyrproject.Org
Sent: 20 January 2020 18:05
To: devel@...; users@...
Cc: devel@...
Subject: [Zephyr-devel] API meeting: agenda

Hi all,

Tomorrow we will discuss an RFC that is ready to be merged, two items
that were raised in last week's TSC and we will check on progress with
the GPIO porting.

- RFC (ready to merge): on-off service request and release
- https://github.com/zephyrproject-rtos/zephyr/pull/21090

- Discussion: Stability documentation for APIs. Should it be documented
in Doxygen?

- Discussion: What exactly is subject to the API lifecycle deprecation
policies described in
https://docs.zephyrproject.org/latest/development_process/api_lifecycle.
html?
- Options:
- APIs only
- APIs, Kconfig options, DeviceTree format
- APIs, Kconfig options, DeviceTree format, subsystems, drivers,
boards and SoCs

- GPIO update (users)
- https://github.com/zephyrproject-rtos/zephyr/issues/20017

Additional items in the "Triage" column in the GitHub project may be
discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub
project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-
Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-
8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: Signaling/Messaging Userspace from Kernel

Justin Huang
 

Thank you Andrew very much for the explanation! Very helpful.

Justin


From: Boie, Andrew P <andrew.p.boie@...>
Sent: Sunday, January 19, 2020 5:49 PM
To: Justin Huang <justin.y.huang@...>; users@... <users@...>
Subject: RE: [Zephyr-users] Signaling/Messaging Userspace from Kernel
 
  • I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.

 

If you look closely you will see that there is no capability for user mode functions to install a callback handler. This type of operation is supervisor mode only.

 

  • Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?

 

In the callback handler the application has registered from supervisor mode (typically at application initialization), use an IPC object to wake up a user thread for further processing.

 

There’s some example code in samples/userspace/prod_consumer

 

This is something we’d like to iterate on further so if you can come up with some scenarios that you don’t think are well supported please file GH enhancement tickets and assign to  me for further discussion.

 

HTH,

Andrew

 

 

From: users@... <users@...> On Behalf Of Justin Huang
Sent: Saturday, January 18, 2020 10:38 AM
To: users@...
Subject: [Zephyr-users] Signaling/Messaging Userspace from Kernel

 

Hi,

 

Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?

 

I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.

 

Any thoughts/pointers/suggestions would be greatly appreciated.

 

Many thanks in advance and 

with kind regards,

 

Justin


API meeting: agenda

Carles Cufi
 

Hi all,

Tomorrow we will discuss an RFC that is ready to be merged, two items that were raised in last week's TSC and we will check on progress with the GPIO porting.

- RFC (ready to merge): on-off service request and release
- https://github.com/zephyrproject-rtos/zephyr/pull/21090

- Discussion: Stability documentation for APIs. Should it be documented in Doxygen?

- Discussion: What exactly is subject to the API lifecycle deprecation policies described in https://docs.zephyrproject.org/latest/development_process/api_lifecycle.html?
- Options:
- APIs only
- APIs, Kconfig options, DeviceTree format
- APIs, Kconfig options, DeviceTree format, subsystems, drivers, boards and SoCs

- GPIO update (users)
- https://github.com/zephyrproject-rtos/zephyr/issues/20017

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: Signaling/Messaging Userspace from Kernel

Boie, Andrew P
 

  • I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.

 

If you look closely you will see that there is no capability for user mode functions to install a callback handler. This type of operation is supervisor mode only.

 

  • Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?

 

In the callback handler the application has registered from supervisor mode (typically at application initialization), use an IPC object to wake up a user thread for further processing.

 

There’s some example code in samples/userspace/prod_consumer

 

This is something we’d like to iterate on further so if you can come up with some scenarios that you don’t think are well supported please file GH enhancement tickets and assign to  me for further discussion.

 

HTH,

Andrew

 

 

From: users@... <users@...> On Behalf Of Justin Huang
Sent: Saturday, January 18, 2020 10:38 AM
To: users@...
Subject: [Zephyr-users] Signaling/Messaging Userspace from Kernel

 

Hi,

 

Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?

 

I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.

 

Any thoughts/pointers/suggestions would be greatly appreciated.

 

Many thanks in advance and 

with kind regards,

 

Justin


Signaling/Messaging Userspace from Kernel

Justin Huang
 

Hi,

Could someone shed some light on ways in Zephyr for Kernel to signal, or send a message to, threads running in the userspace?

I see some examples using callback functions, but wonder if that is a good practice: it is generally a security risk to run a function provided by a userspace application in the supervisor mode.

Any thoughts/pointers/suggestions would be greatly appreciated.

Many thanks in advance and 
with kind regards,

Justin


Re: Removing an item from the Device tree

Lawrence King
 

Excellent solution. Thank you.

Lawrence King
Principal Developer
+1(416)627-7302

-----Original Message-----
From: Kumar Gala <kumar.gala@...>
Sent: Wednesday, January 15, 2020 9:52 AM
To: Lawrence King <lawrence.king@...>
Cc: Zephyr-users@...
Subject: Re: [Zephyr-users] Removing an item from the Device tree

You can use /delete-property/, something like:

&uart0 {
/delete-property/ rts-pin;
/delete-property/ cts-pin;
};

In your overlay should work.

- k


On Jan 15, 2020, at 8:49 AM, Lawrence King <lawrence.king@...> wrote:

I have a little problem with the device tree

In zephyrproject/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts the uart is defined as:

&uart0 {
compatible = "nordic,nrf-uart";
current-speed = <115200>;
status = "okay";
tx-pin = <20>;
rx-pin = <19>;
rts-pin = <5>;
cts-pin = <7>;
};

Which works just fine. However I am not using the RTS and CTS pin features of the UART, and I need to use the pins for other things. I can simply go into the DTS file and comment out the two pins:

&uart0 {
compatible = "nordic,nrf-uart";
current-speed = <115200>;
status = "okay";
tx-pin = <20>;
rx-pin = <19>;
/* rts-pin = <5>; */
/* cts-pin = <7>; */
};

And all is good. However I would prefer to use an overlay in my local working directory instead of making changes to the zephyr tree. I did try redefining uart0 in the local overlay, but RTS and CTS are still there.

What is the right way to remove RTS and CTS?

Lawrence King
Principal Developer
Connected Transport Market Unit
https://www.Irdeto.com
+1(416)627-7302

<image001.png> <image003.png> <image005.png> <image007.png> <image009.png> <image011.png>

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.




Re: Removing an item from the Device tree

Kumar Gala
 

You can use /delete-property/, something like:

&uart0 {
/delete-property/ rts-pin;
/delete-property/ cts-pin;
};

In your overlay should work.

- k

On Jan 15, 2020, at 8:49 AM, Lawrence King <lawrence.king@...> wrote:

I have a little problem with the device tree

In zephyrproject/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts the uart is defined as:

&uart0 {
compatible = "nordic,nrf-uart";
current-speed = <115200>;
status = "okay";
tx-pin = <20>;
rx-pin = <19>;
rts-pin = <5>;
cts-pin = <7>;
};

Which works just fine. However I am not using the RTS and CTS pin features of the UART, and I need to use the pins for other things. I can simply go into the DTS file and comment out the two pins:

&uart0 {
compatible = "nordic,nrf-uart";
current-speed = <115200>;
status = "okay";
tx-pin = <20>;
rx-pin = <19>;
/* rts-pin = <5>; */
/* cts-pin = <7>; */
};

And all is good. However I would prefer to use an overlay in my local working directory instead of making changes to the zephyr tree. I did try redefining uart0 in the local overlay, but RTS and CTS are still there.

What is the right way to remove RTS and CTS?

Lawrence King
Principal Developer
Connected Transport Market Unit
https://www.Irdeto.com
+1(416)627-7302

<image001.png> <image003.png> <image005.png> <image007.png> <image009.png> <image011.png>

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.




Removing an item from the Device tree

Lawrence King
 

I have a little problem with the device tree

 

In zephyrproject/zephyr/boards/arm/nrf52840_mdk/nrf52840_mdk.dts the uart is defined as:

 

&uart0 {

        compatible = "nordic,nrf-uart";

        current-speed = <115200>;

        status = "okay";

        tx-pin = <20>;

        rx-pin = <19>;

       rts-pin = <5>;

        cts-pin = <7>;

};

 

Which works just fine. However I am not using the RTS and CTS pin features of the UART, and I need to use the pins for other things. I can simply go into the DTS file and comment out the two pins:

 

&uart0 {

        compatible = "nordic,nrf-uart";

        current-speed = <115200>;

        status = "okay";

        tx-pin = <20>;

        rx-pin = <19>;

/*      rts-pin = <5>;  */

/*      cts-pin = <7>;  */

};

 

And all is good. However I would prefer to use an overlay in my local working directory instead of making changes to the zephyr tree. I did try redefining uart0 in the local overlay, but RTS and CTS are still there.

 

What is the right way to remove RTS and CTS?

 

Lawrence King

Principal Developer

Connected Transport Market Unit

https://www.Irdeto.com

+1(416)627-7302

 

1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7

            

CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.

 

 

 


Re: NVS on flash with erase page size 64k or larger #nvs

Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
 

NVS on flash with erase page size 64k or larger #nvs

 Marco

Jan 2   

 

  • Hi there

    > In my application I try to use NVS on an external SPI flash (M25P16) which has an erase page size of 64k.

    > As I realised, NVS seems to have some limit on its maximum sector size of just below those 64k, since the variable storing it is an u16_t.

    > Is there any workaround to get this combination to work anyway, or is even an enhancement planned, to overcome this limit?
    > Since there are still quite a few memories on the market with page sizes exceeding those 64k it might be interesting generally.

    > Thanks and regards.

 

Hi.

 

64k sector is known limitation – it is not planed by us to support more right now. Although a patch witch configurable extension will be accepted.

(a I know the code, it shouldn’t be hard to add such extension).

AndrzejR

 


Re: Feedback requested on west manifest imports

Jørn Villesen Christensen <jvc@...>
 

On 14/01/2020 19:33, Bolivar, Marti wrote:
Hello Zephyr users and developers,

We've just uploaded a pre-release version of west to PyPI with a new
feature: manifest imports. We would like your feedback!

Please let us know what you think. We'd like to get feedback before
the west 0.7 release, as making big changes after that time will be
harder to do.
Just had a read through your documentation; it looks nice. Have not
tested the code, but judging from the documentation, it looks useful.

Thank you :-)

~Jørn


DTS/Binding Issue migrating from 2.0.0 to 2.1.0 #nrf52832

matt@...
 

Hello Zephyr Users,

I have inherited a Zephyr project using nRF52832 from another developer and am having an issue migrating from 2.0.0 to 2.1.0. Its probably something simple but I'm fairly new to the devicetree system and can't seem to wrap my head around whats wrong here.

In my custom board .dts file I have the following i2c configuration (note that the lis3dh is a zephyr-supported sensor driver and I have custom drivers/bindings for tca6507 and mcp47cvb12):

&i2c0 {
        status = "okay";
        sda-pin = <7>;
        scl-pin = <5>;
        clock-frequency = <I2C_BITRATE_FAST>;
 
        lis3dh@19 {
                compatible = "st,lis2dh", "st,lis3dh";
                reg = <0x19>;
                irq-gpios = <&gpio0 19 0>;
                label = "LIS3DH";
        };
 
        tca6507@45 {
                compatible = "ti,tca6507";
                reg = <0x45>;
                enable-gpios = <&gpio0 26 GPIO_DIR_OUT>;
                label = "TCA6507";
        };
 
        mcp47cvb12@60 {
                compatible = "mcp,mcp47cvb12";
                reg = <0x60>;
                label = "MCP47CVB12";
        };
};
Using OS v2.0.0 this built properly. After upgrading the OS to v2.1.0, I get the following error from `zephyr/scripts/dts/extract_dts_includes.py` on build: 

Exception: /soc/i2c@40003000/lis3dh@19 defines parent /soc/i2c@40003000 as bus master, but /soc/i2c@40003000 is not configured as bus master in binding
By changing `compatible = "st,lis2dh", "st,lis3dh";` to `compatible = "st,lis2dh-i2c", "st,lis3dh-i2c";` in the .dts file this gets rid of the error for the lis3dh, but i get a similar error for `mcp47cvb12` and `tca6507`. For completeness, here are my .yaml files for these two bindings:

mcp,mcp47cvb12.yaml:
title: Microchip MCP47CVB12 Driver
 
description: Microchip MCP47CVB12 DAC binding
 
compatible: "mcp,mcp47cvb12"
 
include: i2c-device.yaml
ti,tca6507.yaml:
title: TI TCA6507 LED Driver
 
description: TI TCA6507 LED binding
 
compatible: "ti,tca6507"
 
include: i2c-device.yaml
 
properties:
    enable-gpios:
      type: compound
      required: true
Alright so onto direct questions:

  1. What does the error message `but /soc/i2c@40003000 is not configured as bus master in binding` mean? It seems to me that `i2c-device.yaml` correctly sets `parent-bus: i2c`
  2. Why does adding the `-i2c` to the .dts file `compatible` field for the lis3dh fix this error? I never had to add this in the past.
  3. What do I need to change, if anything, in my custom device bindings to fix this error?
Thank you for your help,

Matt


Feedback requested on west manifest imports

Bolivar, Marti
 

Hello Zephyr users and developers,

We've just uploaded a pre-release version of west to PyPI with a new
feature: manifest imports. We would like your feedback!

For a short README you can follow to try it out, see:

https://github.com/mbolivar/my-zephyr-app

This new feature lets you import projects from a west.yml file
somewhere else (like zephyr/west.yml) into your own "downstream"
west.yml file.

The import gives you the zephyr repository and all its modules "for
free": you do not have to copy/paste projects from zephyr/west.yml into
your custom file and manually track changes. You can also add your own
repositories or override individual modules if you've got your own
forks, etc. See the README for links to more information.

Please let us know what you think. We'd like to get feedback before
the west 0.7 release, as making big changes after that time will be
harder to do.

Thanks!
Marti


API meeting: Agenda

Carles Cufi
 

Hi all,

This week we will focus on a new RFC and GPIO.

- RFC: New counter_get_value() API call
- https://github.com/zephyrproject-rtos/zephyr/issues/21846

- GPIO: Update on progress
- Proposal from Peter Bigot: Port remaining users without testing them on hardware (accepted)
- Look at the PRs with driver conversion (https://github.com/zephyrproject-rtos/zephyr/issues/18530)
- Check users of GPIO APIs: https://github.com/zephyrproject-rtos/zephyr/issues/20017
- Tips for converting users can be found here: https://github.com/zephyrproject-rtos/zephyr/issues/20017#issuecomment-549315497 (thanks Peter!)
- Any additional outstanding PRs to topic-gpio

Additional items in the "Triage" column in the GitHub project may be discussed if time permits.
If you want an item included in the meeting, please add it to the GitHub project.

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#zephyr-api-discussion
https://github.com/zephyrproject-rtos/zephyr/projects/18
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: NXP RT1064 board and JLink Debugging

langrind@...
 

For what it's worth 8 months later, I was able to use PyOCD and the the built-in debugger on RT1064-EVK board to flash the Zephyr blinky program using MCUXpresso's flash programmer. Thus avoiding (for now) the need to buy a J-link probe. I didn't need to change much of anything.

What I did was use the MCUX option to save the flash command it uses to a file, and then tweaked the file so it's a script I can pass in whatever elf file I want:

MCUX_WORKSPACE_LOC=$HOME/Documents/MCUXpresso_11.0.1_2563/workspace
MCUX_FLASH_DIR0=/usr/local/mcuxpressoide-11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.bin.linux_11.0.1.201908271452/binaries/Flash
MCUX_FLASH_DIR1=$HOME/Documents/MCUXpresso_11.0.1_2563/workspace/.mcuxpressoide_packages_support/MIMXRT1064xxxxA_support/Flash
MCUX_IDE_BIN=/usr/local/mcuxpressoide-11.0.1_2563/ide/plugins/com.nxp.mcuxpresso.tools.bin.linux_11.0.1.201908271452/binaries/

$MCUX_IDE_BIN/crt_emu_cm_redlink --flash-load-exec $1 -p MIMXRT1064xxxxA --flash-driver MIMXRT1064.cfx -x $HOME/bin --flash-dir $MCUX_FLASH_DIR0 --flash-dir $MCUX_FLASH_DIR1

(some of that stuff may be unnecessary)

I copied MIMXRT1064xxxxA_part.xml  and MIMXRT1064xxxxA.xml from an MCUX project directory into ~/bin (hence the -x $HOME/bin in the command above)

The script will flash the build/zephyr/zephyr.elf no problem. I didn't have to change any jumpers on the RT1064-EVK other than to set SW7 to boot from internal flash. I didn't have to change anything about how the zephyr sample program is built.


Upgrade pyocd requested version to 0.24.0

Erwan Gouriou
 

Hi Zephyr users,

In order to benefit from a wider range of user options [1], I'm proposing in PR 21791 to upgrade requirement for pyocd to version 0.24.0.
Change should not have impact for most users, but if you have any comments, don't hesitate to let me know (in PR discussion)

Cheers
Erwan




Re: DHCPV4 and CONFIG_NET_SOCKETS_SOCKOPT_TLS

Jukka Rissanen
 

Hi,

the DHCPv4 code does not really timeout, there is exponential backoff so the system will try to get the IP address as long as needed.

For the socket TLS error, you need to enable also mbedTLS as that is used to implement the actual TLS support.

Cheers,
Jukka


On Tue, 2020-01-07 at 17:15 +0100, Denv E wrote:
Hi,

using zephyr-v2.1.0

I have build the mqtt_publisher sample application for the stm32f746g_disco and it works fine.

I have build the dhcpv4_client sample application for the stm32f746g_disco and it works fine.

When I want to combine both, mqtts and dhcpv4, the dhcpv4 is always timing out.

I have tried step by step.

Using dhcpv4_client sample:

add to prj.conf

# Enable Sockets support
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_SOCKOPT_TLS=y

Then the application is no longer compiling:

zephyr/subsys/net/lib/sockets/sockets_tls.c:1735:45: error: 'struct tls_context' has no member named 'ssl'

Does sock_opt_tls is depending on mbedtls? In the guiconfig there is no dependency mentioned between CONFIG_NET_SOCKETS_SOCKOPT_TLS and CONFIG_MBEDTLS.
The sockets_tls uses different mbedtls defines.

What is the correct solution for this problem?

kr,

Wim



Re: I2C on nRF5340 Issues #i2c #driver #nrf5340

Marciano
 

After further testing, I found that if I step through each instruction with the debugger the individual messages send correctly, but not if I let the program run regularly. In neither case does the i2c_transfer(…) function return. What might cause the differences in behavior between slow stepping and running the program?


PassiveLogic, Inc.
Main 801-394-3344
Mobile 801-800-1184
marciano@...

This e-mail and any files transmitted with it may contain confidential or legally privileged information of PassiveLogic and/or its affiliates, and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete the e-mail in its entirety from your system.



On Jan 7, 2020, at 3:07 PM, marciano@... wrote:

I am attempting to write a basic I2C program using Zephyr, but I am currently unable to sent a single byte over I2C. The program hangs after the first clock falling & rising edge.

I'm using external 1K pullups, and have a BME680 device on the other end. I observe the same behavior on the bus with or without the BME680 device.

Am I doing something wrong?

 

prj.conf

CONFIG_NEWLIB_LIBC=y

CONFIG_PRINTK=y

CONFIG_HAS_SEGGER_RTT=y

CONFIG_USE_SEGGER_RTT=y

CONFIG_RTT_CONSOLE=y

CONFIG_UART_CONSOLE=n



# nRF5340 board config

CONFIG_TRUSTED_EXECUTION_SECURE=y



CONFIG_BT=n

CONFIG_TIMESLICING=n

CONFIG_DEVICE_POWER_MANAGEMENT=y

CONFIG_SYS_POWER_MANAGEMENT=y

CONFIG_SYS_POWER_DEEP_SLEEP_STATES=y

CONFIG_DEVICE_POWER_MANAGEMENT=y



CONFIG_I2C=y

CONFIG_I2C_1=y

main.c

#include 
#include 
#include <sys/printk.h>
#include <drivers/i2c.h>

/* Application main Thread */
int main(void)
{
  struct device *p_i2c = device_get_binding("I2C_1");
  u32_t dev_config = I2C_SPEED_SET(I2C_SPEED_STANDARD) | I2C_MODE_MASTER;
  int res = i2c_configure(p_i2c, dev_config);
  if (res)
  {
    return res;
  }
  struct i2c_msg msgs[2];
  u8_t data[2][2];
  data[0][0] = 0x01; // register address
  data[0][1] = 0x00;
  msgs[0].buf = data[0];
  msgs[0].len = 2U;
  msgs[0].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

  data[1][0] = 0x4;
  data[1][1] = 0xff;
  msgs[1].buf = data[1];
  msgs[1].len = 2U;
  msgs[1].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

  int i = i2c_transfer(p_i2c, &msgs[0], 2, 0x77);
  if  (i)
    printk("transfer failed");
  return 0;
}
<Screen Shot 2020-01-06 at 2.53.05 PM.png>


I2C on nRF5340 Issues #i2c #driver #nrf5340

Marciano
 

I am attempting to write a basic I2C program using Zephyr, but I am currently unable to sent a single byte over I2C. The program hangs after the first clock falling & rising edge.

I'm using external 1K pullups, and have a BME680 device on the other end. I observe the same behavior on the bus with or without the BME680 device.

Am I doing something wrong?

 


prj.conf

CONFIG_NEWLIB_LIBC=y

CONFIG_PRINTK=y

CONFIG_HAS_SEGGER_RTT=y

CONFIG_USE_SEGGER_RTT=y

CONFIG_RTT_CONSOLE=y

CONFIG_UART_CONSOLE=n



# nRF5340 board config

CONFIG_TRUSTED_EXECUTION_SECURE=y



CONFIG_BT=n

CONFIG_TIMESLICING=n

CONFIG_DEVICE_POWER_MANAGEMENT=y

CONFIG_SYS_POWER_MANAGEMENT=y

CONFIG_SYS_POWER_DEEP_SLEEP_STATES=y

CONFIG_DEVICE_POWER_MANAGEMENT=y



CONFIG_I2C=y

CONFIG_I2C_1=y

main.c

#include 
#include 
#include <sys/printk.h>
#include <drivers/i2c.h>

/* Application main Thread */
int main(void)
{
  struct device *p_i2c = device_get_binding("I2C_1");
  u32_t dev_config = I2C_SPEED_SET(I2C_SPEED_STANDARD) | I2C_MODE_MASTER;
  int res = i2c_configure(p_i2c, dev_config);
  if (res)
  {
    return res;
  }
  struct i2c_msg msgs[2];
  u8_t data[2][2];
  data[0][0] = 0x01; // register address
  data[0][1] = 0x00;
  msgs[0].buf = data[0];
  msgs[0].len = 2U;
  msgs[0].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

  data[1][0] = 0x4;
  data[1][1] = 0xff;
  msgs[1].buf = data[1];
  msgs[1].len = 2U;
  msgs[1].flags = I2C_MSG_WRITE | I2C_MSG_STOP;

  int i = i2c_transfer(p_i2c, &msgs[0], 2, 0x77);
  if  (i)
    printk("transfer failed");
  return 0;
}


DHCPV4 and CONFIG_NET_SOCKETS_SOCKOPT_TLS

Denv E
 

Hi,

using zephyr-v2.1.0

I have build the mqtt_publisher sample application for the stm32f746g_disco and it works fine.

I have build the dhcpv4_client sample application for the stm32f746g_disco and it works fine.

When I want to combine both, mqtts and dhcpv4, the dhcpv4 is always timing out.

I have tried step by step.

Using dhcpv4_client sample:

add to prj.conf

# Enable Sockets support
CONFIG_NET_SOCKETS=y
CONFIG_NET_SOCKETS_SOCKOPT_TLS=y

Then the application is no longer compiling:

zephyr/subsys/net/lib/sockets/sockets_tls.c:1735:45: error: 'struct tls_context' has no member named 'ssl'

Does sock_opt_tls is depending on mbedtls? In the guiconfig there is no dependency mentioned between CONFIG_NET_SOCKETS_SOCKOPT_TLS and CONFIG_MBEDTLS.
The sockets_tls uses different mbedtls defines.

What is the correct solution for this problem?

kr,

Wim