|
Re: Zephyr Project using Eclipse
Stefan Jaritz
Morning, A bit tricky because Eclipse CDT integration of cmake is only available at the latest release and imho not very good. 1.) build from eclipse Simplest way: before: 2.) debug from eclipse the open ocd debuger from the gnu mcu pulgin works best
(https://gnu-mcu-eclipse.github.io/debug/openocd/) openocd.cfg from the board config run west debugserver and start the eclipse debug config
Good luck Stefan
On 09/11/2018 19:13, Nicholas Yameen
wrote:
|
|||||||||
|
|
|||||||||
|
Randy Chou <rchou3@...>
Hi Vinayak,
I merge the patch, host (nRF Connect) get update connection parameter request. After CI change to 30ms, it can keep connection a bit longer but it still disconnect after few minutes (distance is ~2m). If I move host close to device then the connection can keep more than one hour. I also try to change the CI back to 7.5ms and move host far away from device (~2m), the connection is also stable. Do you have any suggestion that I can help to debug this issue? Thanks, Randy
|
|||||||||
|
|
|||||||||
|
Re: Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle
#nrf52832
Hi Carles,
Thanks for the feedback. It seems the Qt QLowerEnergyController object selects the first valid address different from the zero address for addressing the HCI controller/adapter. In my case for Nordic Zephyr BLE Controller this is the random address when the public address is not set first different from the zero address by the hci cmd 0x3f 0x006 "address". Best regards, Frank
|
|||||||||
|
|
|||||||||
|
Re: lwip integration with OpenThread
#nrf52840
#lwip
#openthread
deepa.gopinath@...
Hi Paul,
I have found it in this link - https://github.com/zephyrproject-rtos/zephyr/issues/10561 By referring the config file also we can able to find Echo client and server example can be built for either OpenThread or third party IP stack. https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/echo_client/overlay-ot.conf Remaining config files will be used to build for other configurations - https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/net/echo_client/ Thanks & Regards, Deepa
|
|||||||||
|
|
|||||||||
|
Re: thread permissions issue
Diego Sueiro
On Sat, 10 Nov 2018 at 16:59, Diego Sueiro <diego.sueiro@gmail.com> wrote:
I managed to solve this by calling "k_thread_access_grant(k_current_get(), dev, NULL)" before calling the "Z_SYSCALL_DRIVER_SENSOR" macro. 2 - Even having the CONFIG_USERSAPCE=y set when callingThis question remains open.
|
|||||||||
|
|
|||||||||
|
thread permissions issue
Diego Sueiro
Hello Zephyrs,
I'm developing a shell module for the sensor drivers and I want to validate if the device name passed from the user is a sensor device. I have the CONFIG_USERSAPCE=y. After calling "dev = device_get_binding(argv[1])" I call the "Z_SYSCALL_DRIVER_SENSOR(dev, sample_fetch)" and I get the following error message: thread 0x2000064c (1) does not have permission on sensor driver 0x20005ac8 [0000] syscall cmd_get_sensor failed check: access denied Some questions: 1 - How do I grant permission to the running thread to access the sensor driver object? 2 - Even having the CONFIG_USERSAPCE=y set when calling "sensor_sample_fetch" it seems that it is calling the "_impl_sensor_sample_fetch" directly instead of "Z_SYSCALL_HANDLER(sensor_sample_fetch, dev)" defined in the drivers/sensor/sensor_handlers.c file. How can I have the current thread using the userspace syscalls? Regards, -- *dS Diego Sueiro
|
|||||||||
|
|
|||||||||
|
Re: Zephyr Project using Eclipse
Maureen Helm
Hi Nick, Once you’ve generated your project with CMake and imported it into Eclipse, you can edit source files in Eclipse and click the “Make” button to recompile your application.
Just be careful if you need to edit Kconfig variables, add new .c files to your project, or update the device tree, because these changes require regenerating your project with CMake. You’ll need to run ‘ninja pristine’ on the command line first, reinvoke CMake, then refresh your project in Eclipse.
Maureen
From: devel@... [mailto:devel@...]
On Behalf Of Nicholas Yameen
Sent: Friday, November 9, 2018 1:14 PM To: devel@... Subject: [Zephyr-devel] Zephyr Project using Eclipse
Hello,
I want to develop applications using the FRDM-K64F board from NXP using Eclipse. Is there any way to use Eclipse as an IDE and create a program, then flash it onto the board? I want to do my development all from Eclipse. Or do is Eclipse only used as a debugger? Thank you.
|
|||||||||
|
|
|||||||||
|
Zephyr Project using Eclipse
Nicholas Yameen <Nicholas.Yameen@...>
Hello,
I want to develop applications using the FRDM-K64F board from NXP using Eclipse. Is there any way to use Eclipse as an IDE and create a program, then flash it onto the board? I want to do my development all from Eclipse. Or do is Eclipse only used as a debugger? Thank you.
|
|||||||||
|
|
|||||||||
|
Re: __ASSERT - transfer to error handler
Boie, Andrew P
I'm patiently waiting for a paradise times when on CPU exception, assert, etc.,We do dump this info to the console on a fatal CPU exception. On x86 there's even a crude stack trace. But it would be nice, if running some application under GDB, for the exception to simply break the debugger at the offending instruction rather than go through Zephyr's exception handling path. I'm not sure how this could work, perhaps have the Zephyr exception handler set up the stack/registers to the original context and issue a debug exception? Or would this involve some kind of Zephyr-aware extension to GDB? The problem is always that the stack layout for a CPU exception is different than a function call, and might not even be on the same stack, so you can't easily unwind through when the exception happened to the original faulting context. Andrew
|
|||||||||
|
|
|||||||||
|
Re: __ASSERT - transfer to error handler
Boie, Andrew P
It's better to call k_oops() or k_panic() than _SysFatalErrorHandler() directly. You will actually get useful information about where the error occurred, instead of having to pass in a NULL exception stack frame.
Andrew
From: devel@... [mailto:devel@...]
On Behalf Of Skøien, Kristoffer
Sent: Friday, November 9, 2018 12:11 AM To: devel@... Subject: [Zephyr-devel] __ASSERT - transfer to error handler
Current implementation: The __ASSERT macro is extensively used in the Zephyr codebase and in application code for debugging during development. In case of an ASSERT, the code jumps to __ASSERT_POST which spins the given thread in a while(1).
Issue: During development and debugging, simply looping the thread will mask that the ASSERT has triggered. The only feedback the user gets of an assert is a printout. This can be missed if e.g.: - The RTT or Serial debug interface is down or unused - There is too much logging so that the “ASSERTION FAIL” can be missed
Proposed solution: In __ASSERT_POST provide a function call that will end up a user definable error handler. E.g. _SysFatalErrorHandler
This will let the developer set given SOC pins in case of an ASSERT, ask for a specific LED pattern to be set or print further debug messages.
Feedback is appreciated.
Kind regards Kristoffer
|
|||||||||
|
|
|||||||||
|
Re: Zephyr: FDRM_K64f board from NXP
Florian Fouillet <Florian.Fouillet@...>
Thanks everyone, I will have a look at the DTS.
Cheers,
From: Diego Sueiro [mailto:diego.sueiro@...]
Sent: Friday, November 9, 2018 10:32 AM To: Andrei <andrei.emeltchenko.news@...> Cc: Florian Fouillet <Florian.Fouillet@...>; devel@... Subject: Re: [Zephyr-devel] Zephyr: FDRM_K64f board from NXP
[External email: Use caution with links and attachments]
On Fri, 9 Nov 2018, 3:22 pm Andrei <andrei.emeltchenko.news@... wrote:
Take a look at the documentation to understand how this process works:
|
|||||||||
|
|
|||||||||
|
Re: Zephyr: FDRM_K64f board from NXP
Diego Sueiro
On Fri, 9 Nov 2018, 3:22 pm Andrei <andrei.emeltchenko.news@... wrote: Hi, Take a look at the documentation to understand how this process works:
|
|||||||||
|
|
|||||||||
|
Re: Zephyr: FDRM_K64f board from NXP
Andrei
Hi,
On Fri, Nov 09, 2018 at 01:05:42PM +0000, Florian Fouillet wrote: Hi,It is done somehow through DTS, you need to search i.e. ./zephyr/include/generated/generated_dts_board.h Best regards Andrei Emeltchenko
|
|||||||||
|
|
|||||||||
|
Zephyr: FDRM_K64f board from NXP
Florian Fouillet <Florian.Fouillet@...>
Hi,
I am currently working on the Zephyr OS with a FDRM_K64f board from NXP. I am just going through the documentation and the code example for now.
|
|||||||||
|
|
|||||||||
|
Zephyr 1.13.0 HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle
Vieren Frank <F.Vieren@...>
Hallo Zephyr community,
Anyone knowing why the BD address is always the ZERO address, when using the nRF52 board running the Zephyr HCI uart hex. I also see that the random address remains the same after power cycling the nRF board. Also differences in showing the address for the HCI controller when running the bluetoothctl and hcitool dev commands.
Please see my findings described here in the Nordic Dev Zone, last reply in message queue.
Any feedback is very welcome, Thanks in advance, Frank
|
|||||||||
|
|
|||||||||
|
__ASSERT - transfer to error handler
Skøien, Kristoffer <Kristoffer.Skoien@...>
Current implementation: The __ASSERT macro is extensively used in the Zephyr codebase and in application code for debugging during development. In case of an ASSERT, the code jumps to __ASSERT_POST which spins the given thread in a while(1).
Issue: During development and debugging, simply looping the thread will mask that the ASSERT has triggered. The only feedback the user gets of an assert is a printout. This can be missed if e.g.: - The RTT or Serial debug interface is down or unused - There is too much logging so that the “ASSERTION FAIL” can be missed
Proposed solution: In __ASSERT_POST provide a function call that will end up a user definable error handler. E.g. _SysFatalErrorHandler
This will let the developer set given SOC pins in case of an ASSERT, ask for a specific LED pattern to be set or print further debug messages.
Feedback is appreciated.
Kind regards Kristoffer
|
|||||||||
|
|
|||||||||
|
Re: __ASSERT - transfer to error handler
kristoffer.skoien@...
Thanks for your reply Paul.
Perhaps something simliar to this: #if defined(CONFIG_ARCH_POSIX)
extern void posix_exit(int exit_code);
#define __ASSERT_POST posix_exit(1)
#elif defined(CONFIG_ASSERT_ERR_HANDLER) #define __ASSERT_POST _SysFatalErrorHandler(?,?) #else
#define __ASSERT_POST \
for (;;) { \
/* spin thread */ \
}
#endif
|
|||||||||
|
|
|||||||||
|
Re: Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle
#nrf52832
Carles Cufi
Hi there,
The *public* address is all zeroes because Nordic ICs do not come with one pre-assigned. The *random static* address is set by BlueZ itself, so it will be whatever BlueZ decides it to be. You don’t typically need a public address to work with BLE.
Carles
From: devel@... <devel@...>
On Behalf Of frv
Sent: 09 November 2018 11:49 To: Zephyr-devel@... Subject: [Zephyr-devel] Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832
Hallo Zephyr community,
Anyone knowing why the BD address is always the ZERO address, when using the nRF52 board running the Zephyr HCI uart hex. I also see that the random address remains the same after power cycling the nRF board. Also differences in showing the address for the HCI controller when running the bluetoothctl and hcitool dev commands. Nor using the hcitool or btmgmt tool makes it possible to adjust the addressing, only so far the hcitool cmd 0x3f 0x006 address makes a difference as long as the board is not power cycled (as the setting is volatile, the default non volatile addresses to zero it seems).
Please see my findings described more in detail here in the Nordic Dev Zone, last reply in the message queue.
Any feedback is very welcome, Thanks in advance, Frank
|
|||||||||
|
|
|||||||||
|
Re: __ASSERT - transfer to error handler
Paul Sokolovsky
Hello Kristoffer,
As a quick reply, definitely ack on the problem statement. I can say more, I'm patiently waiting for a paradise times when on CPU exception, assert, etc., we'll be ending up in debugger, point to the instruction where the problem happened (or it can be seen in backtrace). (To be exact, I'm talking about running in QEMU first of all, I actually don't remember how that works on real hw.) As for specific implementation, perhaps more knowledgeable people can comment. I would just point that an obvious override point is __ASSERT_POST macro itself. I.e. instead of defining it unconditionally, we can have #ifdef around it, and let a user override it before inclusion of Zephyr headers. That's the simplest, but perhaps not the most scalable solution. On Fri, 09 Nov 2018 01:39:34 -0800 kristoffer.skoien@nordicsemi.no wrote: Current implementation: -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|||||||||
|
|
|||||||||
|
Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle
#nrf52832
frv
Hallo Zephyr community,
Anyone knowing why the BD address is always the ZERO address, when using the nRF52 board running the Zephyr HCI uart hex. I also see that the random address remains the same after power cycling the nRF board. Also differences in showing the address for the HCI controller when running the bluetoothctl and hcitool dev commands. Nor using the hcitool or btmgmt tool makes it possible to adjust the addressing, only so far the hcitool cmd 0x3f 0x006 address makes a difference as long as the board is not power cycled (as the setting is volatile, the default non volatile addresses to zero it seems).
Please see my findings described more in detail here in the Nordic Dev Zone, last reply in the message queue.
Any feedback is very welcome, Thanks in advance, Frank
|
|||||||||
|
|
|||||||||
