Date   

Trying to add support for FRDM-KL28Z (nxp)

Lars Knudsen
 

Hi,

I'm trying to add support for the FRDM-KL28Z board but realize, there seem to be missing support under /ext (where I see support for e.g. MKL25Z4).

Would this need to be pulled from an NXP repo?

br
Lars


Re: [Zephyr-users] [Zephyr-devel] nRF52: USART: sending data from Serial terminal to DK

Chettimada, Vinayak Kariappa
 

Why don’t you use tests/bluetooth/mesh_shell ? and add your commands?

Johan may be of assistance.

On 24 Aug 2018, at 13:08, Vikrant More <vikrant8051@...> wrote:

Hi Vinayak,
My sim is to create commands & send it to PDK where PDK process them & help onboard #BluetoothMesh clients to create data packets.

Currently using thread triggered by button interrupt to send Bluetooth Mesh Client mesaages like
Gen_OnOff_Set/ Gen_OnOff_Set_Unack/Gen_Level_Set/Gen_Level_Set_Unack

Thank You !!

On Fri, Aug 24, 2018 at 4:32 PM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
if you are looking for a shell, tests/bluetooth/shell could be your inspiration.

if you are looking for implementing a transport over uart, then samples/bluetooth/hci_uart could be your inspiration.

other samples and subsystems may be using UART, that could also be close to your needs. Hoping the UART API documentation in Zephyr should suffice your requirements and how to use it.

-Vinayak

On 24 Aug 2018, at 12:46, vikrant8051 <vikrant8051@...> wrote:

I found sample code under main tree i.e zephyr/samples/nfc/nfc_hello 
which read data on UART terminal.

But it is crasing with this log  ...

Sample app running on: arm
***** BUS FAULT *****
  Instruction bus error
***** Hardware exception *****
Current thread ID = 0x20000f24
Faulting instruction address = 0x8fccaf0
Fatal fault in essential thread! Spinning...

So I edit as
uart1_dev = device_get_binding("UART_0")

But still firmware is not printing received data back on
terminal.

Thank You !!



On Thu, Aug 23, 2018 at 6:54 PM vikrant8051 <vikrant8051@...> wrote:
Hi,

I wanna send some chuck of data over USART to #nRF52840_PDK like commands.

Is there any sample code available for it or any configuration is required to enable this USART
read feature ?

Thank You !!





Re: Applying TDD to an IP stack issue

Oleg Zhurakivskyy
 

Hello Paul,

On 08/23/2018 01:29 PM, Paul Sokolovsky wrote:

The simplest test would be as follows: it should be an active close,
i.e. connection close should happen on Zephyr side. Then test would
expect to receive a FIN pkt, but should ignore it and not send an ACK.
Then the test should verify that a FIN retransmission is received
within reasonable time.
Thanks for the input.

Currenly the TCP suite is very simple and doesn't have a capability to initiate events on a peer's side of TCP connection.

I am planning to add such capability and will try to implement such a test.

Regards,
Oleg


Re: [Zephyr-users] [Zephyr-devel] nRF52: USART: sending data from Serial terminal to DK

vikrant8051 <vikrant8051@...>
 

Hi Vinayak,
My sim is to create commands & send it to PDK where PDK process them & help onboard #BluetoothMesh clients to create data packets.

Currently using thread triggered by button interrupt to send Bluetooth Mesh Client mesaages like
Gen_OnOff_Set/ Gen_OnOff_Set_Unack/Gen_Level_Set/Gen_Level_Set_Unack

Thank You !!

On Fri, Aug 24, 2018 at 4:32 PM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
if you are looking for a shell, tests/bluetooth/shell could be your inspiration.

if you are looking for implementing a transport over uart, then samples/bluetooth/hci_uart could be your inspiration.

other samples and subsystems may be using UART, that could also be close to your needs. Hoping the UART API documentation in Zephyr should suffice your requirements and how to use it.

-Vinayak

On 24 Aug 2018, at 12:46, vikrant8051 <vikrant8051@...> wrote:

I found sample code under main tree i.e zephyr/samples/nfc/nfc_hello 
which read data on UART terminal.

But it is crasing with this log  ...

Sample app running on: arm
***** BUS FAULT *****
  Instruction bus error
***** Hardware exception *****
Current thread ID = 0x20000f24
Faulting instruction address = 0x8fccaf0
Fatal fault in essential thread! Spinning...

So I edit as
uart1_dev = device_get_binding("UART_0")

But still firmware is not printing received data back on
terminal.

Thank You !!



On Thu, Aug 23, 2018 at 6:54 PM vikrant8051 <vikrant8051@...> wrote:
Hi,

I wanna send some chuck of data over USART to #nRF52840_PDK like commands.

Is there any sample code available for it or any configuration is required to enable this USART
read feature ?

Thank You !!




Re: [Zephyr-users] [Zephyr-devel] nRF52: USART: sending data from Serial terminal to DK

Chettimada, Vinayak Kariappa
 

if you are looking for a shell, tests/bluetooth/shell could be your inspiration.

if you are looking for implementing a transport over uart, then samples/bluetooth/hci_uart could be your inspiration.

other samples and subsystems may be using UART, that could also be close to your needs. Hoping the UART API documentation in Zephyr should suffice your requirements and how to use it.

-Vinayak

On 24 Aug 2018, at 12:46, vikrant8051 <vikrant8051@...> wrote:

I found sample code under main tree i.e zephyr/samples/nfc/nfc_hello 
which read data on UART terminal.

But it is crasing with this log  ...

Sample app running on: arm
***** BUS FAULT *****
  Instruction bus error
***** Hardware exception *****
Current thread ID = 0x20000f24
Faulting instruction address = 0x8fccaf0
Fatal fault in essential thread! Spinning...

So I edit as
uart1_dev = device_get_binding("UART_0")

But still firmware is not printing received data back on
terminal.

Thank You !!



On Thu, Aug 23, 2018 at 6:54 PM vikrant8051 <vikrant8051@...> wrote:
Hi,

I wanna send some chuck of data over USART to #nRF52840_PDK like commands.

Is there any sample code available for it or any configuration is required to enable this USART
read feature ?

Thank You !!




Re: nRF52: USART: sending data from Serial terminal to DK

vikrant8051 <vikrant8051@...>
 

I found sample code under main tree i.e zephyr/samples/nfc/nfc_hello 
which read data on UART terminal.

But it is crasing with this log  ...

Sample app running on: arm
***** BUS FAULT *****
  Instruction bus error
***** Hardware exception *****
Current thread ID = 0x20000f24
Faulting instruction address = 0x8fccaf0
Fatal fault in essential thread! Spinning...

So I edit as
uart1_dev = device_get_binding("UART_0")

But still firmware is not printing received data back on
terminal.

Thank You !!



On Thu, Aug 23, 2018 at 6:54 PM vikrant8051 <vikrant8051@...> wrote:
Hi,

I wanna send some chuck of data over USART to #nRF52840_PDK like commands.

Is there any sample code available for it or any configuration is required to enable this USART
read feature ?

Thank You !!


DS-5 ARM compiler support

miem@...
 

Hi,

Does Zephyr have (or plan to add) support for DS-5 ARM compiler? 

Regards,
Mina


Re: Code cleanup for dts.fixup #defines

@ibisz
 

>What do you think? Do you see any caveats about this?

A similar or the same idea drived the #9526 PR.
I think  a prefix like dtconfig_ is  usefull in aliases definition.

Best regards,
István
 


Re: hciconfig tools error with nrf52832 running zephyr

Johan Hedberg
 

Hi,

On Thu, Aug 23, 2018, @icephyr wrote:
I bought a official nrf52832 development kits and ported zephyr
project successfully. It runs fine with my ubuntu host,via btattach
and btmgmt tools.But it didn't work with my nxp embedded linux,the
linux version is 4.1.15 and supports hciattach hciconfig tools
only.When I tried to bring the bluetooth module up with hciconfig hci0
up,an error comes up:
The 4.1 kernel is too old to support controllers without a public
address. IIRC you need at least a 4.4 kernel, but ideally something much
newer than that.

Johan


hciconfig tools error with nrf52832 running zephyr

icephyr
 

hi guys,
    I got a problem here and hope anyone can give me some advice,thanks.

    I bought a official nrf52832 development kits and ported zephyr project successfully. It runs fine with my ubuntu host,via btattach and btmgmt tools.But it didn't work with my nxp embedded linux,the linux version is 4.1.15 and supports hciattach hciconfig tools only.When I tried to bring the bluetooth module up with hciconfig hci0 up,an error comes up:

#hciconfig hci0 up
#Can't init device hci1: Cannot assign requested address (99)

has anyone met this problem before ? I don't know how to deal with it now,the hci0 can not be up status.


Re: Code cleanup for dts.fixup #defines

Andy Gross
 


On 23 August 2018 at 14:12, Diego Sueiro <diego.sueiro@...> wrote:
Andy,

This is an excellent idea.  The only downside (upside?) is having to standardize on all of the subsystem driver labels.  And it still doesn't solve the device specific properties unless we were to extend this idea to automatically generate generic labels for all device specific properties by adding a #define to point the generic label + property to the device compatible + address value.  Then you'd have to build up the platform data structures to contain this stuff.

Actually, the dts extraction already deals with the driver properties listed in the yaml file.

For example, the nxp,imx-uart.yaml, has the following #defines automatically generated for the uart-2 alias:
<build>/zephyr/include/generated/generated_dts_board.h:
#define CONFIG_UART_CONSOLE_ON_DEV_NAME         "UART_2"
#define NXP_IMX_UART_30890000_BASE_ADDRESS      0x30890000
#define NXP_IMX_UART_30890000_CURRENT_SPEED     115200
#define NXP_IMX_UART_30890000_IRQ_0             27
#define NXP_IMX_UART_30890000_IRQ_0_PRIORITY    3
#define NXP_IMX_UART_30890000_LABEL             "UART_2"
#define NXP_IMX_UART_30890000_MODEM_MODE        64
#define NXP_IMX_UART_30890000_RDC               15
#define NXP_IMX_UART_30890000_SIZE              65536
#define UART_2_BASE_ADDRESS                     NXP_IMX_UART_30890000_BASE_ADDRESS
#define UART_2_CURRENT_SPEED                    NXP_IMX_UART_30890000_CURRENT_SPEED
#define UART_2_IRQ                              NXP_IMX_UART_30890000_IRQ_0
#define UART_2_IRQ_PRIORITY                     NXP_IMX_UART_30890000_IRQ_0_PRIORITY
#define UART_2_LABEL                            NXP_IMX_UART_30890000_LABEL
#define UART_2_MODEM_MODE                       NXP_IMX_UART_30890000_MODEM_MODE
#define UART_2_RDC                              NXP_IMX_UART_30890000_RDC
#define UART_2_SIZE                             NXP_IMX_UART_30890000_SIZE

Note that RDC and MODEM_MODE are custom properties for the imx uart driver.

Ah, right.  Yeah this looks quite nice then.


Re: Code cleanup for dts.fixup #defines

Diego Sueiro
 

Andy,

This is an excellent idea.  The only downside (upside?) is having to standardize on all of the subsystem driver labels.  And it still doesn't solve the device specific properties unless we were to extend this idea to automatically generate generic labels for all device specific properties by adding a #define to point the generic label + property to the device compatible + address value.  Then you'd have to build up the platform data structures to contain this stuff.

Actually, the dts extraction already deals with the driver properties listed in the yaml file.

For example, the nxp,imx-uart.yaml, has the following #defines automatically generated for the uart-2 alias:
<build>/zephyr/include/generated/generated_dts_board.h:
#define CONFIG_UART_CONSOLE_ON_DEV_NAME         "UART_2"
#define NXP_IMX_UART_30890000_BASE_ADDRESS      0x30890000
#define NXP_IMX_UART_30890000_CURRENT_SPEED     115200
#define NXP_IMX_UART_30890000_IRQ_0             27
#define NXP_IMX_UART_30890000_IRQ_0_PRIORITY    3
#define NXP_IMX_UART_30890000_LABEL             "UART_2"
#define NXP_IMX_UART_30890000_MODEM_MODE        64
#define NXP_IMX_UART_30890000_RDC               15
#define NXP_IMX_UART_30890000_SIZE              65536
#define UART_2_BASE_ADDRESS                     NXP_IMX_UART_30890000_BASE_ADDRESS
#define UART_2_CURRENT_SPEED                    NXP_IMX_UART_30890000_CURRENT_SPEED
#define UART_2_IRQ                              NXP_IMX_UART_30890000_IRQ_0
#define UART_2_IRQ_PRIORITY                     NXP_IMX_UART_30890000_IRQ_0_PRIORITY
#define UART_2_LABEL                            NXP_IMX_UART_30890000_LABEL
#define UART_2_MODEM_MODE                       NXP_IMX_UART_30890000_MODEM_MODE
#define UART_2_RDC                              NXP_IMX_UART_30890000_RDC
#define UART_2_SIZE                             NXP_IMX_UART_30890000_SIZE

Note that RDC and MODEM_MODE are custom properties for the imx uart driver.

Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/


On Thu, 23 Aug 2018 at 19:52, Andy Gross <andy.gross@...> wrote:


On 22 August 2018 at 11:16, Diego Sueiro <diego.sueiro@...> wrote:
Folks,

I was thinking about doing a code cleanup in the dts.fixup and uart and gpio driver for the i.MX7 SoC, where we create redundant defines already covered by devicetree aliases.

Here is a breif example for the CONFIG_UART_IMX_UART_2_NAME:
boards/arm/colibri_imx7d_m4/colibri_imx7d_m4.dts:
<...>
aliases {
                <...>
                uart-2 = &uart2;
                <...>
        };
<...>

This alias will generate the following define in <build>/zephyr/include/generated/generated_dts_board.h:
#define UART_2_LABEL                        NXP_IMX_UART_30890000_LABEL


This is an excellent idea.  The only downside (upside?) is having to standardize on all of the subsystem driver labels.  And it still doesn't solve the device specific properties unless we were to extend this idea to automatically generate generic labels for all device specific properties by adding a #define to point the generic label + property to the device compatible + address value.  Then you'd have to build up the platform data structures to contain this stuff.


And the associated change will be:
diff --git a/arch/arm/soc/nxp_imx/mcimx7_m4/dts.fixup b/arch/arm/soc/nxp_imx/mcimx7_m4/dts.fixup
index f8765dc..8e46695 100644
--- a/arch/arm/soc/nxp_imx/mcimx7_m4/dts.fixup
+++ b/arch/arm/soc/nxp_imx/mcimx7_m4/dts.fixup
@@ -65,7 +65,6 @@
 #define CONFIG_UART_IMX_UART_1_IRQ_PRI      NXP_IMX_UART_30860000_IRQ_0_PRIORITY
 #define CONFIG_UART_IMX_UART_1_MODEM_MODE   NXP_IMX_UART_30860000_MODEM_MODE
 
-#define CONFIG_UART_IMX_UART_2_NAME         NXP_IMX_UART_30890000_LABEL
 #define CONFIG_UART_IMX_UART_2_BASE_ADDRESS NXP_IMX_UART_30890000_BASE_ADDRESS
 #define CONFIG_UART_IMX_UART_2_BAUD_RATE    NXP_IMX_UART_30890000_CURRENT_SPEED
 #define CONFIG_UART_IMX_UART_2_IRQ_NUM      NXP_IMX_UART_30890000_IRQ_0
diff --git a/drivers/serial/uart_imx.c b/drivers/serial/uart_imx.c
index 6a8f701..a3ef5ea 100644
--- a/drivers/serial/uart_imx.c
+++ b/drivers/serial/uart_imx.c
@@ -337,7 +337,7 @@ static const struct imx_uart_config imx_uart_2_config = {
 
 static struct imx_uart_data imx_uart_2_data;
 
-DEVICE_AND_API_INIT(uart_2, CONFIG_UART_IMX_UART_2_NAME, &uart_imx_init,
+DEVICE_AND_API_INIT(uart_2, UART_2_LABEL, &uart_imx_init,
                &imx_uart_2_data, &imx_uart_2_config,
                PRE_KERNEL_1, CONFIG_KERNEL_INIT_PRIORITY_DEVICE,
                &uart_imx_driver_api); 
I used this strategy for the imx i2c and pwm drivers.

I believe that this will simplify and let the code a little bit cleaner.

What do you think? Do you see any caveats about this? 

PS.: I found that we could potentially remove 1828 defines in dts.fixup files in master (grep -R --exclude-dir={build,samples,tests} --include="dts.fixup" "#define CONFIG_"  ./* | grep -v "PRIO_BITS" | wc -l)


Regards,

Andy


Re: Code cleanup for dts.fixup #defines

Andy Gross
 



On 22 August 2018 at 11:16, Diego Sueiro <diego.sueiro@...> wrote:
Folks,

I was thinking about doing a code cleanup in the dts.fixup and uart and gpio driver for the i.MX7 SoC, where we create redundant defines already covered by devicetree aliases.

Here is a breif example for the CONFIG_UART_IMX_UART_2_NAME:
boards/arm/colibri_imx7d_m4/colibri_imx7d_m4.dts:
<...>
aliases {
                <...>
                uart-2 = &uart2;
                <...>
        };
<...>

This alias will generate the following define in <build>/zephyr/include/generated/generated_dts_board.h:
#define UART_2_LABEL                        NXP_IMX_UART_30890000_LABEL


This is an excellent idea.  The only downside (upside?) is having to standardize on all of the subsystem driver labels.  And it still doesn't solve the device specific properties unless we were to extend this idea to automatically generate generic labels for all device specific properties by adding a #define to point the generic label + property to the device compatible + address value.  Then you'd have to build up the platform data structures to contain this stuff.


And the associated change will be:
diff --git a/arch/arm/soc/nxp_imx/mcimx7_m4/dts.fixup b/arch/arm/soc/nxp_imx/mcimx7_m4/dts.fixup
index f8765dc..8e46695 100644
--- a/arch/arm/soc/nxp_imx/mcimx7_m4/dts.fixup
+++ b/arch/arm/soc/nxp_imx/mcimx7_m4/dts.fixup
@@ -65,7 +65,6 @@
 #define CONFIG_UART_IMX_UART_1_IRQ_PRI      NXP_IMX_UART_30860000_IRQ_0_PRIORITY
 #define CONFIG_UART_IMX_UART_1_MODEM_MODE   NXP_IMX_UART_30860000_MODEM_MODE
 
-#define CONFIG_UART_IMX_UART_2_NAME         NXP_IMX_UART_30890000_LABEL
 #define CONFIG_UART_IMX_UART_2_BASE_ADDRESS NXP_IMX_UART_30890000_BASE_ADDRESS
 #define CONFIG_UART_IMX_UART_2_BAUD_RATE    NXP_IMX_UART_30890000_CURRENT_SPEED
 #define CONFIG_UART_IMX_UART_2_IRQ_NUM      NXP_IMX_UART_30890000_IRQ_0
diff --git a/drivers/serial/uart_imx.c b/drivers/serial/uart_imx.c
index 6a8f701..a3ef5ea 100644
--- a/drivers/serial/uart_imx.c
+++ b/drivers/serial/uart_imx.c
@@ -337,7 +337,7 @@ static const struct imx_uart_config imx_uart_2_config = {
 
 static struct imx_uart_data imx_uart_2_data;
 
-DEVICE_AND_API_INIT(uart_2, CONFIG_UART_IMX_UART_2_NAME, &uart_imx_init,
+DEVICE_AND_API_INIT(uart_2, UART_2_LABEL, &uart_imx_init,
                &imx_uart_2_data, &imx_uart_2_config,
                PRE_KERNEL_1, CONFIG_KERNEL_INIT_PRIORITY_DEVICE,
                &uart_imx_driver_api); 
I used this strategy for the imx i2c and pwm drivers.

I believe that this will simplify and let the code a little bit cleaner.

What do you think? Do you see any caveats about this? 

PS.: I found that we could potentially remove 1828 defines in dts.fixup files in master (grep -R --exclude-dir={build,samples,tests} --include="dts.fixup" "#define CONFIG_"  ./* | grep -v "PRIO_BITS" | wc -l)


Regards,

Andy


nRF52: USART: sending data from Serial terminal to DK

vikrant8051 <vikrant8051@...>
 

Hi,

I wanna send some chuck of data over USART to #nRF52840_PDK like commands.

Is there any sample code available for it or any configuration is required to enable this USART
read feature ?

Thank You !!


Re: bt_le_scan_start Fails with Error -5 after 128 scan start/stop cycles

Declan Traill <declan.traill@...>
 

Hi,

 

    Sorry for the delay in replying (working on another project).

 

I can confirm the problem still occurs with Controller Privacy turned off, as you suggested would be the case.

 

It sounds like you are on top of the problem – I hope to hear of a possible solution soon…

 

 

Best Regards,

Declan

 

From: Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...>
Sent: Thursday, 23 August 2018 3:21 AM
To: Johan Hedberg <johan.hedberg@...>
Cc: Declan Traill <declan.traill@...>; devel@...
Subject: Re: [Zephyr-devel] bt_le_scan_start Fails with Error -5 after 128 scan start/stop cycles

 

Hi Johan,

 

It is nothing to do with controller privacy, its just that advertiser is active and by BT Spec. 

 

If the Host issues this command when scanning or legacy advertising is enabled, the Controller shall return the error code Command Disallowed (0x0C).

 

Can we do something about this in the host, when address is regenerated?

 

- Vinayak



On 22 Aug 2018, at 14:21, Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:

 

Hi,

Could you please turn off the controller privacy feature and check if you still face issues?
CONFIG_BT_CTLR_PRIVACY=n

This is to narrow down the locality of the problem, just suspecting some race condition with the running advertiser in concurrency,

Regards,
Vinayak


On 22 Aug 2018, at 11:31, Johan Hedberg <johan.hedberg@...> wrote:

Thanks Declan. The logs do indeed show the HCI error:

[bt] [DBG] bt_hci_cmd_send_sync: (0x20004240) opcode 0x2005 status 0x0c

0x0c is the same as "Command Disallowed", i.e. the controller considers
itself to be in a state where it cannot accept a command. OpCode 0x2005
in turn is HCI_Set_Random_Address, so it's this command that the
controller is refusing to accept.

Johan

On Wed, Aug 22, 2018, Declan Traill wrote:

Hi Johan,

 I have attached a new log. This time it fails after 121 cycles (maybe the 128 was a coincidence and the extra debug has changed the timing?).

 Any ideas what is happening?

Regards,
Declan

-----Original Message-----
From: Johan Hedberg <johan.hedberg@...> 
Sent: Wednesday, 22 August 2018 2:34 PM
To: Declan Traill <declan.traill@...>
Cc: devel@...
Subject: Re: [Zephyr-devel] bt_le_scan_start Fails with Error -5 after 128 scan start/stop cycles

Hi Declan,

Could you enable the following options and try to take another log:

CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_DEBUG_HCI_CORE=y

If I remember right, EIO is just a generic mapping to any HCI error coming from the controller. Enabling the above options should hopefully reveal what that error is. If it still doesn't help we'll need to enable controller logs or take a full HCI log (using CONFIG_BT_DEBUG_MONITOR).

Johan

On Wed, Aug 22, 2018, Declan Traill wrote:

Hi,

I have a basic project that scans for 5 seconds, then stops for one second - then repeats forever.
After exactly 128 cycles, the 129th scan start (and all after that) fails with error code -5 (I think this is POSIX: #define EIO 5 /* I/O error */).

Given the number of time it works (128) it seems like a resource or memory may have run out?

Here is the debug log (attached) showing the problem: Any ideas what might be wrong & how to fix it?

Thanks...

P.S. Also at the end of this file is a fragment of debug I saw a couple of times earlier today during testing - showing a kernel error that occurred. It may be related or unrelated to the other problem??

Regards,

Declan Traill
Embedded Firmware Engineer
declan.traill@...
SETEC Pty Ltd
19 Henderson Road, Knoxfield 3180, Victoria, Australia
Phone: +61 3 9763 0962
Fax: +61 3 9763 8789
Direct: +61 3 9213 8458
setec.com.au | teambmpro.com

--------
Email from setec.com.au does not necessarily represent the official 
policy of SETEC Pty Ltd.
See http://www.setec.com.au/emaildisclaimer20060629.html for details.




***** Booting Zephyr OS v1.12.0-1096-g55f6620c3 ***** Zephyr Shell, 
Zephyr version: 1.12.99 Type 'help' for a list of available commands
shell> [bt] [INF] hci_vs_init: HW Platform: Nordic Semiconductor 
shell> (0x0002)
[bt] [INF] hci_vs_init: HW Variant: nRF52x (0x0002) [bt] [INF] 
hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 
1.12 Build 99 [bt] [WRN] bt_pub_key_gen: ECC HCI commands not 
available Bluetooth initialized [bt] [INF] bt_dev_show_info: Identity: 
c0:7e:4c:e6:8b:f3 (random) [bt] [INF] bt_dev_show_info: HCI: version 
5.0 (0x09) revision 0x0000, manufacturer 0x05f1 [bt] [INF] 
bt_dev_show_info: LMP: version 5.0 (0x09) subver 0xffff Advertising 
successfully started


Scanning Started 1

Device found in close proximity: 7a:19:47:6d:5e:b8 (random) (RSSI -70) 
Device found - 7a:19:47:6d:5e:b8 (random) - NOT bonded Scanning 
Stopped Scanning Started 2 Scanning Stopped Scanning Started 3 
Scanning Stopped Scanning Started 4
Connected: 59:75:02:8a:8f:b6 (random) (NOT Bonded) Scanning Stopped 
Scanning Started 5 Scanning Stopped Scanning Started 6 Scanning 
Stopped Scanning Started 7 Scanning Stopped Scanning Started 8 
Scanning Stopped Scanning Started 9 Scanning Stopped Scanning Started 
10 Scanning Stopped Scanning Started 11 Device found in close 
proximity: 5d:29:c2:26:6c:4c (random) (RSSI -57) Device found - 
5d:29:c2:26:6c:4c (random) - NOT bonded Scanning Stopped Scanning 
Started 12 Device found in close proximity: 5d:29:c2:26:6c:4c (random) 
(RSSI -61) Device found - 5d:29:c2:26:6c:4c (random) - NOT bonded 
Scanning Stopped Scanning Started 13 Device found in close proximity: 
5d:29:c2:26:6c:4c (random) (RSSI -48) Device found - 5d:29:c2:26:6c:4c 
(random) - NOT bonded Scanning Stopped Scanning Started 14 Device 
found in close proximity: 5d:29:c2:26:6c:4c (random) (RSSI -57) Device 
found - 5d:29:c2:26:6c:4c (random) - NOT bonded Scanning Stopped 
Scanning Started 15 Device found in close proximity: 5d:29:c2:26:6c:4c 
(random) (RSSI -57) Device found - 5d:29:c2:26:6c:4c (random) - NOT 
bonded Scanning Stopped Scanning Started 16 Device found in close 
proximity: 5d:29:c2:26:6c:4c (random) (RSSI -55) Device found - 
5d:29:c2:26:6c:4c (random) - NOT bonded Scanning Stopped Scanning 
Started 17 Device found in close proximity: 5d:29:c2:26:6c:4c (random) 
(RSSI -50) Device found - 5d:29:c2:26:6c:4c (random) - NOT bonded 
Scanning Stopped Scanning Started 18 Device found in close proximity: 
5d:29:c2:26:6c:4c (random) (RSSI -51) Device found - 5d:29:c2:26:6c:4c 
(random) - NOT bonded Scanning Stopped Scanning Started 19 Device 
found in close proximity: 5d:29:c2:26:6c:4c (random) (RSSI -57) Device 
found - 5d:29:c2:26:6c:4c (random) - NOT bonded Scanning Stopped 
Scanning Started 20 Device found in close proximity: 6f:d9:fb:62:fc:95 
(random) (RSSI -51) Device found - 6f:d9:fb:62:fc:95 (random) - NOT 
bonded Scanning Stopped Scanning Started 21 Device found in close 
proximity: 6f:d9:fb:62:fc:95 (random) (RSSI -58) Device found - 
6f:d9:fb:62:fc:95 (random) - NOT bonded Scanning Stopped Scanning 
Started 22 Device found in close proximity: 6f:d9:fb:62:fc:95 (random) 
(RSSI -53) Device found - 6f:d9:fb:62:fc:95 (random) - NOT bonded 
Scanning Stopped Scanning Started 23 Device found in close proximity: 
6f:d9:fb:62:fc:95 (random) (RSSI -52) Device found - 6f:d9:fb:62:fc:95 
(random) - NOT bonded Scanning Stopped Scanning Started 24 Scanning 
Stopped Scanning Started 25 Scanning Stopped Scanning Started 26 
Scanning Stopped Scanning Started 27 Scanning Stopped Scanning Started 
28 Scanning Stopped Scanning Started 29 Scanning Stopped Scanning 
Started 30 Scanning Stopped Scanning Started 31 Scanning Stopped 
Scanning Started 32 Scanning Stopped Scanning Started 33 Scanning 
Stopped Scanning Started 34 Scanning Stopped Scanning Started 35 
Scanning Stopped Scanning Started 36 Scanning Stopped Scanning Started 
37 Scanning Stopped Scanning Started 38 Scanning Stopped Scanning 
Started 39 Device found in close proximity: 72:bd:c4:8a:51:23 (random) 
(RSSI -70) Device found - 72:bd:c4:8a:51:23 (random) - NOT bonded 
Scanning Stopped Scanning Started 40 Scanning Stopped Scanning Started 
41 Device found in close proximity: 72:bd:c4:8a:51:23 (random) (RSSI 
-70) Device found - 72:bd:c4:8a:51:23 (random) - NOT bonded Scanning 
Stopped Scanning Started 42 Scanning Stopped Scanning Started 43 
Scanning Stopped Scanning Started 44 Scanning Stopped Scanning Started 
45 Scanning Stopped Scanning Started 46 Scanning Stopped Scanning 
Started 47 Scanning Stopped Scanning Started 48 Scanning Stopped 
Scanning Started 49 Scanning Stopped Scanning Started 50 Scanning 
Stopped Scanning Started 51 Scanning Stopped Scanning Started 52 
Scanning Stopped Scanning Started 53 Scanning Stopped Scanning Started 
54 Scanning Stopped Scanning Started 55 Device found in close 
proximity: 72:bd:c4:8a:51:23 (random) (RSSI -69) Device found - 
72:bd:c4:8a:51:23 (random) - NOT bonded Scanning Stopped Scanning 
Started 56 Scanning Stopped Scanning Started 57 Scanning Stopped 
Scanning Started 58 Scanning Stopped Scanning Started 59 Scanning 
Stopped Scanning Started 60 Scanning Stopped Scanning Started 61 
Scanning Stopped Scanning Started 62 Scanning Stopped Scanning Started 
63 Scanning Stopped Scanning Started 64 Scanning Stopped Scanning 
Started 65 Scanning Stopped Scanning Started 66 Scanning Stopped 
Scanning Started 67 Scanning Stopped Scanning Started 68 Scanning 
Stopped Scanning Started 69 Scanning Stopped Scanning Started 70 
Scanning Stopped Scanning Started 71 Scanning Stopped Scanning Started 
72 Scanning Stopped Scanning Started 73 Scanning Stopped Scanning 
Started 74 Scanning Stopped Scanning Started 75 Scanning Stopped 
Scanning Started 76 Scanning Stopped Scanning Started 77 Scanning 
Stopped Scanning Started 78 Scanning Stopped Scanning Started 79 
Scanning Stopped Scanning Started 80 Scanning Stopped Scanning Started 
81 Scanning Stopped Scanning Started 82 Scanning Stopped Scanning 
Started 83 Scanning Stopped Scanning Started 84 Scanning Stopped 
Scanning Started 85 Device found in close proximity: 7a:19:47:6d:5e:b8 
(random) (RSSI -69) Device found - 7a:19:47:6d:5e:b8 (random) - NOT 
bonded Scanning Stopped Scanning Started 86 Device found in close 
proximity: 7a:19:47:6d:5e:b8 (random) (RSSI -69) Device found - 
7a:19:47:6d:5e:b8 (random) - NOT bonded Scanning Stopped Scanning 
Started 87 Scanning Stopped Scanning Started 88 Scanning Stopped 
Scanning Started 89 Scanning Stopped Scanning Started 90 Scanning 
Stopped Scanning Started 91 Scanning Stopped Scanning Started 92 
Scanning Stopped Scanning Started 93 Scanning Stopped Scanning Started 
94 Scanning Stopped Scanning Started 95 Scanning Stopped Scanning 
Started 96 Scanning Stopped Scanning Started 97 Scanning Stopped 
Scanning Started 98 Scanning Stopped Scanning Started 99 Scanning 
Stopped Scanning Started 100 Scanning Stopped Scanning Started 101 
Scanning Stopped Scanning Started 102 Scanning Stopped Scanning 
Started 103 Scanning Stopped Scanning Started 104 Scanning Stopped 
Scanning Started 105 Scanning Stopped Scanning Started 106 Scanning 
Stopped Scanning Started 107 Device found in close proximity: 
88:6b:0f:07:08:fc (public) (RSSI -70) Device found - 88:6b:0f:07:08:fc 
(public) - NOT bonded Scanning Stopped Scanning Started 108 Device 
found in close proximity: 88:6b:0f:07:08:fc (public) (RSSI -70) Device 
found - 88:6b:0f:07:08:fc (public) - NOT bonded Scanning Stopped 
Scanning Started 109 Scanning Stopped Scanning Started 110 Scanning 
Stopped Scanning Started 111 Scanning Stopped Scanning Started 112 
Device found in close proximity: 88:6b:0f:07:08:fc (public) (RSSI -70) 
Device found - 88:6b:0f:07:08:fc (public) - NOT bonded Scanning 
Stopped Scanning Started 113 Device found in close proximity: 
88:6b:0f:07:08:fc (public) (RSSI -70) Device found - 88:6b:0f:07:08:fc 
(public) - NOT bonded Scanning Stopped Scanning Started 114 Device 
found in close proximity: 88:6b:0f:07:08:fc (public) (RSSI -70) Device 
found - 88:6b:0f:07:08:fc (public) - NOT bonded Scanning Stopped 
Scanning Started 115 Device found in close proximity: 
88:6b:0f:07:08:fc (public) (RSSI -70) Device found - 88:6b:0f:07:08:fc 
(public) - NOT bonded Scanning Stopped Scanning Started 116 Scanning 
Stopped Scanning Started 117 Device found in close proximity: 
88:6b:0f:07:08:fc (public) (RSSI -70) Device found - 88:6b:0f:07:08:fc 
(public) - NOT bonded Scanning Stopped Scanning Started 118 Scanning 
Stopped Scanning Started 119 Scanning Stopped Scanning Started 120 
Scanning Stopped Scanning Started 121 Device found in close proximity: 
88:6b:0f:07:08:fc (public) (RSSI -70) Device found - 88:6b:0f:07:08:fc 
(public) - NOT bonded Scanning Stopped Scanning Started 122 Scanning 
Stopped Scanning Started 123 Scanning Stopped Scanning Started 124 
Scanning Stopped Scanning Started 125 Scanning Stopped Scanning 
Started 126 Scanning Stopped Scanning Started 127 Scanning Stopped 
Scanning Started 128 Device found in close proximity: 
88:6b:0f:07:08:fc (public) (RSSI -70) Device found - 88:6b:0f:07:08:fc 
(public) - NOT bonded Scanning Stopped Scanning failed to start 129 
(err -5) Scanning Stopped Scanning failed to start 130 (err -5) 
Scanning Stopped Scanning failed to start 131 (err -5) Scanning 
Stopped Scanning failed to start 132 (err -5) Scanning Stopped 
Scanning failed to start 133 (err -5) Scanning Stopped Scanning failed 
to start 134 (err -5)




Scanning failed to start (err -5)
Scanning failed to start (err -5)
[bt] [ERR] rpa_adv_refresh: assert: 'idx < ((unsigned long) (((int) 
sizeof(char[1 - 2 * !(!__builtin_types_compatible_p(__typeof__(rl), 
__typeof__(&(rl)[0])))]) - 1) + (sizeof(rl) / sizeof((rl)[0]))))' 
failed
***** Kernel OOPS! *****
Current thread ID = 0x20004a10
Faulting instruction address = 0x2a134 Fatal fault in thread 
0x20004a10! Aborting.
Scanning failed to start (err -5)
Scanning failed to start (err -5)
S




--------
Email from setec.com.au does not necessarily represent the official
policy of SETEC Pty Ltd.
See http://www.setec.com.au/emaildisclaimer20060629.html for details.






 



Email from setec.com.au does not necessarily represent the official policy of SETEC Pty Ltd.
See Email Disclaimer 20060629 for details.



Applying TDD to an IP stack issue

Paul Sokolovsky
 

Hello Oleg,

I'm writing to you about your project to develop a testsuite for Zephyr
networking stack using TTCN-3 test language,
https://github.com/intel/net-test-suites . I also cc: this to Zephyr's
development list, as I think the project don't get the attention it
deserves, so the more public discussions about it, the more network
developers will hopefully catch up with it.

So, it's nice to have a dozen or so of tests which pass for Zephyr now.
But the problem we have is that not all things work as expected and not
all cases handled. In other words, we need tests which fail for Zephyr,
to be able to fix them.

I finally throughly investigated and confirmed one such "not handled"
case - TCP FIN packets aren't being retransmitted by Zephyr:
https://github.com/zephyrproject-rtos/zephyr/issues/8188, and I wonder
if you'd be interested in making a test out of it, while I'm working
on a fix, essentially trying to apply TDD (test-driven development)
practice to this case, i.e. when if a bug is discovered, a test for it
is written, before proceeding with developing a fix, so a fix can be
readily verified with the test.

The case is follows: any packet in TCP communication should be queued
for retransmission, and be retransmitted if not ACKed in expected
time. Unfortunately, so far Zephyr queues and retransmits only data
packets, SYN and FIN packets aren't retransmitted. Unfortunately again,
SYN and FIN paths are sufficiently different in Zephyr implementation,
so for now I concentrate on FIN.

The simplest test would be as follows: it should be an active close,
i.e. connection close should happen on Zephyr side. Then test would
expect to receive a FIN pkt, but should ignore it and not send an ACK.
Then the test should verify that a FIN retransmission is received
within reasonable time.

Unfortunately, I'm neither familiar with TTCN-3, nor have resources
now to jump into learning it, so calling for your interest seems like
the best option to keep driving the testsuite project forward. It can
be a useful learning starter/exercise for other networking developers
too, if you showed how textual test spec above translates to TTCN-3
script.


Thanks in advance,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Enable SPI driver on nrf52840

Jan Van Winkel
 

Hi Chuck,

On top of CONFIG_SPI you have to specify which SPI interface your are using, that it is a NRFX SPI and the associated pins in your prj.conf.

Here is an example for the nrf52840_pca10056 I used in a pull request (#6826):
CONFIG_SPI=y
CONFIG_SPI_1=y
CONFIG_SPI_NRFX=y
CONFIG_SPI_1_NRF_SPIM=y
CONFIG_SPI_1_IRQ_PRI=10
CONFIG_SPI_1_NRF_SCK_PIN=3
CONFIG_SPI_1_NRF_MOSI_PIN=28
CONFIG_SPI_1_NRF_MISO_PIN=29

Regards,
Jan


On Thu, Aug 23, 2018 at 6:03 AM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
Hi Chuck,

All that I am sayings is, do not modify your repository, do not add anything to prj,conf file.
execute cmake, then either use make or ninja for the target config or menuconfig. Then you get to the Kconfig options for SPI and I2C drivers, select and fill all necessary details like the IRQ priorities and pins etc.
Mind you if the dependencies are not filled correctly, you will need to start all over again (clean, seems some issue with unassigned values to Kconfig options).

Meanwhile, issue with cmake or make failing fatally for missing dependencies will be looked into, https://github.com/zephyrproject-rtos/zephyr/issues/9573

Sebastian / Ulf,
Seems the make menuconfig is un-usable if dependencies like pin assignments are missing after enabling SPI driver for nRF52840.

Regards,
Vinayak

On 23 Aug 2018, at 04:16, cpmcparland@... wrote:

Vinayak,

Thanks for being persistent in looking at this issue.  Sorry for some confusion, I probably didn't state
the behavior I'm seeing very clearly.  At this point, the issue is that the cmake does NOT properly
complete when I include "CONFIG_SPI=y" in the prj.conf file.  My comment about menuconfig  was
just that, in my situation, it was not usable because the make files had not been created by the
cmake script that failed......sorry if that caused some confusion.

When I add CONFIG_SPI=y to the prj.conf file and do a clean cmake for BOARD=nrg52840_pca10056, I
get the following error from cmake:

CMake Error at ../../../CMakeLists.txt:527 (message):
  The Zephyr library 'drivers__spi' was created without source files.  Empty
  (non-imported) libraries are not supported.  Either make sure that the
  library has the sources it should have, or make sure it is not created when
  it has no source files.

Cmake has created all directories in my target directory (......./build/nrf52840_pca10056/zephyr/drivers/......)
But, no source files have been copied into them from the kernel tree.

When I do the same operation, but targeting a different board (arduino_101), the directories get created
and, under target directory root (...../build/arduino_101/zephyr/drivers/spi), the correct board drivers have
been copied.  Cmake completes successfully and the make also completes successfully.

Is there a magic "CONFIG_XXX" that I just don't know about?

Regards,
Chuck


Re: Zephyr 1.13rc1 tagged

Paul Sokolovsky
 

Hello Anas,

On Thu, 23 Aug 2018 04:19:51 +0000
"Nashif, Anas" <anas.nashif@...> wrote:

Hi,
We have tagged Zephyr 1.13 rc1 and with that closed the merge window
for 1.13. Focus now will go into bug fixing, testing and
documentation. All new features will be merged after 1.13 is released.
Thanks for the prompt pre-release process notifications to the mailing
list this cycle. Hope it'll become a good tradition ;-).

The change log since 1.12 and release notes can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.13.0-rc1
Any reminder/suggestion where/how to contribute notes for the master
changelog of this release (e.g. of breaking changes)? I grepped thru
tickets/PRs at the beginning of this week and don't think I found
something. Actually, I have no idea who's release manager this cycle, as
https://github.com/zephyrproject-rtos/zephyr/issues/8320 is unassigned.

(I can make wild guesses of course ;-). And yeah, I'm sure everyone,
including me, takes it easy - it's vacation times, so everyone misses
something. Again, I'm only pleasantly surprised about mailing list
notices).



Thank you all for the contributions and support,
Anas Nashif
Thanks!

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Zephyr 1.13rc1 tagged

Nashif, Anas
 

Hi,

We have tagged Zephyr 1.13 rc1 and with that closed the merge window for 1.13. Focus now will go into bug fixing, testing and documentation. All new features will be merged after 1.13 is released.

 

The change log since 1.12 and release notes can be found here:

 

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.13.0-rc1

 

Thank you all for the contributions and support,

Anas Nashif


Re: Enable SPI driver on nrf52840

Chettimada, Vinayak Kariappa
 

Hi Chuck,

All that I am sayings is, do not modify your repository, do not add anything to prj,conf file.
execute cmake, then either use make or ninja for the target config or menuconfig. Then you get to the Kconfig options for SPI and I2C drivers, select and fill all necessary details like the IRQ priorities and pins etc.
Mind you if the dependencies are not filled correctly, you will need to start all over again (clean, seems some issue with unassigned values to Kconfig options).

Meanwhile, issue with cmake or make failing fatally for missing dependencies will be looked into, https://github.com/zephyrproject-rtos/zephyr/issues/9573

Sebastian / Ulf,
Seems the make menuconfig is un-usable if dependencies like pin assignments are missing after enabling SPI driver for nRF52840.

Regards,
Vinayak

On 23 Aug 2018, at 04:16, cpmcparland@... wrote:

Vinayak,

Thanks for being persistent in looking at this issue.  Sorry for some confusion, I probably didn't state
the behavior I'm seeing very clearly.  At this point, the issue is that the cmake does NOT properly
complete when I include "CONFIG_SPI=y" in the prj.conf file.  My comment about menuconfig  was
just that, in my situation, it was not usable because the make files had not been created by the
cmake script that failed......sorry if that caused some confusion.

When I add CONFIG_SPI=y to the prj.conf file and do a clean cmake for BOARD=nrg52840_pca10056, I
get the following error from cmake:

CMake Error at ../../../CMakeLists.txt:527 (message):
  The Zephyr library 'drivers__spi' was created without source files.  Empty
  (non-imported) libraries are not supported.  Either make sure that the
  library has the sources it should have, or make sure it is not created when
  it has no source files.

Cmake has created all directories in my target directory (......./build/nrf52840_pca10056/zephyr/drivers/......)
But, no source files have been copied into them from the kernel tree.

When I do the same operation, but targeting a different board (arduino_101), the directories get created
and, under target directory root (...../build/arduino_101/zephyr/drivers/spi), the correct board drivers have
been copied.  Cmake completes successfully and the make also completes successfully.

Is there a magic "CONFIG_XXX" that I just don't know about?

Regards,
Chuck