Date   

CPP support

Guy Morand
 

Hi Zephyr users!

I'm new to Zephyr and was asked to write a small "study" project in c++. I didn't find much in the documentation about c++, except one sample and the following page:
https://docs.zephyrproject.org/latest/reference/kernel/other/cxx_support.html


I'm using the Zephyr SDK 0.13.2 and I started with:

```
#include <memory>

void main(void) {
std::unique_ptr<int> intValue = std::make_unique<int>(1234);

while(1) {
;
}
}
```

My prj.conf contains:

```
CONFIG_CPLUSPLUS=y
CONFIG_STD_CPP20=y
```

Unfortunately, it doesn't build although I can find the <memory> header file in the SDK:

```
main.cpp:6:10: fatal error: memory: No such file or directory
6 | #include <memory>
| ^~~~~~~~
```

* Am I missing something?
* Is the current cpp status is very limited and should avoid standard
library? (what would makes sense :D)

Kind regards,

Guy


Using mcuboot with STM32H7

Per-Erik Klarenfjord
 

In our project we are using the microcontroller STM32H753. We are trying to use mcuboot with the sample smp_svr (overlay-udp.conf) for software updates over Ethernet. This has been working good for the F767 microcontroller, but we are failing when using the H753 microcontroller.

 

From what I’ve read on git-hub I’m not sure if mcuboot right now is compatible with the STM32H7-series due to changes in the flash (dual banks and new byte alignment). Am I right or do you know any walk arounds for using STM32H7-series with mcuboot?

 

I’ve done the following steps when trying to use mcuboot with ”smp_svr”:

 

  1. Build and flash mcuboot. The board boots and everything seems good.

 

  1. Build, sign and flash the sample ”smp_svr” to flash partition slot 0. For the signing procedure to work I hade to add the argument ”align 8” when signing (default was ”align 32”), see below. Mcuboot and smp_svr boots and everything seems good.

> west sign -t imgtool -- --align 8 --key ~/zephyrproject/bootloader/mcuboot/root-rsa-2048.pem

 

  1. Upload a second image to flash partition slot 1, usign mcumgr as the tool for uploading. No errors.

>./mcumgr --conntype udp --connstring=[192.168.2.25]:1337 image upload ~/zephyrproject/zephyr/build/zephyr/zephyr.signed.bin

 

  1. List the images. Both images appear as intended.

>./mcumgr --conntype udp --connstring=[192.168.2.25]:1337 image list

 

Images:

image=0 slot=0

    version: 0.0.0

    bootable: true

    flags: active confirmed

    hash: 5bc6846f35e3f01fcb8351b1e3138ecf9f24039776e3b154095ec695e12d9e79

image=0 slot=1

    version: 0.0.0

    bootable: true

    flags:

    hash: 1b3543e439b29e03ac380f46f87e907fec45cc6aff1cd3b75c75ff570c85f174

Split status: N/A (0)

 

  1. Test the image with the hash code. It fails.

>./mcumgr --conntype udp --connstring=[192.168.2.25]:1337 image test 1b3543e439b29e03ac380f46f87e907fec45cc6aff1cd3b75c75ff570c85f174

 

Error: 1

 

The following is printed on the UART debug port:

[00:01:36.416,000] <err> flash_stm32h7: Write offset not aligned on flashword length. Offset: 0xbfff0, 2

[00:01:36.416,000] <err> flash_stm32h7: Write range invalid. Offset: 786416, len: 16 

 

 

Do you know how to solve this alignment error when using mcuboot with the STM32H7-series of microcontrollers?

 

Regards, Per-Erik


Re: Enabling Exceptions in C++ Build #CPP #CPP_Exceptions

Dave Nadler
 

Thanks Stephanos, it is great to hear that C++ exception thread-safety in Zephyr will be fixed.
Do you have an expected date for this?
Thanks again,
Best Regards, Dave

On 12/9/2021 7:57 PM, Stephanos Ioannidis wrote:

Hi,

 

While the newlib itself is thread-safe, libgcc and libstdc++ (and therefore C++ exceptions) are not.

 

We currently build the GCC with --enable-threads=no (i.e. single thread model), so we are using the libgcc gthr-single.h with dummy lock implementations.

 

In the future, this issue will be addressed by providing Zephyr-specific gthread implementation in the libgcc (gthr-zephyr.h) and building GCC with --enable-threads=zephyr.

 

For more details, refer to the Zephyr SDK issue #350.

 

Regards,

Stephanos

 

-- 
Dave Nadler, USA East Coast voice (978) 263-0097, drn@..., Skype 
 Dave.Nadler1


Re: Enabling Exceptions in C++ Build #CPP #CPP_Exceptions

Stephanos Ioannidis
 

Hi,

 

While the newlib itself is thread-safe, libgcc and libstdc++ (and therefore C++ exceptions) are not.

 

We currently build the GCC with --enable-threads=no (i.e. single thread model), so we are using the libgcc gthr-single.h with dummy lock implementations.

 

In the future, this issue will be addressed by providing Zephyr-specific gthread implementation in the libgcc (gthr-zephyr.h) and building GCC with --enable-threads=zephyr.

 

For more details, refer to the Zephyr SDK issue #350.

 

Regards,

 

Stephanos

 


Re: Enabling Exceptions in C++ Build #CPP #CPP_Exceptions

Dave Nadler
 

Are exceptions thread-safe under Zephyr with newlib?
mbarret, what is the COMPLETE list of menuconfig options you used to enable C++, and which compiler are you using?

Here's why I'm asking (specifically, GCC toolchain)...
Not thread-safe: C++ Exception Processing Crashes in GNU Arm Embedded Toolchain
Depending on how toolchain is built, appropriate mutex support may not be included...

Interested to hear what Zephyr users are doing here...
Hope that helps,
Best Regards, Dave

On 12/9/2021 8:32 AM, mbarrett@... wrote:
We figured out the issue. There are some other config dependencies that I was unaware of but
fiddling in menuconfig helped make it clear. These also need set (along with CONFIG_CPLUSPLUS obviously).
CONFIG_NEWLIB_LIBC=y
CONFIG_LIB_CPLUSPLUS=y
View/Reply Online (#2822)

On 12/9/2021 2:48 AM, artur.lipowski via lists.zephyrproject.org wrote:
What SDK/toolchain and platform do you use?

BTW> Build with C++ exceptions is a part of Zephyr CI (1 test),
so for many platforms (including mine) C++ exceptions work well.
View/Reply Online (#2820) 


-- 
Dave Nadler, USA East Coast voice (978) 263-0097, drn@..., Skype 
 Dave.Nadler1


Re: C++ support with debug optimiations #debugging

mbarrett@...
 

We figured out the issue. There are some other config dependencies that I was unaware of but fiddling in menuconfig helped make it clear. These also need set (along with CONFIG_CPLUSPLUS obviously).
CONFIG_NEWLIB_LIBC=y
CONFIG_LIB_CPLUSPLUS=y
 


Re: out of tree arch build? #customboard

Carles Cufi
 

Hi there,

 

Right now, no. archs (unlike SoCs or boards) are expected to be in-tree. If you cannot upstream your arch you will likely need to keep a fork of Zephyr patched.

 

Carles

 

From: users@... <users@...> On Behalf Of canyon_lake via lists.zephyrproject.org
Sent: 09 December 2021 05:59
To: users@...
Subject: [Zephyr-users] out of tree arch build? #customboard

 

Hi,

is there a way to support out of tree arch build like SOC or board?

Any advise is appreciated.

Sheng


Re: Enabling Exceptions in C++ Build #CPP #CPP_Exceptions

artur.lipowski@...
 

What SDK/toolchain and platform do you use?

BTW> Build with C++ exceptions is a part of Zephyr CI (1 test), so for many platforms (including mine) C++ exceptions work well.


out of tree arch build? #customboard

canyon_lake@...
 

Hi,

is there a way to support out of tree arch build like SOC or board?

Any advise is appreciated.

Sheng


Enabling Exceptions in C++ Build #CPP #CPP_Exceptions

apion@...
 

I am trying to get my code to build with C++ exceptions enabled.  Here are my configurations:

CONFIG_CPLUSPLUS=y
CONFIG_NEWLIB_LIBC=y
CONFIG_LIB_CPLUSPLUS=y
CONFIG_MINIMAL_LIBC=n
CONFIG_NEWLIB_LIBC_NANO=n
CONFIG_EXCEPTIONS=y

The build fails in the linker stage with an undefined reference to "_fini". 
Does anyone know why this is happening?
(The code builds fine if I don't try to use exceptions)


Re: gsm_modem sample changed in Zephyr 2.7 #ppp

Brenton Chetty
 

Thank you guys for your help.

I can't believe, I didn't think of removing that line. I think I need to take my work leave earlier lol.
And yes, Next time I will include more information about potential errors.

With much appreciation
Brenton


On Wed, Dec 8, 2021 at 4:54 PM William Fish <William.fish@...> wrote:
Looked at the file structure to check: "fatal error: drivers/gsm_ppp.h: No such file or directory". Not so surprisingly the header file is not in the drivers folder it is in the drivers/modem folder, appears something has gone wrong with our testing.

The offending code is in \samples\net\gsm_modem\src\main.c: line 14 
#include <drivers/gsm_ppp.h>

It should be removed and that should fix it, give it a try and please raise an issue in the Zephyr Git.

In the future could show more of the error; i.e. which file & line the include statement is? This really helps find the issue.

Thanks,

Billy..


Re: Clocks reset to start-up config after exiting STOP mode #stm32 #pm

Marijn Stam <marijnstam@...>
 

Hello,

 

I would like to follow this up by letting you know this issue has been fixed.

 

This issue has been solved by calling LL_LPM_EnableSleep() function in the STOP mode exit routine. This function clears the SLEEPDEEP bit in the SCB register.

I suppose what happened, is that the SLEEPDEEP bit was still set, and whenever the Idle thread triggered another __WFI() after having exited STOP mode, it would re-enter stopmode without being properly configured.

Van: Marijn Stam
Verzonden: Tuesday, 7 December 2021 16:11
Aan: users@...
Onderwerp: Clocks reset to start-up config after exiting STOP mode #STM32 #PM

 

Hello,

 

I'm using the Zephyr RTOS on a STM32F091 and have recently started working on implementing some low-power states (sleep and STOP). The system is fed by the PLL (48MHz) which is in turn fed by a HSE (20MHz).

I'm using the RTC peripheral to manage wake-ups, I simply set ALARMA at ~500ms before going to sleep.

 

What I see after waking up from STOP mode, is a bunch of garbage characters on the UART output and the whole system seemed to have slowed down significantly. A blinking LED for example, is now blinking much slower.

 

This is the code I use to enter the STOP mode (in functions pm_power_state_set and pm_power_state_exit_post_ops):

Note that this is not a Zephyr power driver, since the F091 was not supported yet. It is, however, heavily influenced by the other available power driver for STM32 platform (G0/L0 for example)

  1. //Switch to HSI clock before entering stop mode, needed so we can turn HSE off before entering (page 87 of RM)
  2. /* Enable HSI if not enabled */
  3. if (LL_RCC_HSI_IsReady() != 1) {
  4. /* Enable HSI */
  5. LL_RCC_HSI_Enable();
  6. while (LL_RCC_HSI_IsReady() != 1) {
  7. /* Wait for HSI ready */
  8. }
  9. }
  10.  
  11. /* Set HSI as SYSCLCK source */
  12. LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_HSI);
  13. while (LL_RCC_GetSysClkSource() != LL_RCC_SYS_CLKSOURCE_STATUS_HSI) {
  14. }
  15. //Disable the HSE now that the HSI is enabled
  16. LL_RCC_HSE_Disable();
  17.  
  18. LL_RCC_PLL_Disable();
  19.  
  20. LL_PWR_SetPowerMode(LL_PWR_MODE_STOP_MAINREGU);
  21. LL_LPM_EnableDeepSleep();
  22.  
  23. //Disable SysTick interrupts so we don't immediately wake up
  24. LL_SYSTICK_DisableIT();
  25.  
  26. //This calls __WFI();
  27. k_cpu_idle();

Then this is called whenever the STOP mode is exited:

  1. LL_LPM_DisableSleepOnExit();
  2.  
  3. //Restore clock configuration
  4. stm32_clock_control_init(NULL);
  5.  
  6. //Re-enable the systick interrupt
  7. LL_SYSTICK_EnableIT();
  8.  
  9. irq_unlock(0);

The stm32_clock_control_init(NULL) does the following in sequence:

  • Configure some init struct for peripheral clock configuration
  • Enable default clocks (only SYSCFG peripheral clock in this case)
  • Clock is switched to HSI
  • PLL is disabled
  • Configure and switch to PLL with HSE as source clock
  • Disable HSI and MSI

To verify, I routed the SYSCLK to MCO, so I can monitor it on a scope. It shows the correct clock speed of 48MHz before entering the low-power procedure, then it is 8MHz after exiting STOP mode (HSI is startup clock).

After the stm32_clock_control_init(NULL) function has been executed, the SYSCLK is back at 48MHz, and the RCC registers show the right configuration.

Then, very shortly after, the RCC configuration is reset back to exit STOP conditions, i.e. HSI on, HSE and PLL off, HSI as system clock, back at 8MHz. This seems to happen asynchronously and I can't pinpoint why it happens.

This does not happen when I enter/exit sleep mode, only STOP.

I've verified that the Clock Security System is off. 

Any help with this would be greatly appreciated, as I am grasping at straws at this point.

 

Thank you kindly,

 

Marijn Stam

 

 


Re: gsm_modem sample changed in Zephyr 2.7 #ppp

William Fish
 

Looked at the file structure to check: "fatal error: drivers/gsm_ppp.h: No such file or directory". Not so surprisingly the header file is not in the drivers folder it is in the drivers/modem folder, appears something has gone wrong with our testing.

The offending code is in \samples\net\gsm_modem\src\main.c: line 14 
#include <drivers/gsm_ppp.h>

It should be removed and that should fix it, give it a try and please raise an issue in the Zephyr Git.

In the future could show more of the error; i.e. which file & line the include statement is? This really helps find the issue.

Thanks,

Billy..


Re: gsm_modem sample changed in Zephyr 2.7 #ppp

Jukka Rissanen
 

Hi Brenton,



Cheers,
Jukka


On Wed, 2021-12-08 at 15:04 +0200, Brenton Chetty wrote:
Hi. I did try removing my build folder and using the pristine build, both did not help unfortunately. I am also using a clean install of Ubuntu and Zephyr, so the sample should have worked out of the box. I am totally baffled by this issue.

Regards
Brenton

On Wed, Dec 8, 2021 at 11:45 AM William Fish <William.fish@...> wrote:
You may just need to just do a "pristine" build or delete the build folder as the file was moved a while ago to conform with coding standards.

Billy..



Re: gsm_modem sample changed in Zephyr 2.7 #ppp

Brenton Chetty
 

Hi. I did try removing my build folder and using the pristine build, both did not help unfortunately. I am also using a clean install of Ubuntu and Zephyr, so the sample should have worked out of the box. I am totally baffled by this issue.

Regards
Brenton


On Wed, Dec 8, 2021 at 11:45 AM William Fish <William.fish@...> wrote:
You may just need to just do a "pristine" build or delete the build folder as the file was moved a while ago to conform with coding standards.

Billy..


Re: gsm_modem sample changed in Zephyr 2.7 #ppp

William Fish
 

You may just need to just do a "pristine" build or delete the build folder as the file was moved a while ago to conform with coding standards.

Billy..


C++ support with debug optimiations #debugging

mbarrett@...
 

Hi All,

We're trying to turn on debug optimizations, with C++ support. We have the following settings in our prj.conf:
CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_NO_OPTIMIZATIONS=y

but this leads to an undefined reference to vtable. Anyone have any ideas why this might be, and if there's a way to resolve it?

Thanks,
Marshal


Clocks reset to start-up config after exiting STOP mode #stm32 #pm

Marijn Stam <marijnstam@...>
 

Hello,

 

I'm using the Zephyr RTOS on a STM32F091 and have recently started working on implementing some low-power states (sleep and STOP). The system is fed by the PLL (48MHz) which is in turn fed by a HSE (20MHz).

I'm using the RTC peripheral to manage wake-ups, I simply set ALARMA at ~500ms before going to sleep.

 

What I see after waking up from STOP mode, is a bunch of garbage characters on the UART output and the whole system seemed to have slowed down significantly. A blinking LED for example, is now blinking much slower.

 

This is the code I use to enter the STOP mode (in functions pm_power_state_set and pm_power_state_exit_post_ops):

Note that this is not a Zephyr power driver, since the F091 was not supported yet. It is, however, heavily influenced by the other available power driver for STM32 platform (G0/L0 for example)

  1. //Switch to HSI clock before entering stop mode, needed so we can turn HSE off before entering (page 87 of RM)
  2. /* Enable HSI if not enabled */
  3. if (LL_RCC_HSI_IsReady() != 1) {
  4. /* Enable HSI */
  5. LL_RCC_HSI_Enable();
  6. while (LL_RCC_HSI_IsReady() != 1) {
  7. /* Wait for HSI ready */
  8. }
  9. }
  10.  
  11. /* Set HSI as SYSCLCK source */
  12. LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_HSI);
  13. while (LL_RCC_GetSysClkSource() != LL_RCC_SYS_CLKSOURCE_STATUS_HSI) {
  14. }
  15. //Disable the HSE now that the HSI is enabled
  16. LL_RCC_HSE_Disable();
  17.  
  18. LL_RCC_PLL_Disable();
  19.  
  20. LL_PWR_SetPowerMode(LL_PWR_MODE_STOP_MAINREGU);
  21. LL_LPM_EnableDeepSleep();
  22.  
  23. //Disable SysTick interrupts so we don't immediately wake up
  24. LL_SYSTICK_DisableIT();
  25.  
  26. //This calls __WFI();
  27. k_cpu_idle();

Then this is called whenever the STOP mode is exited:

  1. LL_LPM_DisableSleepOnExit();
  2.  
  3. //Restore clock configuration
  4. stm32_clock_control_init(NULL);
  5.  
  6. //Re-enable the systick interrupt
  7. LL_SYSTICK_EnableIT();
  8.  
  9. irq_unlock(0);

The stm32_clock_control_init(NULL) does the following in sequence:

  • Configure some init struct for peripheral clock configuration
  • Enable default clocks (only SYSCFG peripheral clock in this case)
  • Clock is switched to HSI
  • PLL is disabled
  • Configure and switch to PLL with HSE as source clock
  • Disable HSI and MSI

To verify, I routed the SYSCLK to MCO, so I can monitor it on a scope. It shows the correct clock speed of 48MHz before entering the low-power procedure, then it is 8MHz after exiting STOP mode (HSI is startup clock).

After the stm32_clock_control_init(NULL) function has been executed, the SYSCLK is back at 48MHz, and the RCC registers show the right configuration.

Then, very shortly after, the RCC configuration is reset back to exit STOP conditions, i.e. HSI on, HSE and PLL off, HSI as system clock, back at 8MHz. This seems to happen asynchronously and I can't pinpoint why it happens.

This does not happen when I enter/exit sleep mode, only STOP.

I've verified that the Clock Security System is off. 

Any help with this would be greatly appreciated, as I am grasping at straws at this point.

 

Thank you kindly,

 

Marijn Stam

 

 


gsm_modem sample changed in Zephyr 2.7 #ppp

Brenton Chetty
 

Hi there,

I was using the Zephyr 2.6 branch, and I got the gsm_sample to work for my application. I was using the nrf5340dk_nrf5340_cpuapp with a U-blox R211 gsm modem.

However, when I updated to Zephyr 2.7.99, I can no longer compile the gsm_modem sample.
I receive the following error : "fatal error: drivers/gsm_ppp.h: No such file or directory".

My overlay file contains the following:
&uart1 {
    status = "okay";
    current-speed = <115200>;
    tx-pin = <33>;
    rx-pin = <32>;
    rts-pin = <11>;
    cts-pin = <10>;
    gsm: gsm-modem {
        compatible = "zephyr,gsm-ppp";
        label = "gsm_ppp";
    };
};

May you please advise me on whatever configuration I seem to be missing?

With Festive Greetings :)
Brenton Chetty


Flash write support for hyperflash on mimxrt1050_evk #flash #driver

mbarrett@...
 

I'm in the process of adding device firmware upgrade support for the mimxrt1050_evk using the hyperflash.

To use the flash_img api I had to make the following change:
--- a/dts/bindings/mtd/nxp,imx-flexspi-hyperflash.yaml
+++ b/dts/bindings/mtd/nxp,imx-flexspi-hyperflash.yaml
@@ -5,4 +5,4 @@ description: NXP FlexSPI HyperFlash
 
 compatible: "nxp,imx-flexspi-hyperflash"
 
-include: nxp,imx-flexspi-device.yaml
+include: ["nxp,imx-flexspi-device.yaml", soc-nv-flash.yaml]


Now with the flash shell enabled when I do an erase, write, and then read, I don't read back exactly what is written:
> flash erase S26KS512S 340000
Erase success.
> flash read S26KS512S 340000 8
00340000: ff ff ff ff ff ff ff ff                          |........         |
 
> flash write S26KS512S 340000 0123 4567
Write OK.
Verification ERROR!
> flash read S26KS512S 340000 8
00340000: 01 00 00 00 01 40 00 00                          |.....@..         |


So it appears that flash was actually written, but more bits are set to 0 then expected. It must be on the write side because the device is booting from the hyperflash without issue. Is there a reason that the soc-nv-flash binding wasn't included for the hyperflash in the first place (something that isn't compatible that I'm unaware of)? I've noticed that changing the ahb-write-wait-interval property for the hyperflash in the board's device tree seems to have an effect on the result. Any insight anyone has would be greatly appreciated.

Thanks!
 
 

221 - 240 of 3032