Date   

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


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

Lubos, Robert
 

Hi Nikos,

 

Contributions are always welcome, would be also good to contribute the overlay-ot.conf to the lwm2m_client sample, once you have configuration that is proven to work. We even have an outstanding issue opened for that:
https://github.com/zephyrproject-rtos/zephyr/issues/18601

 

As for the issues reported, the first one (CONFIG_LWM2M_COAP_BLOCK_SIZE) looks to me like a bug, as this value is used to determine maximum supported packet size:
https://github.com/zephyrproject-rtos/zephyr/blob/master/subsys/net/lib/lwm2m/lwm2m_object.h#L133

Given that currently we only support block transfer for FW updates, it doesn’t seem like valid approach. As a workaround, you can modify `MAX_PACKET_SIZE` to some higher value and see if it helps.

 

The Kconfig error can be fixed by explicitly enabling TLS support in overlay-dtls.conf (CONFIG_MBEDTLS_TLS_VERSION_1_2=y). TLS is by default disabled for OpenThread to save RAM/ROM when not needed (OT uses mbedTLS internally). The sample relied on a default config, hence it didn’t work with OT enabled. Other Kconfig warnings can be disabled by overwriting the defaults from `prj.conf` in `overlay-ot.conf` (OT makes no use of IPv4).

As for DTLS testing, you may also need to increase mbedTLS heap size (CONFIG_MBEDTLS_HEAP_SIZE=8192), to make sure it’s enough for both, OpenThread and LwM2M.

 

Regards,

Robert

 

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

 

Thanks Robert, with your help I managed to make the OTBR work (I can make a documentation as contribution for the project if you are interested). Although, the device is registered to the leshan server as it should, I have two problems. The first one is that I can not change the CONFIG_LWM2M_COAP_BLOCK_SIZE to 64 (or 128) because I am getting the following error <err> net_lwm2m_rd_client: Registration err: -12 which I saw in API that corresponds to * Not enough core */. The second problem is that I can not build the lwm2m sample when I use the overlay-dtls.conf to enable communication over DTLS in the openthread network. The description of error is that error: Aborting due to Kconfig warnings the warnings are about the NET_IF_UNICAST_IPV4_ADDR_COUNT, NET_IF_MCAST_IPV4_ADDR_COUNT, TEST_RANDOM_GENERATOR and NET_SOCKETS_ENABLE_DTLS parameteres. I tried to comment in some of them but again I have problems. My build command is west build -p auto -b nrf52840dk_nrf52840 samples/net/lwm2m_client/ -d build_lwm2m -- -DCONF_FILE="prj.conf overlay-ot.conf overlay-dtls.conf"


Do you have any ideas?


API meeting: agenda

Carles Cufi
 


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

Nikos Karamolegkos
 

Thanks Robert, with your help I managed to make the OTBR work (I can make a documentation as contribution for the project if you are interested). Although, the device is registered to the leshan server as it should, I have two problems. The first one is that I can not change the CONFIG_LWM2M_COAP_BLOCK_SIZE to 64 (or 128) because I am getting the following error <err> net_lwm2m_rd_client: Registration err: -12 which I saw in API that corresponds to * Not enough core */. The second problem is that I can not build the lwm2m sample when I use the overlay-dtls.conf to enable communication over DTLS in the openthread network. The description of error is that error: Aborting due to Kconfig warnings the warnings are about the NET_IF_UNICAST_IPV4_ADDR_COUNT, NET_IF_MCAST_IPV4_ADDR_COUNT, TEST_RANDOM_GENERATOR and NET_SOCKETS_ENABLE_DTLS parameteres. I tried to comment in some of them but again I have problems. My build command is west build -p auto -b nrf52840dk_nrf52840 samples/net/lwm2m_client/ -d build_lwm2m -- -DCONF_FILE="prj.conf overlay-ot.conf overlay-dtls.conf"


Do you have any ideas?


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

Lubos, Robert
 

Hi Nikos,

 

If you use CONF_FILE option, you need to specify both, prj.conf and the overlay: “-- -DCONF_FILE="prj.conf overlay-usb-nrf-br.conf"”.

There’s also an OVERLAY_CONFIG option, where you can specify only the overlay file: “-- -DOVERLAY_CONFIG= overlay-usb-nrf-br.conf”.

 

Regarding OTBR, I’m sorry but I don’t have a working setup right now to test. For sure it’s critical that you provide the OTBR with the same channel/panid/network key as other Thread devices in your network.

The easiest way to determine whether you are connected to other devices is to use OT CLI component (OPENTHREAD_SHELL needs to be enabled, it is by default) and check children/router tables:

  • “ot role” to determine whether you are a router (leader in specific case) or a child
  • “ot child table” to see if you have any children in router role
  • “ot router table” to see if there are any other routers in your network
  • “ot parent” to see information about a parent router in child role

 

I haven’t worked with OTBR for some time, but I’m not sure if using “Join” option will work unless you have a commissioner in your network. I think that safer option would be to let the border router form the network (https://openthread.io/guides/border-router/web-gui#form_a_thread_network ) and then let your other device join it. Just make sure to use the same network parameters, as mentioned earlier.

 

Regards,

Robert

 

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

 

I am a bit lost.  I am trying to compile the OpenThread NCP sample in order to connect the nrf52840 dk with the raspberry which will be running the openthread border router docker image. In order to compile the sample I am running west build -b nrf52840dk_nrf52840 samples/net/openthread/ncp/ -- -DCONF_FILE="overlay-usb-nrf-br.conf" but I have to add CONFIG_UART_INTERRUPT_DRIVEN=y in the overlay file (otherwise I have errors). Is this a bug? Nevertheless, finally, when I am using the pre compiled image from openthread site for the nrf52840-dk and at the same time I have a node running the LWM2M sample with the default overlay-ot.conf file (from the echo client) I can see the network in the OTBR GUI. I am trying to join the network from the OTBR but I don't know how to continue (or to check if the procedure is successful)  . Is the OTBR configured ok? Have anybody experience running the the LWM2M client over OT using the border router? I will appreciate some help.


Re: Debug probes and setup #debugging #gdb #nrf52480 #ztest #bluetoothmesh

Carles Cufi
 

Hi Erik,

 

FYI, pyocd is Zephyr-aware and Nordic’s J-Link OBs can be reflashed with pyocd-compatible firmware:

https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF52-DK/Download#infotabs

 

Also:

https://twitter.com/SEGGERMicro/status/1298893256323932161?s=20

 

Carles

 

From: users@... <users@...> On Behalf Of Erik via lists.zephyrproject.org
Sent: 04 September 2020 18:31
To: users@...
Subject: [Zephyr-users] Debug probes and setup #bluetooth #debugging #gdb #nrf52480 #ztest #bluetoothmesh

 

Hi,
We are looking for direction on how best to improve our (multi-threaded) debugging capability.

Current setup:              host ---NRF52_dev_board (onboard jLink) -- custom Nordic-SoC board

where host is macOS and Win10 and our Bluetooth application can run either on dev or custom board.
We launch GDB debugging using west and for terminal output on macOS use separate JLinkRTTClient attaching to GDB (couldn't get regular terminal to work)

We understand JLink isn't ZephyrOS aware and per OpenOCD's most recent manual, neither is OpenOCD, so believe we need to run alt 
GDB server compiled with such support. We are hoping for a good out-of-box setup.
- Are there ways to stay with current setup and still see everything going on and step through code?
- Would debugging from within Docker Desktop, running below Docker image be possible/best path to align with what most people do?
  https://github.com/zephyrproject-rtos/docker-image
- Purchase a different HW probe (which one?) and use OpenOCD?
- If also want to debug/test Bluetooth app in QEMU, would we be forced to run on a Linux native host/dual boot, or can one emulate Bluetooth
   even if run in Docker image?

Would appreciate feedback on what works, and also paths to avoid.

  Erik


Debug probes and setup #debugging #gdb #nrf52480 #ztest #bluetoothmesh

Erik
 

Hi,
We are looking for direction on how best to improve our (multi-threaded) debugging capability.

Current setup:              host ---NRF52_dev_board (onboard jLink) -- custom Nordic-SoC board

where host is macOS and Win10 and our Bluetooth application can run either on dev or custom board.
We launch GDB debugging using west and for terminal output on macOS use separate JLinkRTTClient attaching to GDB (couldn't get regular terminal to work)

We understand JLink isn't ZephyrOS aware and per OpenOCD's most recent manual, neither is OpenOCD, so believe we need to run alt 
GDB server compiled with such support. We are hoping for a good out-of-box setup.
- Are there ways to stay with current setup and still see everything going on and step through code?
- Would debugging from within Docker Desktop, running below Docker image be possible/best path to align with what most people do?
  https://github.com/zephyrproject-rtos/docker-image
- Purchase a different HW probe (which one?) and use OpenOCD?
- If also want to debug/test Bluetooth app in QEMU, would we be forced to run on a Linux native host/dual boot, or can one emulate Bluetooth
   even if run in Docker image?

Would appreciate feedback on what works, and also paths to avoid.

  Erik

441 - 460 of 2659