Date   

Re: Password Protection for Shell #uart #api

Chruściński, Krzysztof
 

Hi Dave,

 

I think you could try to look into selecting root command feature. Create dummy command with only “login” subcommand. Set this dummy command during system startup (shell_set_root_command(“dummy_cmd”) as root command. Then to enable all commands reset root command on login ( shell_set_root_cmd(NULL)). It can give a notion of shell protection. There is one thing though: select command and a key shortcut which is equivalent of shell_set_root_cmd(NULL) that must be disabled (CONFIG_SHELL_CMDS_SELECT=n).

 

Regards,

Krzysztof

 

From: users@... <users@...> On Behalf Of dave via lists.zephyrproject.org
Sent: Tuesday, September 15, 2020 10:17 PM
To: users@...
Subject: [Zephyr-users] Password Protection for Shell #uart #api

 

Hello,
I'm quite new to Zephyr, so I may have missed this, but I can't seem to find an easy way to add a simple password protection wall for the shell commands. I don't need or expect a full user model with permissions, just a simple "root" style password that can hide the commands until it is entered. Assuming I connect my device over USB and bring up the shell as a serial console, I can see that I have full access to all the shell commands without any protections. I often design products that use the shell/CLI as an interface to verify the system during manufacturing, as well as deal with systems that may have been bricked in the field, so it's something I'd like to continue using - but I don't want this to be wide open to users.

I could imagine using the API to create a command, like say "login", with a password argument field - but maybe there is a more elegant way?

Thanks in advance for the help!

Cheers,
Dave MacLeod


Re: How to resolve FATAL ERROR that displayed when I edited, modified some files.

Dicek Bear
 

Dear Zephyr Users, Developers,

Thank you for good support.
I did not know that header files and c-sources comments can not  include any irregular code that represent some languages' characters except alphabet.

Now I replaced all comments to the alphabet. Then the problem is solved.  

Thank you and best regards,
Dicek Bear.

2020年9月11日(金) 12:20 Dicek Bear via lists.zephyrproject.org <dicek334=gmail.com@...>:

Dear Zephyr Users, Developers,

I am a beginner of Zepher OS, so it is too difficult to analyze the following problem.
Please teach me how to resolve it.

First step,
I install the development environment as following "Getting Started Guide "https://docs.zephyrproject.org/latest/getting_started/index.html".
Then I try some samples and demos, 'hello_world', 'blinky', 'Button','console_getchar() Sample Application','console_getline() Sample Application'
and so on. The build command is "$ west build -p auto -b atsamr21_xpro samples/hello_world/".

Second step,
I edit, modify some header files and c-source files, then I rebuild 'hello_world' sample again. It is no problem.
The rebuild command is "$ west build -p auto -b atsamr21_xpro samples/hello_world/".

Third step,
I clean the build files. The clean command  is "$west build -t clean". It is no problem.

Fourth step,
I try to build again with the same build command "$ west build -p auto -b atsamr21_xpro samples/hello_world/". It causes 'FATAL ERROR".
The following is the displayed messages.

==================================================================================================================================
vagrant@ubuntu2004:~/zephyrproject/zephyr$ west build -p auto -b atsamr21_xpro samples/hello_world/
[1/122] Preparing syscall dependency handling
[3/122] Generating misc/generated/syscalls.json, misc/generated/struct_tags.json
FAILED: zephyr/misc/generated/syscalls.json zephyr/misc/generated/struct_tags.json
cd /home/vagrant/zephyrproject/zephyr/build/zephyr && /usr/bin/python3.8 /home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py --include /home/vagrant/zephyrproject/zephyr/include --include /home/vagrant/zephyrproject/zephyr/drivers --include /home/vagrant/zephyrproject/zephyr/subsys/net --json-file /home/vagrant/zephyrproject/zephyr/build/zephyr/misc/generated/syscalls.json --tag-struct-file /home/vagrant/zephyrproject/zephyr/build/zephyr/misc/generated/struct_tags.json
Traceback (most recent call last):
  File "/home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py", line 153, in <module>
    main()
  File "/home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py", line 132, in main
    syscalls, tagged = analyze_headers(args.include)
  File "/home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py", line 80, in analyze_headers
    contents = fp.read()
  File "/usr/lib/python3.8/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8f in position 16151: invalid start byte
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/vagrant/zephyrproject/zephyr/build
==================================================================================================================================

Are there any rules to edit, modify header files and c-source files ?.

Thank you and best regards,
Dicek Bear.


Password Protection for Shell #uart #api

dave@...
 

Hello,
I'm quite new to Zephyr, so I may have missed this, but I can't seem to find an easy way to add a simple password protection wall for the shell commands. I don't need or expect a full user model with permissions, just a simple "root" style password that can hide the commands until it is entered. Assuming I connect my device over USB and bring up the shell as a serial console, I can see that I have full access to all the shell commands without any protections. I often design products that use the shell/CLI as an interface to verify the system during manufacturing, as well as deal with systems that may have been bricked in the field, so it's something I'd like to continue using - but I don't want this to be wide open to users.

I could imagine using the API to create a command, like say "login", with a password argument field - but maybe there is a more elegant way?

Thanks in advance for the help!

Cheers,
Dave MacLeod


API meeting: agenda

Carles Cufi
 


Re: Requesting Bug list for ZephyrProject release 1.14.0

Carles Cufi
 

Hi Harish,

 

Best I can think of for that is to use a filter in GitHub to see all issues (open and closed) that target the next 1.14.3 release:

https://github.com/zephyrproject-rtos/zephyr/issues?q=+is%3Aissue+milestone%3Av1.14.3+

 

Carles

 

From: Harish KothandaRaman <harish.kothandaraman@...>
Sent: 14 September 2020 14:47
To: Cufi, Carles <Carles.Cufi@...>
Cc: users@...; Arjun Chinta <arjun@...>
Subject: Re: [Zephyr-users] Requesting Bug list for ZephyrProject release 1.14.0

 

Hello Carles,

 

Thanks for the pointers. I really appreciate your help.

From the above link it is possible to get the list of issue that has been fixed in version 1.14.x , but is it possible for us to know what where the issue that was pending when v1.14.x was released?

 

Thanks,

Harish K



On Sep 14, 2020, at 7:32 AM, Cufi, Carles <Carles.Cufi@...> wrote:

 

Hi Harish,

 

You can browse the issues that were addressed in the 1.14.x releases here:

 

 

Then there’s also the vulnerability list:

 

Thanks,

 

Carles

 

From: users@... <users@...> On Behalf Of Harish KothandaRaman via lists.zephyrproject.org
Sent: 09 September 2020 20:25
To: users@...
Cc: Arjun Chinta <arjun@...>
Subject: [Zephyr-users] Requesting Bug list for ZephyrProject release 1.14.0

 

Hello,

 

This is Harish Working for NupulseCV an medical device manufacturer. 

We have used the Zephyr project  (release version v1.14.0), in our development of BLE 5.0 support for our device which uses nordic nRF52840, which was helpful in speeding our development. 

As being a medical device manufacturer, we need to submit details about the Off-the-shelf software (OTSS) documentation for Zephyr project to FDA.

For this process we need help from zephyr project team to identify the list of known issues in the Zephyr OS version v1.14.0. With this list we would be able to evaluate the risks of the bug to our device.

 

We were able to find the list of current issues in Zephyr OS from the following gitHub link.

But it would be really helpful for us to understand what were the pending issues for  nRF project for Zephyr OS v1.14.0.

 

Thanks in anticipation.

 

Regards

Harish K

 

 

 


Re: Requesting Bug list for ZephyrProject release 1.14.0

Harish KothandaRaman <harish.kothandaraman@...>
 

Hello Carles,

Thanks for the pointers. I really appreciate your help.
From the above link it is possible to get the list of issue that has been fixed in version 1.14.x , but is it possible for us to know what where the issue that was pending when v1.14.x was released?

Thanks,
Harish K

On Sep 14, 2020, at 7:32 AM, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Harish,
 
You can browse the issues that were addressed in the 1.14.x releases here:
 
 
Then there’s also the vulnerability list:
 
Thanks,
 
Carles
 
From: users@... <users@...> On Behalf Of Harish KothandaRaman via lists.zephyrproject.org
Sent: 09 September 2020 20:25
To: users@...
Cc: Arjun Chinta <arjun@...>
Subject: [Zephyr-users] Requesting Bug list for ZephyrProject release 1.14.0
 
Hello,
 
This is Harish Working for NupulseCV an medical device manufacturer. 
We have used the Zephyr project  (release version v1.14.0), in our development of BLE 5.0 support for our device which uses nordic nRF52840, which was helpful in speeding our development. 
As being a medical device manufacturer, we need to submit details about the Off-the-shelf software (OTSS) documentation for Zephyr project to FDA.
For this process we need help from zephyr project team to identify the list of known issues in the Zephyr OS version v1.14.0. With this list we would be able to evaluate the risks of the bug to our device.
 
We were able to find the list of current issues in Zephyr OS from the following gitHub link.
But it would be really helpful for us to understand what were the pending issues for  nRF project for Zephyr OS v1.14.0.
 
Thanks in anticipation.
 
Regards
Harish K
 
 


Re: Requesting Bug list for ZephyrProject release 1.14.0

Carles Cufi
 

Hi Harish,

 

You can browse the issues that were addressed in the 1.14.x releases here:

https://docs.zephyrproject.org/1.14.1/releases/release-notes-1.14.html

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

 

 

Then there’s also the vulnerability list:

https://docs.zephyrproject.org/latest/security/vulnerabilities.html

 

Thanks,

 

Carles

 

From: users@... <users@...> On Behalf Of Harish KothandaRaman via lists.zephyrproject.org
Sent: 09 September 2020 20:25
To: users@...
Cc: Arjun Chinta <arjun@...>
Subject: [Zephyr-users] Requesting Bug list for ZephyrProject release 1.14.0

 

Hello,

 

This is Harish Working for NupulseCV an medical device manufacturer. 

We have used the Zephyr project  (release version v1.14.0), in our development of BLE 5.0 support for our device which uses nordic nRF52840, which was helpful in speeding our development. 

As being a medical device manufacturer, we need to submit details about the Off-the-shelf software (OTSS) documentation for Zephyr project to FDA.

For this process we need help from zephyr project team to identify the list of known issues in the Zephyr OS version v1.14.0. With this list we would be able to evaluate the risks of the bug to our device.

 

We were able to find the list of current issues in Zephyr OS from the following gitHub link.

But it would be really helpful for us to understand what were the pending issues for  nRF project for Zephyr OS v1.14.0.

 

Thanks in anticipation.

 

Regards

Harish K

 

 


Re: Custom linker script for module #api

EugKrashtan
 

Ok, solution found. Adding zephyr_linker_sources(SECTIONS custom-sections.ld) into cmakelists.txt inside module folder giver required flexibility.
Thanks!


Custom linker script for module #api

EugKrashtan
 

Hi.
My custom module requires an additional ROM section. Is it possible to define CONFIG_CUSTOM_LINKER_SCRIPT for module only without adding this option to prj.conf file?

WBR,
  Eugene


Re: v2.4.0-rc1: Can't set GPIO pin output during pinmux initialization

Erwan Gouriou
 

Thanks Brix.

Helge, FYI, you might be interested in https://github.com/zephyrproject-rtos/zephyr/issues/27985 that will work around the issue for V2.4.0.

BR
Erwan

On Wed, 9 Sep 2020 at 21:48, Henrik Brix Andersen <henrik@...> wrote:
Hi all,

This problem is due to a change in the device initialisation:
https://github.com/zephyrproject-rtos/zephyr/pull/28198

Regards,
Brix
-- 
Henrik Brix Andersen

> On 9 Sep 2020, at 16.27, Erwan Gouriou <erwan.gouriou@...> wrote:
>
> Hi Helge,
>
> Looking into it quickly, there has been no change in the init priorities on gpio or pinmux.
> board pinmux init: PRE_KERNEL_1
> gpio init: POST_KERNEL
> So, what seems strange also is that it had effect in v2.3.0.
>
> Anyway, the problem still stands.
>
> I don't see a particular reason you wouldn't not be allowed to make this call.
> So the actual solution would be to change gpio driver prio to PRE_KERNEL (has to be after clock_control and interrupt_controler though)
> I can't tell if there is a reason it is not the case already.
>
> BR
> Erwan
>
>
>
> On Tue, 8 Sep 2020 at 15:57, Helge Juul <helge.juul@...> wrote:
> Hi.
>
> I'm in the process of updating Zephyr from v2.3.0 to v2.4.0-rc1 and I've seen an unexpected change.
>
> I have a custom board, and in the pinmux initialization I'm using the GPIO API to set some pins that need early initialization:
>
> static int pinmux_stm32_init(const struct device *port)
> {
>     ARG_UNUSED(port);
>     stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));
>
>     const struct device *porti = device_get_binding("GPIOI");
>     gpio_pin_configure(porti, 11, GPIO_OUTPUT_HIGH);
>     gpio_pin_configure(porti, 12, GPIO_OUTPUT_HIGH);
>
>     return 0;
> }
>
> This works with v2.3.0.
> With v2.4.0-rc1 it builds without warnings, but when I try to run it on target it crashes during initialization.
>
> During my debugging I've found that the GPIO API is in fact initialized _after_ the pinmux initialization, so that might be an issue.
>
> Questions:
> 1.  Is this supposed to work? (using GPIO API from within pinmux_stm32_init())
> 2.  If not, what is the proper way of setting a pin high or low at this stage of the initialization sequence? stm32_setup_pins() only sets pin configurations, not actual pin value. (I can of course write directly to GPIO registers, but there's gotta be a better way)
>
> Thanks,
> Helge
>
>


How to resolve FATAL ERROR that displayed when I edited, modified some files.

Dicek Bear
 

Dear Zephyr Users, Developers,

I am a beginner of Zepher OS, so it is too difficult to analyze the following problem.
Please teach me how to resolve it.

First step,
I install the development environment as following "Getting Started Guide "https://docs.zephyrproject.org/latest/getting_started/index.html".
Then I try some samples and demos, 'hello_world', 'blinky', 'Button','console_getchar() Sample Application','console_getline() Sample Application'
and so on. The build command is "$ west build -p auto -b atsamr21_xpro samples/hello_world/".

Second step,
I edit, modify some header files and c-source files, then I rebuild 'hello_world' sample again. It is no problem.
The rebuild command is "$ west build -p auto -b atsamr21_xpro samples/hello_world/".

Third step,
I clean the build files. The clean command  is "$west build -t clean". It is no problem.

Fourth step,
I try to build again with the same build command "$ west build -p auto -b atsamr21_xpro samples/hello_world/". It causes 'FATAL ERROR".
The following is the displayed messages.

==================================================================================================================================
vagrant@ubuntu2004:~/zephyrproject/zephyr$ west build -p auto -b atsamr21_xpro samples/hello_world/
[1/122] Preparing syscall dependency handling
[3/122] Generating misc/generated/syscalls.json, misc/generated/struct_tags.json
FAILED: zephyr/misc/generated/syscalls.json zephyr/misc/generated/struct_tags.json
cd /home/vagrant/zephyrproject/zephyr/build/zephyr && /usr/bin/python3.8 /home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py --include /home/vagrant/zephyrproject/zephyr/include --include /home/vagrant/zephyrproject/zephyr/drivers --include /home/vagrant/zephyrproject/zephyr/subsys/net --json-file /home/vagrant/zephyrproject/zephyr/build/zephyr/misc/generated/syscalls.json --tag-struct-file /home/vagrant/zephyrproject/zephyr/build/zephyr/misc/generated/struct_tags.json
Traceback (most recent call last):
  File "/home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py", line 153, in <module>
    main()
  File "/home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py", line 132, in main
    syscalls, tagged = analyze_headers(args.include)
  File "/home/vagrant/zephyrproject/zephyr/scripts/parse_syscalls.py", line 80, in analyze_headers
    contents = fp.read()
  File "/usr/lib/python3.8/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8f in position 16151: invalid start byte
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/vagrant/zephyrproject/zephyr/build
==================================================================================================================================

Are there any rules to edit, modify header files and c-source files ?.

Thank you and best regards,
Dicek Bear.


Build fails : arm-none-eabi-gcc.exe: error: unrecognized argument in option '-mabi=lp64'.

Hanumesha Ks <hanumesha.ks@...>
 

Hi Zephyr Users,

 

I tried to execute following command,  

\zephyrproject\zephyr>west build -b qemu_cortex_a53 -d build\hello_world samples\hello_world

by v2.3.0 release on Windows-10  with gcc-arm-none-eabi-9-2019-q4-major-win32

but my build fails with error arm-none-eabi-gcc.exe: error: unrecognized argument in option '-mabi=lp64'.

 

Build fails screenshot pasted below.

 

 

As per the gcc AArch64 “-mabi” Permissible values are  -mabi=ilp32 and -mabi=lp64 more info in below link.

https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options

 

Please guide me to resolve this issue ?

 

Best Regards

Hanumesha KS

Software engineer

NXP – Bangalore  

 

 

 


Re: Flash two firmware in flash and jump from one address to another #flash #nrf52480

Nikos Karamolegkos
 

Hello, after all I am flashing the base firmware (first app) into 0x0 address and then using the CONFIG_FLASH_LOAD_OFFSET=0x20000 to the proj.conf  of the second app I am flashing the second firmware in the 0x20000 address. Therefore, when I press a button from the first app I can jump to the second firmware. The only issue now is that I would like to update the start address to 0x20000 before the "jump" (in this way if I press reset the second app will boot). I have looked to the flash configs of zephyr but I have not found something useful. Any ideas?


Re: Direct ISR support on ARC

Justin Huang
 

Thank you Ruud for sharing and sorry for replying late.
You nail it: I was checking Zephyr 2.0.0. I will get the latest copy and give it a try.

Many thanks again,
Justin


From: users@... <users@...> on behalf of Ruud Derwig <ruud.derwig@...>
Sent: Monday, August 31, 2020 2:19 AM
To: Justin Huang <justin.y.huang@...>; users@... <users@...>
Subject: Re: [Zephyr-users] Direct ISR support on ARC
 

Hi Justin,

 

What version are you using? ARC support for direct interrupts was added in v2.1

(and note that Z_ARCH_IRQ_DIRECT_CONNECT was renamed to ARCH_IRQ_DIRECT_CONNECT).

 

Regards,

 

Ruud.

 

From: users@... <users@...> On Behalf Of Justin Huang
Sent: Saturday, August 29, 2020 2:45 AM
To: users@...
Subject: [Zephyr-users] Direct ISR support on ARC

 

Hi,

 

It appears to me that there is no support of 'direct ISR' by Zepher for the ARC processors: I do not see the definition of Z_ARCH_IRQ_DIRECT_CONNECT in the irq.h for ARC. 

Could someone please share why it is not supported?

 

Thanks,
Justin


Re: v2.4.0-rc1: Can't set GPIO pin output during pinmux initialization

Henrik Brix Andersen
 

Hi all,

This problem is due to a change in the device initialisation:
https://github.com/zephyrproject-rtos/zephyr/pull/28198

Regards,
Brix
--
Henrik Brix Andersen

On 9 Sep 2020, at 16.27, Erwan Gouriou <erwan.gouriou@linaro.org> wrote:

Hi Helge,

Looking into it quickly, there has been no change in the init priorities on gpio or pinmux.
board pinmux init: PRE_KERNEL_1
gpio init: POST_KERNEL
So, what seems strange also is that it had effect in v2.3.0.

Anyway, the problem still stands.

I don't see a particular reason you wouldn't not be allowed to make this call.
So the actual solution would be to change gpio driver prio to PRE_KERNEL (has to be after clock_control and interrupt_controler though)
I can't tell if there is a reason it is not the case already.

BR
Erwan



On Tue, 8 Sep 2020 at 15:57, Helge Juul <helge.juul@nortekgroup.com> wrote:
Hi.

I'm in the process of updating Zephyr from v2.3.0 to v2.4.0-rc1 and I've seen an unexpected change.

I have a custom board, and in the pinmux initialization I'm using the GPIO API to set some pins that need early initialization:

static int pinmux_stm32_init(const struct device *port)
{
ARG_UNUSED(port);
stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));

const struct device *porti = device_get_binding("GPIOI");
gpio_pin_configure(porti, 11, GPIO_OUTPUT_HIGH);
gpio_pin_configure(porti, 12, GPIO_OUTPUT_HIGH);

return 0;
}

This works with v2.3.0.
With v2.4.0-rc1 it builds without warnings, but when I try to run it on target it crashes during initialization.

During my debugging I've found that the GPIO API is in fact initialized _after_ the pinmux initialization, so that might be an issue.

Questions:
1. Is this supposed to work? (using GPIO API from within pinmux_stm32_init())
2. If not, what is the proper way of setting a pin high or low at this stage of the initialization sequence? stm32_setup_pins() only sets pin configurations, not actual pin value. (I can of course write directly to GPIO registers, but there's gotta be a better way)

Thanks,
Helge



Requesting Bug list for ZephyrProject release 1.14.0

Harish KothandaRaman <harish.kothandaraman@...>
 

Hello,

This is Harish Working for NupulseCV an medical device manufacturer. 
We have used the Zephyr project  (release version v1.14.0), in our development of BLE 5.0 support for our device which uses nordic nRF52840, which was helpful in speeding our development. 
As being a medical device manufacturer, we need to submit details about the Off-the-shelf software (OTSS) documentation for Zephyr project to FDA.
For this process we need help from zephyr project team to identify the list of known issues in the Zephyr OS version v1.14.0. With this list we would be able to evaluate the risks of the bug to our device.

We were able to find the list of current issues in Zephyr OS from the following gitHub link.
But it would be really helpful for us to understand what were the pending issues for  nRF project for Zephyr OS v1.14.0.

Thanks in anticipation.

Regards
Harish K



Re: v2.4.0-rc1: Can't set GPIO pin output during pinmux initialization

Erwan Gouriou
 

Hi Helge,

Looking into it quickly, there has been no change in the init priorities on gpio or pinmux.
board pinmux init: PRE_KERNEL_1
gpio init: POST_KERNEL
So, what seems strange also is that it had effect in v2.3.0.

Anyway, the problem still stands.

I don't see a particular reason you wouldn't not be allowed to make this call.
So the actual solution would be to change gpio driver prio to PRE_KERNEL (has to be after clock_control and interrupt_controler though)
I can't tell if there is a reason it is not the case already.

BR
Erwan



On Tue, 8 Sep 2020 at 15:57, Helge Juul <helge.juul@...> wrote:
Hi.

I'm in the process of updating Zephyr from v2.3.0 to v2.4.0-rc1 and I've seen an unexpected change.

I have a custom board, and in the pinmux initialization I'm using the GPIO API to set some pins that need early initialization:

static int pinmux_stm32_init(const struct device *port)
{
    ARG_UNUSED(port);
    stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));

    const struct device *porti = device_get_binding("GPIOI");
    gpio_pin_configure(porti, 11, GPIO_OUTPUT_HIGH);
    gpio_pin_configure(porti, 12, GPIO_OUTPUT_HIGH);

    return 0;
}

This works with v2.3.0.
With v2.4.0-rc1 it builds without warnings, but when I try to run it on target it crashes during initialization.

During my debugging I've found that the GPIO API is in fact initialized _after_ the pinmux initialization, so that might be an issue.

Questions:
1.  Is this supposed to work? (using GPIO API from within pinmux_stm32_init())
2.  If not, what is the proper way of setting a pin high or low at this stage of the initialization sequence? stm32_setup_pins() only sets pin configurations, not actual pin value. (I can of course write directly to GPIO registers, but there's gotta be a better way)

Thanks,
Helge



Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Lubos, Robert
 

I just meant that OpenThread uses mbedTLS as it’s crypto library, for instance:
https://github.com/openthread/openthread/blob/master/src/core/crypto/sha256.cpp#L41

 

Regards,

Robert

 

From: users@... [mailto:users@...] On Behalf Of Nikos Karamolegkos via lists.zephyrproject.org
Sent: Wednesday, September 9, 2020 10:50
To: users@...
Subject: Re: [Zephyr-users] LWM2M client to nrf582540-DK #nrf52840 #networking

 

Perfect. I will prepare the configuration for the contribution. I made the changes you proposed and worked (I set MAX_PACKET_SIZE to 1024). Just to be clear by what do you mean by "OT use mbedTLS internally"?


Re: LWM2M client to nrf582540-DK #nrf52840 #networking

Nikos Karamolegkos
 

Perfect. I will prepare the configuration for the contribution. I made the changes you proposed and worked (I set MAX_PACKET_SIZE to 1024). Just to be clear by what do you mean by "OT use mbedTLS internally"?


v2.4.0-rc1: Can't set GPIO pin output during pinmux initialization

Helge Juul
 

Hi.

I'm in the process of updating Zephyr from v2.3.0 to v2.4.0-rc1 and I've seen an unexpected change.

I have a custom board, and in the pinmux initialization I'm using the GPIO API to set some pins that need early initialization:

static int pinmux_stm32_init(const struct device *port)
{
    ARG_UNUSED(port);
    stm32_setup_pins(pinconf, ARRAY_SIZE(pinconf));

    const struct device *porti = device_get_binding("GPIOI");
    gpio_pin_configure(porti, 11, GPIO_OUTPUT_HIGH);
    gpio_pin_configure(porti, 12, GPIO_OUTPUT_HIGH);

    return 0;
}

This works with v2.3.0.
With v2.4.0-rc1 it builds without warnings, but when I try to run it on target it crashes during initialization.

During my debugging I've found that the GPIO API is in fact initialized _after_ the pinmux initialization, so that might be an issue.

Questions:
1. Is this supposed to work? (using GPIO API from within pinmux_stm32_init())
2. If not, what is the proper way of setting a pin high or low at this stage of the initialization sequence? stm32_setup_pins() only sets pin configurations, not actual pin value. (I can of course write directly to GPIO registers, but there's gotta be a better way)

Thanks,
Helge

481 - 500 of 2705