Date   

Re: Configure microphones on ST Discovery kit IoT node

Daniele Bortoluzzi <danieleb88@...>
 

Hi,
I also tried these configurations, according to .dts specs:

prj.conf:
CONFIG_DMA=y

app.overlay:
/ {
soc {
i2c4: i2c@40005800 {
compatible = "st,stm32-i2c-v2";
#address-cells = <1>;
#size-cells = <0>;
label= "I2C_4";

status = "okay";
pinctrl-names = "default";
clock-frequency = <I2C_BITRATE_FAST_PLUS>;

mp34dt01@0 {
compatible = "st,mpxxdtyy";
reg = <0>;
label = "MP34DT01";
};
};
};

i2c4_ck_pe9: i2c4_ck_pe9@0 {
pinmux = <STM32_PINMUX('E', 9, GPIO)>;
drive-open-drain;
};

i2c4_da_pe7: i2c4_da_pe7@0 {
pinmux = <STM32_PINMUX('E', 7, GPIO)>;
drive-open-drain;
};
};

&i2c4 {
pinctrl-names = "default";
pinctrl-0 = <&i2c4_ck_pe9 &i2c4_da_pe7>;
};

But it doesn't compile:
Error: disco_l475_iot1.dts.pre.tmp:1939.55-56 syntax error
FATAL ERROR: Unable to parse input tree



Il giorno mer 9 mar 2022 alle ore 09:48 Daniele Bortoluzzi <danieleb88@...> ha scritto:
Hi,
I'm Bortoluzzi Daniele, and I'm developing, for my master's thesis with University of Turin, a project using platformio and zephyr, helped by my thesis advisor and co-supervisor.

I would like to use the microphone (MP34DT01) of the B-L475E-IOT01A (ST Discovery kit IoT node) in a zephyr project. This mcu is supported by zephyr, but the .dts file doesn't configure the interface used by mic.

According with the hardware specs [1], I tried to start from zephyr example using st_mpxxdtyy driver [2] and configure:

prj.conf:

CONFIG_AUDIO=y
CONFIG_AUDIO_DMIC=y
CONFIG_AUDIO_MPXXDTYY=y


app.overlay:

&XXXX {
     status = "okay";
     pinctrl-0 = <&YYYY &ZZZZ>;
     pinctrl-names = "default";

     mp34dt01: mp34dt01@0 {
            compatible = "st,mpxxdtyy";
            reg = <0>;
            label = "MP34DT01";
     };
};


According with the specs [1] and analyzing the ST function pack FP-AI-SENSING1 [4], we think we should use:
- DFSDM1_CKOUT —» pin PE9
- DFSDM1_DATIN2 —» pin PE7
but we don't know how to write the DTS file.

In particular, about the app.overlay, we are not sure:
- which interface to use (XXXX field)
- which pin variables to use (YYYY, ZZZZ fields).

Could you please help us?

Thank you very much for your support.

Daniele

Some infos:


Security WG - meeting agenda, March 14

Flavio Ceolin
 

Hi everyone,

Following the proposed agenda for our next meeting:

- Kick off the group
- PSA crypto API adoption on Zephyr


p.s: I've broadcasted this email to several mailing lists just
because this is the first meeting for this group.

Regards,
Flavio Ceolin


Use of __attribute__((uncached)) using the ARC toolchain

nikola.neskovic995@...
 

Hi, I am trying to make an array that would bypass cache. I declare it like this:
volatile __attribute__((aligned(64))) __attribute__((packed)) uint32_t __attribute__((uncached)) buffer[4] = {0}

After the declaration I fill my buffer in a simple for loop:
for(i = 0; i < size; i++) { buffer[i] = i; }

And after compilation for my for loop I get the following asm code:
mov_sr    0,0
mov_s    r14,<buffer_address>
add2    r1,r14,r0
st_s    r0,[r1,0]
add_s    r0,r0,1
brne_nt    r0,<size>,-14

From what I understand about the _uncached_ attribute instead of the st_s command, in my disassembly, I should get st.di.

I found a workaround using pointers, so if I just declare a pointer like this:
volatile uint32_t __attribute__((uncached)) *help = (volatile uint32_t *)(buffer)
and I use it in the for loop instead of the buffer I get the st.di commands correctly.

I am using the zephyr_sdk_0.12.4 version of ARC toolchain.
I don't know if this is the best place to ask this question, but if anyone has an answer for this of can direct me to another list I would very much appreciate that.

Thanks in advance :)


Security Working Group invitation

Flavio Ceolin
 

Hi everyone,


I'd like to invite anyone to join the new working group dedicated to
security on Zephyr. Information about meetings and mailing list can
be found in:

https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings#security-working-group
https://lists.zephyrproject.org/g/security-wg



Regards,
Flavio Ceolin


Re: Zephyr Example Application cannot be built

Jonathan Hahn
 

Hey,

I did not try to build myself, but after quickly looking into your code, I have
a few ideas, you could give a try:

  • The dts/bindings filenames are missing your `x`.
  • You could use 
    const struct device *dev = DEVICE_DT_GET(LSM6DSOX_LABEL);
    instead of device_get_binding
    If sensor driver was not compiled, it should fail at compile time.
  • Your root/Kconfig and app/Kconfig seem to duplicate stuff.
  • drivers/sensor/CMakeLists.txt does not use add_subdirectory_ifdef, not sure whether the if clause does what it is intended to do.

Not very convinced that looking in any of those solves your issue. Hope it helps though.

Best regards

Jonathan

Am 10.03.22 um 11:26 schrieb lau kc:

Hi,
  I would like to develop an out-of-tree driver and there is an example provided in zephyrproject-rtos github(https://github.com/zephyrproject-rtos/example-application).

  I have followed the example and built a project with a sensor driver. The driver is a copy of lsm6dso and renamed to lsm6dsox for testing. There is no error message when building the project but I noticed that the drivers have not been imported. 

  If I move the out-of-tree driver to the root zephyr driver directory(driver and dts).
Everything is working fine and the driver can be correctly imported. But that is not the goal of an out-of-tree driver.

  Could anyone give me advice?

-yes.png is the sample project containing the .c file is built.
-no.png is the out-of-tree project that does not contain the .c file.
-copy_to_driver.png is the out-of-tree project that contains the .c file by copying the out-of-tree driver to the zephyr driver directory.
-.zip if the out-of-tree project for testing.


Zephyr Example Application cannot be built

lau kc <kclauah@...>
 

Hi,
  I would like to develop an out-of-tree driver and there is an example provided in zephyrproject-rtos github(https://github.com/zephyrproject-rtos/example-application).

  I have followed the example and built a project with a sensor driver. The driver is a copy of lsm6dso and renamed to lsm6dsox for testing. There is no error message when building the project but I noticed that the drivers have not been imported. 

  If I move the out-of-tree driver to the root zephyr driver directory(driver and dts).
Everything is working fine and the driver can be correctly imported. But that is not the goal of an out-of-tree driver.

  Could anyone give me advice?

-yes.png is the sample project containing the .c file is built.
-no.png is the out-of-tree project that does not contain the .c file.
-copy_to_driver.png is the out-of-tree project that contains the .c file by copying the out-of-tree driver to the zephyr driver directory.
-.zip if the out-of-tree project for testing.


Configure microphones on ST Discovery kit IoT node

Daniele Bortoluzzi <danieleb88@...>
 

Hi,
I'm Bortoluzzi Daniele, and I'm developing, for my master's thesis with University of Turin, a project using platformio and zephyr, helped by my thesis advisor and co-supervisor.

I would like to use the microphone (MP34DT01) of the B-L475E-IOT01A (ST Discovery kit IoT node) in a zephyr project. This mcu is supported by zephyr, but the .dts file doesn't configure the interface used by mic.

According with the hardware specs [1], I tried to start from zephyr example using st_mpxxdtyy driver [2] and configure:

prj.conf:

CONFIG_AUDIO=y
CONFIG_AUDIO_DMIC=y
CONFIG_AUDIO_MPXXDTYY=y


app.overlay:

&XXXX {
     status = "okay";
     pinctrl-0 = <&YYYY &ZZZZ>;
     pinctrl-names = "default";

     mp34dt01: mp34dt01@0 {
            compatible = "st,mpxxdtyy";
            reg = <0>;
            label = "MP34DT01";
     };
};


According with the specs [1] and analyzing the ST function pack FP-AI-SENSING1 [4], we think we should use:
- DFSDM1_CKOUT —» pin PE9
- DFSDM1_DATIN2 —» pin PE7
but we don't know how to write the DTS file.

In particular, about the app.overlay, we are not sure:
- which interface to use (XXXX field)
- which pin variables to use (YYYY, ZZZZ fields).

Could you please help us?

Thank you very much for your support.

Daniele

Some infos:


Re: Configure BLE Module on STEVAL-MKSBOX1V1

Daniele Bortoluzzi <danieleb88@...>
 

I noticed that specific code too, and I agreed with you that probably we should adapt hci_spi driver.
Unfortunately, at the moment, it's out of scope for my thesis, because I don't have too much time to spend on it.

Thank you very much for your support.

Best regards,
Daniele

Il giorno lun 7 mar 2022 alle ore 16:45 Erwan Gouriou <erwan.gouriou@...> ha scritto:
If you look at code under BT_SPI_BLUENRG, you'll see that it proposes some specific code that 
was required to add on top of bare hci_spi driver to get the module working.

I haven't add a look to other BlueNRG modules, but it's possible they require similar adaptation,
for this I suggest to have a check on modules documentation and see what is required to integrate
them with a bluetooth host over a HCI link.

Cheers
Erwan

On Tue, 1 Mar 2022 at 21:54, Daniele Bortoluzzi <danieleb88@...> wrote:
Hi Erwan,
thank you for the response.

We are using sensortile.box with SPBTLE-1S BLE v4.2 connectivity. In fact we are currently don't use BT_SPI_BLUENRG config.

What do you suggest us to integrate SPBTLE-1S? Is our .dts correct? Are there in zephyr other mcus supported that are using same connectivity?

Thank you.

Best regards

Daniele

Il mar 1 mar 2022, 09:56 Erwan Gouriou <erwan.gouriou@...> ha scritto:
Hello Daniele,

You're globally in the right direction, but please note that stm32l562_dk actually uses a SPBTLE-RFTR module, based on BlueNRG-MS (BLE v4.1).
SensorTile board use, depending on version:
- SPBTLE-1S Bluetooth Smart connectivity (BLE v4.2)
- BlueNRG-M2 (BLE v5.2)

These modules might differ from BlueNRG-MS on SPI API, likely not needing BT_SPI_BLUENRG,
or requiring an adaptation. Please refer to their respective manuals to see how to integrate them.

BR
Erwan

On Mon, 28 Feb 2022 at 13:23, Daniele Bortoluzzi <danieleb88@...> wrote:
Hi,
I'm Bortoluzzi Daniele, and I'm developing, for my master's thesis with University of Turin, a project using platformio and zephyr.

I would like to use the Ble Module (SPBTLE-1S) of the STEVAL-MKSBOX1V1 (SensorTile.box) in a zephyr project. This mcu is supported by zephyr, but the .dts file doesn't configure the spi2 interface used by bluetooth.

According with the hardware specs [1], I tried to start from ST BLE sensor project example [2] and configure:

prj.conf:

CONFIG_BT_SPI=y
CONFIG_BT_HCI=y
CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="SPBTLE-1S"
CONFIG_BT_GATT_CLIENT=y

app.overlay:

/ {
    chosen {
           zephyr,bt-hci-spi = &zephyr_bt_hci_spi;
           zephyr,bt-hci-spi-slave = &zephyr_bt_hci_spi_slave;
    };
};

&spi2 {
    pinctrl-0 = <&spi2_nss_pd0 &spi2_sck_pd1 &spi2_miso_pd3 &spi2_mosi_pc3>;
    pinctrl-names = "default";
    status = "okay";

    cs-gpios = <&gpiod 0 GPIO_ACTIVE_LOW>;

    zephyr_bt_hci_spi: zephyr_bt_hci_spi@0 {
        compatible = "zephyr,bt-hci-spi";
        reg = <0>;
        irq-gpios = <&gpiod 4 GPIO_ACTIVE_LOW>;
        reset-gpios = <&gpioa 8 GPIO_ACTIVE_LOW>;
        spi-max-frequency = <1000000>;
        label = "SPBTLE-1S";
    };

    zephyr_bt_hci_spi_slave: zephyr_bt_hci_spi_slave@1 {
        compatible = "zephyr,bt-hci-spi-slave";
        reg = <1>;
        irq-gpios = <&gpiod 4 GPIO_ACTIVE_LOW>;
    };
};

Unfortunately, bluetooth isn't enabled correctly and the system hangs up:
in the main.c, the bt_enable waits endlessly, because the function bt_spi_rx_thread of the file https://github.com/zephyrproject-rtos/zephyr/blob/v2.7-branch/drivers/bluetooth/hci/spi.c (line 343) doesn't return, looping in the do-while.

Thank you very much for your support.


The wrong project conf file is merged in .config #nrf52

Mohamed Belaroussi
 

Hello,

I am using nRF52833 Soc with nRF Connect SDK v1.7.0 and SES (Nordic Edition) v5.6.0 (64-bit).
I have two project configuration files prj_debug.conf and prj_release.conf
I switch between the two using the method described below,

Tools > Options > nRF Connect > Additional CMake Options -DCONF_FILE=prj_release.conf

File > Open nRF Connect SDK Project... to re-open the project

I tried to do the above with and without selecting a 'Clean Build Directory'?

In both cases I see in SES logs that prj_debug.conf is being merged instead of prj_release.conf as specified in -DCONF_FILE=prj_release.conf. See logs below.
Can someone please enlighten me and tell me what I am doing wrong.

Creating solution HomeBeacon_dev_sb.emProject                                    C:/Zypher/v1.7.0/toolchain/opt/bin/cmake.exe -GNinja -DBOARD=nrf52833dk_nrf52833 -DBOARD_DIR=C:\Zypher\v1.7.0\zephyr\boards\arm\nrf52833dk_nrf52833 -BC:\Sandbox\HomeBeacon_dev_sb\build_nrf52833dk_nrf52833_rel_v1_3_99 -SC:\Sandbox\HomeBeacon_dev_sb -DNCS_TOOLCHAIN_VERSION=1.7.0 -DCONF_FILE=prj_release.conf -DDTC_OVERLAY_FILE=C:/Sandbox/HomeBeacon_dev_sb/nrf52833dk_nrf52833.overlay -DEXTRA_KCONFIG_TARGETS=menuconfig_ses -DEXTRA_KCONFIG_TARGET_COMMAND_FOR_menuconfig_ses=C:\Zypher\v1.7.0\toolchain\segger_embedded_studio/html/configure_nordic_project_menuconfig.py
-- Application: C:/Sandbox/HomeBeacon_dev_sb
-- Zephyr version: 2.6.99 (C:/Zypher/v1.7.0/zephyr), build: v2.6.99-ncs1
-- Found Python3: C:/Zypher/v1.7.0/toolchain/opt/bin/python.exe (found suitable exact version "3.8.2") found components: Interpreter
-- Found west (found suitable version "0.11.1", minimum required is "0.7.1")
-- Board: nrf52833dk_nrf52833
-- Cache files will be written to: C:/Zypher/v1.7.0/zephyr/.cache
-- Found dtc: C:/Zypher/v1.7.0/toolchain/opt/bin/dtc.exe (found suitable version "1.4.7", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (C:/Zypher/v1.7.0/toolchain/opt)
-- Found BOARD.dts: C:/Zypher/v1.7.0/zephyr/boards/arm/nrf52833dk_nrf52833/nrf52833dk_nrf52833.dts
-- Found devicetree overlay: C:/Sandbox/HomeBeacon_dev_sb/nrf52833dk_nrf52833.overlay
-- Generated zephyr.dts: C:/Sandbox/HomeBeacon_dev_sb/build_nrf52833dk_nrf52833_rel_v1_3_99/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: C:/Sandbox/HomeBeacon_dev_sb/build_nrf52833dk_nrf52833_rel_v1_3_99/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: C:/Sandbox/HomeBeacon_dev_sb/build_nrf52833dk_nrf52833_rel_v1_3_99/zephyr/include/generated/device_extern.h
-- Including generated dts.cmake file: C:/Sandbox/HomeBeacon_dev_sb/build_nrf52833dk_nrf52833_rel_v1_3_99/zephyr/dts.cmake
Parsing C:/Sandbox/HomeBeacon_dev_sb/Kconfig
Loaded configuration 'C:/Zypher/v1.7.0/zephyr/boards/arm/nrf52833dk_nrf52833/nrf52833dk_nrf52833_defconfig'
Merged configuration 'C:/Sandbox/HomeBeacon_dev_sb/prj_debug.conf'
Configuration saved to 'C:/Sandbox/HomeBeacon_dev_sb/build_nrf52833dk_nrf52833_rel_v1_3_99/zephyr/.config'
Kconfig header saved to 'C:/Sandbox/HomeBeacon_dev_sb/build_nrf52833dk_nrf52833_rel_v1_3_99/zephyr/include/generated/autoconf.h'

...

Also, what is the difference between re-opening and re-loading a project in Segger Embedded Studio (SES-NE)?

Thank you.

Kind regards

Mohamed

 

 
 


Re: Problems setting up ethernet mac address on STM32H753ZI

Weiberg, Bernd
 

PR has been submitted now.

By the way:

The change of the mac address works fine now and the new one will be used consequently now by the whole network stack.

 

Thanks a lot.

 

Von: Jukka Rissanen <jukka.rissanen@...>
Gesendet: Dienstag, 8. März 2022 13:33
An: Weiberg, Bernd (SMO RI R&D DF 1) <bernd.weiberg@...>; users@...
Betreff: Re: AW: [Zephyr-users] Problems setting up ethernet mac address on STM32H753ZI

 

Hi Bernd,

 

Indeed, the code should return the value of "ret" variable. Would you be able to send a PR that fixes the issue?

 

 

Cheers,

Jukka

 

 

On Tue, 2022-03-08 at 11:21 +0000, Weiberg, Bernd wrote:

Hi Jukka,

thanks for hat good advice!

I have tried to change the mac address using the net_mgmt API as it can be found in the example you suggested.

net_mgmt(NET_REQUEST_ETHERNET_SET_MAC_ADDRESS, ..) returns -ENOTSUP (134) in my case.

After some deeper investigations if found out, that there might be a bug in the underlaying driver eth_stm32_hal.c.

The Code of eth_stm32_hal_set_config() always returns -ENOTSUP even if everything is fine.

In my opinion the last return have to be changed from return -ENOTSUP to return ret;

How can I address this error?

See code below:

 

static int eth_stm32_hal_set_config(const struct device *dev,

                                                                   enum ethernet_config_type type,

                                                                   const struct ethernet_config *config)

{

                int ret = -ENOTSUP;

                struct eth_stm32_hal_dev_data *dev_data;

                ETH_HandleTypeDef *heth;

 

                dev_data = dev->data;

                heth = &dev_data->heth;

 

                switch (type) {

                case ETHERNET_CONFIG_TYPE_MAC_ADDRESS:

                               memcpy(dev_data->mac_addr, config->mac_address.addr, 6);

                               heth->Instance->MACA0HR = (dev_data->mac_addr[5] << 8) |

                                               dev_data->mac_addr[4];

                               heth->Instance->MACA0LR = (dev_data->mac_addr[3] << 24) |

                                               (dev_data->mac_addr[2] << 16) |

                                               (dev_data->mac_addr[1] << 8) |

                                               dev_data->mac_addr[0];

                               net_if_set_link_addr(dev_data->iface, dev_data->mac_addr,

                                                                    sizeof(dev_data->mac_addr),

                                                                    NET_LINK_ETHERNET);

                               ret = 0;

                               break;

                case ETHERNET_CONFIG_TYPE_PROMISC_MODE:

#if defined(CONFIG_NET_PROMISCUOUS_MODE)

#if defined(CONFIG_SOC_SERIES_STM32H7X)

                               if (config->promisc_mode) {

                                               heth->Instance->MACPFR |= ETH_MACPFR_PR;

                               } else {

                                               heth->Instance->MACPFR &= ~ETH_MACPFR_PR;

                               }

#else

                               if (config->promisc_mode) {

                                               heth->Instance->MACFFR |= ETH_MACFFR_PM;

                               } else {

                                               heth->Instance->MACFFR &= ~ETH_MACFFR_PM;

                               }

#endif  /* CONFIG_SOC_SERIES_STM32H7X */

                               ret = 0;

#endif /* CONFIG_NET_PROMISCUOUS_MODE */

                               break;

                default:

                               break;

                }

 

                return -ENOTSUP;

}

 

 

Von: Jukka Rissanen <jukka.rissanen@...>
Gesendet: Montag, 7. März 2022 09:57
An: Weiberg, Bernd (SMO RI R&D DF 1) <bernd.weiberg@...>; users@...
Betreff: Re: [Zephyr-users] Problems setting up ethernet mac address on STM32H753ZI

 

Hi Bernd,

 

when chaning the MAC from the application, you should use the net_mgmt API so that the Ethernet driver knows that the link address is changed.

See for example tests/net/ethernet_mgmt/src/main.c and test_change_mac_when_down() function how it is doing the change.

 

Cheers,

Jukka

 

 

On Fri, 2022-03-04 at 12:10 +0000, Weiberg, Bernd wrote:

Dear Users,

currently I have some trouble setting the ethernet MAC Address on an NUCLEO-H753ZI Board.

After setting the MAC address I got some strange behavior:

When I try to ping my notebook from the nucleo board using net ping <ip> I can see (with Wireshark) that the ping requests from the nucleo board are still be send with the old mac address as Source. The response from the notebook is then send back to the new mac address.

This behavior is the result of the following wrong arp request/response procedure (192.168.1.43 is my NUCLEO Board and 192.168.1.200 is my notebook):

1:   192.168.1.43         192.168.1.200        ICMP Echo (ping) request

2:   08:00:27:bc:26:03    ff:ff:ff:ff:ff:ff    Who has 192.168.1.43? Tell 192.168.1.200

3:   02:80:e1:2c:24:31    08:00:27:bc:26:03    192.168.1.43 is at 00:19:28:ab:cd:ef

 

After resolving the mac address of the notebook using ARP the NUCLEO send a ping request to the notebook (1).

The Notebook (08:00:27:bc:26:03) is asking the NUCLEO for its mac address (2).

The NUCLEO answers, with the correct mac address in the arp response (00:19:28:ab:cd:ef) but still uses the old one as source address (02:80:e1:2c:24:31).

 

I used the following code for changing the mac address:

/*

* Set mac address

******************************************************************************/

int set_mac(uint8_t *p_mac, uint8_t len)

{

     int result = 0;

     struct net_if *p_iface = net_if_get_default();

 

     // Check, if we have got a valid network interface

     if (p_iface == NULL) {

          LOG_WRN("No network interface defined");

          return -ENODEV;

     }

 

     // The API documentation for net_if_set_link_addr() says that the address

     // must be valid throughout interface lifetime, so we will copy it to our

     // local variable. But at first we will check the size.

     if (len != sizeof(mac)) {

          LOG_WRN("Invalid size for mac address %u (expected %u)",

                     len, sizeof(mac));

          return -EINVAL;

     }

     memcpy(mac, p_mac, sizeof(mac));

 

     // Before we can setup the mac address, we have to bring the interface down

     if (net_if_down(p_iface) != 0) {

          LOG_WRN("Failed to bring network interface down");

          return -EACCES;

 

     }

     // Try to change the mac address now

     if ((result = net_if_set_link_addr(p_iface, mac, sizeof(mac),

                NET_LINK_ETHERNET)) != 0)

     {

          LOG_WRN("Failed to setup mac address: %d", result);

          result = -EACCES;

     }

 

     // Bring the interface up again (even if we failed to setup the mac address)

     if (net_if_up(p_iface) != 0) {

          LOG_WRN("Failed to bring network interface up again");

          return -EACCES;

     }

     return result;

}

 

As pointed out by the API documentation is stored the mac address in a variable which is on the heap and

doesn’t change through the lifetime of the interface.

I also brought the interface down before changing the mac address.

 

Any Ideas?

 

Cheers.

 

 

 

 

 

 


Re: Problems setting up ethernet mac address on STM32H753ZI

Jukka Rissanen
 

Hi Bernd,

Indeed, the code should return the value of "ret" variable. Would you be able to send a PR that fixes the issue?


Cheers,
Jukka


On Tue, 2022-03-08 at 11:21 +0000, Weiberg, Bernd wrote:

Hi Jukka,

thanks for hat good advice!

I have tried to change the mac address using the net_mgmt API as it can be found in the example you suggested.

net_mgmt(NET_REQUEST_ETHERNET_SET_MAC_ADDRESS, ..) returns -ENOTSUP (134) in my case.

After some deeper investigations if found out, that there might be a bug in the underlaying driver eth_stm32_hal.c.

The Code of eth_stm32_hal_set_config() always returns -ENOTSUP even if everything is fine.

In my opinion the last return have to be changed from return -ENOTSUP to return ret;

How can I address this error?

See code below:

 

static int eth_stm32_hal_set_config(const struct device *dev,

                                                                   enum ethernet_config_type type,

                                                                   const struct ethernet_config *config)

{

                int ret = -ENOTSUP;

                struct eth_stm32_hal_dev_data *dev_data;

                ETH_HandleTypeDef *heth;

 

                dev_data = dev->data;

                heth = &dev_data->heth;

 

                switch (type) {

                case ETHERNET_CONFIG_TYPE_MAC_ADDRESS:

                               memcpy(dev_data->mac_addr, config->mac_address.addr, 6);

                               heth->Instance->MACA0HR = (dev_data->mac_addr[5] << 8) |

                                               dev_data->mac_addr[4];

                               heth->Instance->MACA0LR = (dev_data->mac_addr[3] << 24) |

                                               (dev_data->mac_addr[2] << 16) |

                                               (dev_data->mac_addr[1] << 8) |

                                               dev_data->mac_addr[0];

                               net_if_set_link_addr(dev_data->iface, dev_data->mac_addr,

                                                                    sizeof(dev_data->mac_addr),

                                                                    NET_LINK_ETHERNET);

                               ret = 0;

                               break;

                case ETHERNET_CONFIG_TYPE_PROMISC_MODE:

#if defined(CONFIG_NET_PROMISCUOUS_MODE)

#if defined(CONFIG_SOC_SERIES_STM32H7X)

                               if (config->promisc_mode) {

                                               heth->Instance->MACPFR |= ETH_MACPFR_PR;

                               } else {

                                               heth->Instance->MACPFR &= ~ETH_MACPFR_PR;

                               }

#else

                               if (config->promisc_mode) {

                                               heth->Instance->MACFFR |= ETH_MACFFR_PM;

                               } else {

                                               heth->Instance->MACFFR &= ~ETH_MACFFR_PM;

                               }

#endif  /* CONFIG_SOC_SERIES_STM32H7X */

                               ret = 0;

#endif /* CONFIG_NET_PROMISCUOUS_MODE */

                               break;

                default:

                               break;

                }

 

                return -ENOTSUP;

}

 

 

Von: Jukka Rissanen <jukka.rissanen@...>
Gesendet: Montag, 7. März 2022 09:57
An: Weiberg, Bernd (SMO RI R&D DF 1) <bernd.weiberg@...>; users@...
Betreff: Re: [Zephyr-users] Problems setting up ethernet mac address on STM32H753ZI

 

Hi Bernd,

 

when chaning the MAC from the application, you should use the net_mgmt API so that the Ethernet driver knows that the link address is changed.

See for example tests/net/ethernet_mgmt/src/main.c and test_change_mac_when_down() function how it is doing the change.

 

Cheers,

Jukka

 

 

On Fri, 2022-03-04 at 12:10 +0000, Weiberg, Bernd wrote:

Dear Users,

currently I have some trouble setting the ethernet MAC Address on an NUCLEO-H753ZI Board.

After setting the MAC address I got some strange behavior:

When I try to ping my notebook from the nucleo board using net ping <ip> I can see (with Wireshark) that the ping requests from the nucleo board are still be send with the old mac address as Source. The response from the notebook is then send back to the new mac address.

This behavior is the result of the following wrong arp request/response procedure (192.168.1.43 is my NUCLEO Board and 192.168.1.200 is my notebook):

1:   192.168.1.43         192.168.1.200        ICMP Echo (ping) request

2:   08:00:27:bc:26:03    ff:ff:ff:ff:ff:ff    Who has 192.168.1.43? Tell 192.168.1.200

3:   02:80:e1:2c:24:31    08:00:27:bc:26:03    192.168.1.43 is at 00:19:28:ab:cd:ef

 

After resolving the mac address of the notebook using ARP the NUCLEO send a ping request to the notebook (1).

The Notebook (08:00:27:bc:26:03) is asking the NUCLEO for its mac address (2).

The NUCLEO answers, with the correct mac address in the arp response (00:19:28:ab:cd:ef) but still uses the old one as source address (02:80:e1:2c:24:31).

 

I used the following code for changing the mac address:

/*

* Set mac address

******************************************************************************/

int set_mac(uint8_t *p_mac, uint8_t len)

{

     int result = 0;

     struct net_if *p_iface = net_if_get_default();

 

     // Check, if we have got a valid network interface

     if (p_iface == NULL) {

          LOG_WRN("No network interface defined");

          return -ENODEV;

     }

 

     // The API documentation for net_if_set_link_addr() says that the address

     // must be valid throughout interface lifetime, so we will copy it to our

     // local variable. But at first we will check the size.

     if (len != sizeof(mac)) {

          LOG_WRN("Invalid size for mac address %u (expected %u)",

                     len, sizeof(mac));

          return -EINVAL;

     }

     memcpy(mac, p_mac, sizeof(mac));

 

     // Before we can setup the mac address, we have to bring the interface down

     if (net_if_down(p_iface) != 0) {

          LOG_WRN("Failed to bring network interface down");

          return -EACCES;

 

     }

     // Try to change the mac address now

     if ((result = net_if_set_link_addr(p_iface, mac, sizeof(mac),

                NET_LINK_ETHERNET)) != 0)

     {

          LOG_WRN("Failed to setup mac address: %d", result);

          result = -EACCES;

     }

 

     // Bring the interface up again (even if we failed to setup the mac address)

     if (net_if_up(p_iface) != 0) {

          LOG_WRN("Failed to bring network interface up again");

          return -EACCES;

     }

     return result;

}

 

As pointed out by the API documentation is stored the mac address in a variable which is on the heap and

doesn’t change through the lifetime of the interface.

I also brought the interface down before changing the mac address.

 

Any Ideas?

 

Cheers.

 

 

 

 

 



Re: Problems setting up ethernet mac address on STM32H753ZI

Weiberg, Bernd
 

Hi Jukka,

thanks for hat good advice!

I have tried to change the mac address using the net_mgmt API as it can be found in the example you suggested.

net_mgmt(NET_REQUEST_ETHERNET_SET_MAC_ADDRESS, ..) returns -ENOTSUP (134) in my case.

After some deeper investigations if found out, that there might be a bug in the underlaying driver eth_stm32_hal.c.

The Code of eth_stm32_hal_set_config() always returns -ENOTSUP even if everything is fine.

In my opinion the last return have to be changed from return -ENOTSUP to return ret;

How can I address this error?

See code below:

 

static int eth_stm32_hal_set_config(const struct device *dev,

                                                                   enum ethernet_config_type type,

                                                                   const struct ethernet_config *config)

{

                int ret = -ENOTSUP;

                struct eth_stm32_hal_dev_data *dev_data;

                ETH_HandleTypeDef *heth;

 

                dev_data = dev->data;

                heth = &dev_data->heth;

 

                switch (type) {

                case ETHERNET_CONFIG_TYPE_MAC_ADDRESS:

                               memcpy(dev_data->mac_addr, config->mac_address.addr, 6);

                               heth->Instance->MACA0HR = (dev_data->mac_addr[5] << 8) |

                                               dev_data->mac_addr[4];

                               heth->Instance->MACA0LR = (dev_data->mac_addr[3] << 24) |

                                               (dev_data->mac_addr[2] << 16) |

                                               (dev_data->mac_addr[1] << 8) |

                                               dev_data->mac_addr[0];

                               net_if_set_link_addr(dev_data->iface, dev_data->mac_addr,

                                                                    sizeof(dev_data->mac_addr),

                                                                    NET_LINK_ETHERNET);

                               ret = 0;

                               break;

                case ETHERNET_CONFIG_TYPE_PROMISC_MODE:

#if defined(CONFIG_NET_PROMISCUOUS_MODE)

#if defined(CONFIG_SOC_SERIES_STM32H7X)

                               if (config->promisc_mode) {

                                               heth->Instance->MACPFR |= ETH_MACPFR_PR;

                               } else {

                                               heth->Instance->MACPFR &= ~ETH_MACPFR_PR;

                               }

#else

                               if (config->promisc_mode) {

                                               heth->Instance->MACFFR |= ETH_MACFFR_PM;

                               } else {

                                               heth->Instance->MACFFR &= ~ETH_MACFFR_PM;

                               }

#endif  /* CONFIG_SOC_SERIES_STM32H7X */

                               ret = 0;

#endif /* CONFIG_NET_PROMISCUOUS_MODE */

                               break;

                default:

                               break;

                }

 

                return -ENOTSUP;

}

 

 

Von: Jukka Rissanen <jukka.rissanen@...>
Gesendet: Montag, 7. März 2022 09:57
An: Weiberg, Bernd (SMO RI R&D DF 1) <bernd.weiberg@...>; users@...
Betreff: Re: [Zephyr-users] Problems setting up ethernet mac address on STM32H753ZI

 

Hi Bernd,

 

when chaning the MAC from the application, you should use the net_mgmt API so that the Ethernet driver knows that the link address is changed.

See for example tests/net/ethernet_mgmt/src/main.c and test_change_mac_when_down() function how it is doing the change.

 

Cheers,

Jukka

 

 

On Fri, 2022-03-04 at 12:10 +0000, Weiberg, Bernd wrote:

Dear Users,

currently I have some trouble setting the ethernet MAC Address on an NUCLEO-H753ZI Board.

After setting the MAC address I got some strange behavior:

When I try to ping my notebook from the nucleo board using net ping <ip> I can see (with Wireshark) that the ping requests from the nucleo board are still be send with the old mac address as Source. The response from the notebook is then send back to the new mac address.

This behavior is the result of the following wrong arp request/response procedure (192.168.1.43 is my NUCLEO Board and 192.168.1.200 is my notebook):

1:   192.168.1.43         192.168.1.200        ICMP Echo (ping) request

2:   08:00:27:bc:26:03    ff:ff:ff:ff:ff:ff    Who has 192.168.1.43? Tell 192.168.1.200

3:   02:80:e1:2c:24:31    08:00:27:bc:26:03    192.168.1.43 is at 00:19:28:ab:cd:ef

 

After resolving the mac address of the notebook using ARP the NUCLEO send a ping request to the notebook (1).

The Notebook (08:00:27:bc:26:03) is asking the NUCLEO for its mac address (2).

The NUCLEO answers, with the correct mac address in the arp response (00:19:28:ab:cd:ef) but still uses the old one as source address (02:80:e1:2c:24:31).

 

I used the following code for changing the mac address:

/*

* Set mac address

******************************************************************************/

int set_mac(uint8_t *p_mac, uint8_t len)

{

     int result = 0;

     struct net_if *p_iface = net_if_get_default();

 

     // Check, if we have got a valid network interface

     if (p_iface == NULL) {

          LOG_WRN("No network interface defined");

          return -ENODEV;

     }

 

     // The API documentation for net_if_set_link_addr() says that the address

     // must be valid throughout interface lifetime, so we will copy it to our

     // local variable. But at first we will check the size.

     if (len != sizeof(mac)) {

          LOG_WRN("Invalid size for mac address %u (expected %u)",

                     len, sizeof(mac));

          return -EINVAL;

     }

     memcpy(mac, p_mac, sizeof(mac));

 

     // Before we can setup the mac address, we have to bring the interface down

     if (net_if_down(p_iface) != 0) {

          LOG_WRN("Failed to bring network interface down");

          return -EACCES;

 

     }

     // Try to change the mac address now

     if ((result = net_if_set_link_addr(p_iface, mac, sizeof(mac),

                NET_LINK_ETHERNET)) != 0)

     {

          LOG_WRN("Failed to setup mac address: %d", result);

          result = -EACCES;

     }

 

     // Bring the interface up again (even if we failed to setup the mac address)

     if (net_if_up(p_iface) != 0) {

          LOG_WRN("Failed to bring network interface up again");

          return -EACCES;

     }

     return result;

}

 

As pointed out by the API documentation is stored the mac address in a variable which is on the heap and

doesn’t change through the lifetime of the interface.

I also brought the interface down before changing the mac address.

 

Any Ideas?

 

Cheers.

 

 

 

 

 


Re: Configure BLE Module on STEVAL-MKSBOX1V1

Erwan Gouriou
 

If you look at code under BT_SPI_BLUENRG, you'll see that it proposes some specific code that 
was required to add on top of bare hci_spi driver to get the module working.

I haven't add a look to other BlueNRG modules, but it's possible they require similar adaptation,
for this I suggest to have a check on modules documentation and see what is required to integrate
them with a bluetooth host over a HCI link.

Cheers
Erwan

On Tue, 1 Mar 2022 at 21:54, Daniele Bortoluzzi <danieleb88@...> wrote:
Hi Erwan,
thank you for the response.

We are using sensortile.box with SPBTLE-1S BLE v4.2 connectivity. In fact we are currently don't use BT_SPI_BLUENRG config.

What do you suggest us to integrate SPBTLE-1S? Is our .dts correct? Are there in zephyr other mcus supported that are using same connectivity?

Thank you.

Best regards

Daniele

Il mar 1 mar 2022, 09:56 Erwan Gouriou <erwan.gouriou@...> ha scritto:
Hello Daniele,

You're globally in the right direction, but please note that stm32l562_dk actually uses a SPBTLE-RFTR module, based on BlueNRG-MS (BLE v4.1).
SensorTile board use, depending on version:
- SPBTLE-1S Bluetooth Smart connectivity (BLE v4.2)
- BlueNRG-M2 (BLE v5.2)

These modules might differ from BlueNRG-MS on SPI API, likely not needing BT_SPI_BLUENRG,
or requiring an adaptation. Please refer to their respective manuals to see how to integrate them.

BR
Erwan

On Mon, 28 Feb 2022 at 13:23, Daniele Bortoluzzi <danieleb88@...> wrote:
Hi,
I'm Bortoluzzi Daniele, and I'm developing, for my master's thesis with University of Turin, a project using platformio and zephyr.

I would like to use the Ble Module (SPBTLE-1S) of the STEVAL-MKSBOX1V1 (SensorTile.box) in a zephyr project. This mcu is supported by zephyr, but the .dts file doesn't configure the spi2 interface used by bluetooth.

According with the hardware specs [1], I tried to start from ST BLE sensor project example [2] and configure:

prj.conf:

CONFIG_BT_SPI=y
CONFIG_BT_HCI=y
CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="SPBTLE-1S"
CONFIG_BT_GATT_CLIENT=y

app.overlay:

/ {
    chosen {
           zephyr,bt-hci-spi = &zephyr_bt_hci_spi;
           zephyr,bt-hci-spi-slave = &zephyr_bt_hci_spi_slave;
    };
};

&spi2 {
    pinctrl-0 = <&spi2_nss_pd0 &spi2_sck_pd1 &spi2_miso_pd3 &spi2_mosi_pc3>;
    pinctrl-names = "default";
    status = "okay";

    cs-gpios = <&gpiod 0 GPIO_ACTIVE_LOW>;

    zephyr_bt_hci_spi: zephyr_bt_hci_spi@0 {
        compatible = "zephyr,bt-hci-spi";
        reg = <0>;
        irq-gpios = <&gpiod 4 GPIO_ACTIVE_LOW>;
        reset-gpios = <&gpioa 8 GPIO_ACTIVE_LOW>;
        spi-max-frequency = <1000000>;
        label = "SPBTLE-1S";
    };

    zephyr_bt_hci_spi_slave: zephyr_bt_hci_spi_slave@1 {
        compatible = "zephyr,bt-hci-spi-slave";
        reg = <1>;
        irq-gpios = <&gpiod 4 GPIO_ACTIVE_LOW>;
    };
};

Unfortunately, bluetooth isn't enabled correctly and the system hangs up:
in the main.c, the bt_enable waits endlessly, because the function bt_spi_rx_thread of the file https://github.com/zephyrproject-rtos/zephyr/blob/v2.7-branch/drivers/bluetooth/hci/spi.c (line 343) doesn't return, looping in the do-while.

Thank you very much for your support.


Re: Problems setting up ethernet mac address on STM32H753ZI

Jukka Rissanen
 

Hi Bernd,

when chaning the MAC from the application, you should use the net_mgmt API so that the Ethernet driver knows that the link address is changed.
See for example tests/net/ethernet_mgmt/src/main.c and test_change_mac_when_down() function how it is doing the change.

Cheers,
Jukka


On Fri, 2022-03-04 at 12:10 +0000, Weiberg, Bernd wrote:

Dear Users,

currently I have some trouble setting the ethernet MAC Address on an NUCLEO-H753ZI Board.

After setting the MAC address I got some strange behavior:

When I try to ping my notebook from the nucleo board using net ping <ip> I can see (with Wireshark) that the ping requests from the nucleo board are still be send with the old mac address as Source. The response from the notebook is then send back to the new mac address.

This behavior is the result of the following wrong arp request/response procedure (192.168.1.43 is my NUCLEO Board and 192.168.1.200 is my notebook):

1:   192.168.1.43         192.168.1.200        ICMP Echo (ping) request

2:   08:00:27:bc:26:03    ff:ff:ff:ff:ff:ff    Who has 192.168.1.43? Tell 192.168.1.200

3:   02:80:e1:2c:24:31    08:00:27:bc:26:03    192.168.1.43 is at 00:19:28:ab:cd:ef

 

After resolving the mac address of the notebook using ARP the NUCLEO send a ping request to the notebook (1).

The Notebook (08:00:27:bc:26:03) is asking the NUCLEO for its mac address (2).

The NUCLEO answers, with the correct mac address in the arp response (00:19:28:ab:cd:ef) but still uses the old one as source address (02:80:e1:2c:24:31).

 

I used the following code for changing the mac address:

/*

* Set mac address

******************************************************************************/

int set_mac(uint8_t *p_mac, uint8_t len)

{

     int result = 0;

     struct net_if *p_iface = net_if_get_default();

 

     // Check, if we have got a valid network interface

     if (p_iface == NULL) {

          LOG_WRN("No network interface defined");

          return -ENODEV;

     }

 

     // The API documentation for net_if_set_link_addr() says that the address

     // must be valid throughout interface lifetime, so we will copy it to our

     // local variable. But at first we will check the size.

     if (len != sizeof(mac)) {

          LOG_WRN("Invalid size for mac address %u (expected %u)",

                     len, sizeof(mac));

          return -EINVAL;

     }

     memcpy(mac, p_mac, sizeof(mac));

 

     // Before we can setup the mac address, we have to bring the interface down

     if (net_if_down(p_iface) != 0) {

          LOG_WRN("Failed to bring network interface down");

          return -EACCES;

 

     }

     // Try to change the mac address now

     if ((result = net_if_set_link_addr(p_iface, mac, sizeof(mac),

                NET_LINK_ETHERNET)) != 0)

     {

          LOG_WRN("Failed to setup mac address: %d", result);

          result = -EACCES;

     }

 

     // Bring the interface up again (even if we failed to setup the mac address)

     if (net_if_up(p_iface) != 0) {

          LOG_WRN("Failed to bring network interface up again");

          return -EACCES;

     }

     return result;

}

 

As pointed out by the API documentation is stored the mac address in a variable which is on the heap and

doesn’t change through the lifetime of the interface.

I also brought the interface down before changing the mac address.

 

Any Ideas?

 

Cheers.

 

 

 

 



Re: Global scheduler suspend

Rob Meades
 

Never mind: my motivation was to find a scheduler-suspension mechanism that works in the same way between Zephyr and FreeRTOS (since our code runs on both), and I thought the two were different but actually I think it ends up amounting to the same thing - FreeRTOS asserts if a suspended task does something to become unready (e.g. try to lock a mutex or send a message), rather than just rescheduling as Zephyr does, but all I need from this mechanism is to prevent RTOS-tick rescheduling and that is the same in both cases. I can fix it in the definition of the function.

Sorry for bothering!

Rob

-----Original Message-----
From: users@... [mailto:users@...] On Behalf Of Rob Meades via lists.zephyrproject.org
Sent: 05 March 2022 20:44
To: users@...
Subject: [Zephyr-users] Global scheduler suspend

*** This is an EXTERNAL email. It was sent from outside of u-blox. ***

Apologies if I've missed this in the documentation but I'm looking for a way to suspend the Zephyr scheduler so that my task is not descheduled under any circumstances (until I re-enable the scheduler); I not been unable to find anything that does this so far.

I have found k_sched_lock() but that still deschedules the task should it do something that makes it unready. I've also found irq_lock() but again that is thread-specific so if the current thread is descheduled I'm back to where I started from.

Is there an organised way to good 'ole global scheduler suspend?

Rob


Global scheduler suspend

Rob Meades
 

Apologies if I've missed this in the documentation but I'm looking for a way to suspend the Zephyr scheduler so that my task is not descheduled under any circumstances (until I re-enable the scheduler); I not been unable to find anything that does this so far.

I have found k_sched_lock() but that still deschedules the task should it do something that makes it unready. I've also found irq_lock() but again that is thread-specific so if the current thread is descheduled I'm back to where I started from.

Is there an organised way to good 'ole global scheduler suspend?

Rob


Zephyr SDK 0.14.0-beta1 Release

Stephanos Ioannidis
 

Hi,

 

Zephyr SDK 0.14.0-beta1 has been released.

 

https://github.com/zephyrproject-rtos/sdk-ng/releases/tag/v0.14.0-beta1

 

This is the first Zephyr SDK release to support all three major host operating systems:

 

  • Linux (AArch64, x86-64)
  • macOS (AArch64, x86-64)
  • Windows (x86-64)

 

Please refer to the following preliminary “Getting Started Guide” for the instructions on how to

install and use the multi-platform Zephyr SDK:

 

https://stephanosio.github.io/zephyr-mpsdk-doc-test/getting_started/index.html#install-a-toolchain

 

Please try it out and report if you find any issues.

 

Thanks,

 

Stephanos


Problems setting up ethernet mac address on STM32H753ZI

Weiberg, Bernd
 

Dear Users,

currently I have some trouble setting the ethernet MAC Address on an NUCLEO-H753ZI Board.

After setting the MAC address I got some strange behavior:

When I try to ping my notebook from the nucleo board using net ping <ip> I can see (with Wireshark) that the ping requests from the nucleo board are still be send with the old mac address as Source. The response from the notebook is then send back to the new mac address.

This behavior is the result of the following wrong arp request/response procedure (192.168.1.43 is my NUCLEO Board and 192.168.1.200 is my notebook):

1:   192.168.1.43         192.168.1.200        ICMP Echo (ping) request

2:   08:00:27:bc:26:03    ff:ff:ff:ff:ff:ff    Who has 192.168.1.43? Tell 192.168.1.200

3:   02:80:e1:2c:24:31    08:00:27:bc:26:03    192.168.1.43 is at 00:19:28:ab:cd:ef

 

After resolving the mac address of the notebook using ARP the NUCLEO send a ping request to the notebook (1).

The Notebook (08:00:27:bc:26:03) is asking the NUCLEO for its mac address (2).

The NUCLEO answers, with the correct mac address in the arp response (00:19:28:ab:cd:ef) but still uses the old one as source address (02:80:e1:2c:24:31).

 

I used the following code for changing the mac address:

/*

* Set mac address

******************************************************************************/

int set_mac(uint8_t *p_mac, uint8_t len)

{

     int result = 0;

     struct net_if *p_iface = net_if_get_default();

 

     // Check, if we have got a valid network interface

     if (p_iface == NULL) {

          LOG_WRN("No network interface defined");

          return -ENODEV;

     }

 

     // The API documentation for net_if_set_link_addr() says that the address

     // must be valid throughout interface lifetime, so we will copy it to our

     // local variable. But at first we will check the size.

     if (len != sizeof(mac)) {

          LOG_WRN("Invalid size for mac address %u (expected %u)",

                     len, sizeof(mac));

          return -EINVAL;

     }

     memcpy(mac, p_mac, sizeof(mac));

 

     // Before we can setup the mac address, we have to bring the interface down

     if (net_if_down(p_iface) != 0) {

          LOG_WRN("Failed to bring network interface down");

          return -EACCES;

 

     }

     // Try to change the mac address now

     if ((result = net_if_set_link_addr(p_iface, mac, sizeof(mac),

                NET_LINK_ETHERNET)) != 0)

     {

          LOG_WRN("Failed to setup mac address: %d", result);

          result = -EACCES;

     }

 

     // Bring the interface up again (even if we failed to setup the mac address)

     if (net_if_up(p_iface) != 0) {

          LOG_WRN("Failed to bring network interface up again");

          return -EACCES;

     }

     return result;

}

 

As pointed out by the API documentation is stored the mac address in a variable which is on the heap and

doesn’t change through the lifetime of the interface.

I also brought the interface down before changing the mac address.

 

Any Ideas?

 

Cheers.

 

 

 

 


Re: Configure BLE Module on STEVAL-MKSBOX1V1

Daniele Bortoluzzi <danieleb88@...>
 

Hi Erwan,
thank you for the response.

We are using sensortile.box with SPBTLE-1S BLE v4.2 connectivity. In fact we are currently don't use BT_SPI_BLUENRG config.

What do you suggest us to integrate SPBTLE-1S? Is our .dts correct? Are there in zephyr other mcus supported that are using same connectivity?

Thank you.

Best regards

Daniele


Il mar 1 mar 2022, 09:56 Erwan Gouriou <erwan.gouriou@...> ha scritto:
Hello Daniele,

You're globally in the right direction, but please note that stm32l562_dk actually uses a SPBTLE-RFTR module, based on BlueNRG-MS (BLE v4.1).
SensorTile board use, depending on version:
- SPBTLE-1S Bluetooth Smart connectivity (BLE v4.2)
- BlueNRG-M2 (BLE v5.2)

These modules might differ from BlueNRG-MS on SPI API, likely not needing BT_SPI_BLUENRG,
or requiring an adaptation. Please refer to their respective manuals to see how to integrate them.

BR
Erwan

On Mon, 28 Feb 2022 at 13:23, Daniele Bortoluzzi <danieleb88@...> wrote:
Hi,
I'm Bortoluzzi Daniele, and I'm developing, for my master's thesis with University of Turin, a project using platformio and zephyr.

I would like to use the Ble Module (SPBTLE-1S) of the STEVAL-MKSBOX1V1 (SensorTile.box) in a zephyr project. This mcu is supported by zephyr, but the .dts file doesn't configure the spi2 interface used by bluetooth.

According with the hardware specs [1], I tried to start from ST BLE sensor project example [2] and configure:

prj.conf:

CONFIG_BT_SPI=y
CONFIG_BT_HCI=y
CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="SPBTLE-1S"
CONFIG_BT_GATT_CLIENT=y

app.overlay:

/ {
    chosen {
           zephyr,bt-hci-spi = &zephyr_bt_hci_spi;
           zephyr,bt-hci-spi-slave = &zephyr_bt_hci_spi_slave;
    };
};

&spi2 {
    pinctrl-0 = <&spi2_nss_pd0 &spi2_sck_pd1 &spi2_miso_pd3 &spi2_mosi_pc3>;
    pinctrl-names = "default";
    status = "okay";

    cs-gpios = <&gpiod 0 GPIO_ACTIVE_LOW>;

    zephyr_bt_hci_spi: zephyr_bt_hci_spi@0 {
        compatible = "zephyr,bt-hci-spi";
        reg = <0>;
        irq-gpios = <&gpiod 4 GPIO_ACTIVE_LOW>;
        reset-gpios = <&gpioa 8 GPIO_ACTIVE_LOW>;
        spi-max-frequency = <1000000>;
        label = "SPBTLE-1S";
    };

    zephyr_bt_hci_spi_slave: zephyr_bt_hci_spi_slave@1 {
        compatible = "zephyr,bt-hci-spi-slave";
        reg = <1>;
        irq-gpios = <&gpiod 4 GPIO_ACTIVE_LOW>;
    };
};

Unfortunately, bluetooth isn't enabled correctly and the system hangs up:
in the main.c, the bt_enable waits endlessly, because the function bt_spi_rx_thread of the file https://github.com/zephyrproject-rtos/zephyr/blob/v2.7-branch/drivers/bluetooth/hci/spi.c (line 343) doesn't return, looping in the do-while.

Thank you very much for your support.


Re: Configure BLE Module on STEVAL-MKSBOX1V1

Erwan Gouriou
 

Hello Daniele,

You're globally in the right direction, but please note that stm32l562_dk actually uses a SPBTLE-RFTR module, based on BlueNRG-MS (BLE v4.1).
SensorTile board use, depending on version:
- SPBTLE-1S Bluetooth Smart connectivity (BLE v4.2)
- BlueNRG-M2 (BLE v5.2)

These modules might differ from BlueNRG-MS on SPI API, likely not needing BT_SPI_BLUENRG,
or requiring an adaptation. Please refer to their respective manuals to see how to integrate them.

BR
Erwan

On Mon, 28 Feb 2022 at 13:23, Daniele Bortoluzzi <danieleb88@...> wrote:
Hi,
I'm Bortoluzzi Daniele, and I'm developing, for my master's thesis with University of Turin, a project using platformio and zephyr.

I would like to use the Ble Module (SPBTLE-1S) of the STEVAL-MKSBOX1V1 (SensorTile.box) in a zephyr project. This mcu is supported by zephyr, but the .dts file doesn't configure the spi2 interface used by bluetooth.

According with the hardware specs [1], I tried to start from ST BLE sensor project example [2] and configure:

prj.conf:

CONFIG_BT_SPI=y
CONFIG_BT_HCI=y
CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="SPBTLE-1S"
CONFIG_BT_GATT_CLIENT=y

app.overlay:

/ {
    chosen {
           zephyr,bt-hci-spi = &zephyr_bt_hci_spi;
           zephyr,bt-hci-spi-slave = &zephyr_bt_hci_spi_slave;
    };
};

&spi2 {
    pinctrl-0 = <&spi2_nss_pd0 &spi2_sck_pd1 &spi2_miso_pd3 &spi2_mosi_pc3>;
    pinctrl-names = "default";
    status = "okay";

    cs-gpios = <&gpiod 0 GPIO_ACTIVE_LOW>;

    zephyr_bt_hci_spi: zephyr_bt_hci_spi@0 {
        compatible = "zephyr,bt-hci-spi";
        reg = <0>;
        irq-gpios = <&gpiod 4 GPIO_ACTIVE_LOW>;
        reset-gpios = <&gpioa 8 GPIO_ACTIVE_LOW>;
        spi-max-frequency = <1000000>;
        label = "SPBTLE-1S";
    };

    zephyr_bt_hci_spi_slave: zephyr_bt_hci_spi_slave@1 {
        compatible = "zephyr,bt-hci-spi-slave";
        reg = <1>;
        irq-gpios = <&gpiod 4 GPIO_ACTIVE_LOW>;
    };
};

Unfortunately, bluetooth isn't enabled correctly and the system hangs up:
in the main.c, the bt_enable waits endlessly, because the function bt_spi_rx_thread of the file https://github.com/zephyrproject-rtos/zephyr/blob/v2.7-branch/drivers/bluetooth/hci/spi.c (line 343) doesn't return, looping in the do-while.

Thank you very much for your support.

221 - 240 of 3111