Re: Looking for help with SAMD2x
Vincent - VLoTech
Hi Kumar,
toggle quoted messageShow quoted text
We work mostly with sam4s series but also used samd21 before. I can help you with the maintenance and also align the atmel SoC series. Please let me know if you are interested in my help and what is needed. Kind regards Vincent
Op 16 nov. 2018 om 18:28 heeft Kumar Gala <kumar.gala@linaro.org> het volgende geschreven:
|
|
Not able to build any project
vikrant8051 <vikrant8051@...>
Hello, After latest sync with master branch not able to build any project .... For details this is log for building hello_world app ... ----------------------------------------------------------------------------------------------------------------------------- root@computer:/home/vikrant/zephyr/samples/hello_world/build# cmake -GNinja -DBOARD=nrf52840_pca10056 .. -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.6", minimum required is "3.4") -- Selected BOARD nrf52840_pca10056 Zephyr version: 1.13.99 Parsing Kconfig tree in /home/vikrant/zephyr/Kconfig Loading /home/vikrant/zephyr/boards/arm/nrf52840_pca10056/nrf52840_pca10056_defconfig as base Merging /home/vikrant/zephyr/samples/hello_world/prj.conf -- Generating zephyr/include/generated/generated_dts_board.h nrf52840_pca10056.dts_compiled: Warning (unique_unit_address): /soc/i2c@40003000: duplicate unit-address (also used in node /soc/spi@40003000) nrf52840_pca10056.dts_compiled: Warning (unique_unit_address): /soc/i2c@40004000: duplicate unit-address (also used in node /soc/spi@40004000) -- Cache files will be written to: /root/.cache/zephyr -- The C compiler identification is GNU 6.2.0 -- The CXX compiler identification is GNU 6.2.0 -- The ASM compiler identification is GNU -- Found assembler: /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-gcc -- Performing Test toolchain_is_ok -- Performing Test toolchain_is_ok - Success -- Configuring done CMake Error at ../../CMakeLists.txt:1226 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:offsets> The evaluation of the TARGET_OBJECTS generator expression is only suitable for consumption by CMake. It is not suitable for writing out elsewhere. CMake Error at ../../CMakeLists.txt:1191 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:offsets> The evaluation of the TARGET_OBJECTS generator expression is only suitable for consumption by CMake. It is not suitable for writing out elsewhere. CMake Error at ../../CMakeLists.txt:570 (add_custom_command): Error evaluating generator expression: $<TARGET_OBJECTS:offsets> The evaluation of the TARGET_OBJECTS generator expression is only suitable for consumption by CMake. It is not suitable for writing out elsewhere. CMake Error at ../../CMakeLists.txt:570 (add_custom_command): Error evaluating generator expression: $<TARGET_OBJECTS:offsets> The evaluation of the TARGET_OBJECTS generator expression is only suitable for consumption by CMake. It is not suitable for writing out elsewhere. CMake Error at ../../CMakeLists.txt:570 (add_custom_command): Error evaluating generator expression: $<TARGET_OBJECTS:offsets> The evaluation of the TARGET_OBJECTS generator expression is only suitable for consumption by CMake. It is not suitable for writing out elsewhere. -- Generating done -- Build files have been written to: /home/vikrant/zephyr/samples/hello_world/build Thank You !!
|
|
Looking for help with SAMD2x
Kumar Gala
Guys,
I’m looking to see if someone (or group) can help with maintenance of the Atmel SAMD2x SoC family. We have a few things that need updating (like the watchdog driver). And need someone I can check in w/from time to time if there are questions or we need testing on a board. Let me know if you can help in the short term with converting drivers/watchdog/wdt_sam0.c to use the new watchdog API. [ I also have a question about testing flash support ] thanks - k
|
|
Re: Getting started with ARM GNU Compiler | errors |
#gettingstartedguide
Balasubramanyam
Hi Sebastian, I tried deleting build folder and created again. Compilation successful without any issues. Issue not seen anymore Thanks, Balasubramanyam Rangineni
On Fri, Nov 16, 2018 at 9:23 PM Bøe, Sebastian <Sebastian.Boe@...> wrote: I can't think of any reason why blinky would work, whilst hello_world --
Thanks & Regards, Rangineni Balasubramanyam
|
|
Re: Getting started with ARM GNU Compiler | errors |
#gettingstartedguide
Sebastian Boe
I can't think of any reason why blinky would work, whilst hello_world
would produce that error. Could you try again after deleting the build directories? It is not necessary to add --specs=nosys.specs when the variant is set to gnuarmemb. ________________________________________ From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Balasubramanyam <rangineni.balu@gmail.com> Sent: Friday, November 16, 2018 4:48:20 PM To: marti@foundries.io Cc: devel@lists.zephyrproject.org Subject: Re: [Zephyr-devel] Getting started with ARM GNU Compiler | errors | #gettingstartedguide Hi Marti, I tried compiling zephyr\samples\hello_world\ project. I used camke command to compile cmake -GNinja -DBOARD=nrf52832_mdk .. Failure seen after this command itself. But when I tried compiling blinky project I did not see any issue. On Fri, Nov 16, 2018 at 9:10 PM Marti Bolivar <marti@foundries.io<mailto:marti@foundries.io>> wrote: Hi, Is this an upstream sample project? What command lines did you use for cmake and building the project itself? Thanks, Marti On Thu, Nov 15, 2018 at 9:55 PM <rangineni.balu@gmail.com<mailto:rangineni.balu@gmail.com>> wrote:
-- Thanks & Regards, Rangineni Balasubramanyam
|
|
Re: Getting started with ARM GNU Compiler | errors |
#gettingstartedguide
Balasubramanyam
Hi Marti, I tried compiling zephyr\samples\hello_world\ project. I used camke command to compile cmake -GNinja -DBOARD=nrf52832_mdk .. Failure seen after this command itself. But when I tried compiling blinky project I did not see any issue.
On Fri, Nov 16, 2018 at 9:10 PM Marti Bolivar <marti@...> wrote: Hi, --
Thanks & Regards, Rangineni Balasubramanyam
|
|
Re: Getting started with ARM GNU Compiler | errors |
#gettingstartedguide
Marti Bolivar <marti@...>
Hi,
toggle quoted messageShow quoted text
Is this an upstream sample project? What command lines did you use for cmake and building the project itself? Thanks, Marti
On Thu, Nov 15, 2018 at 9:55 PM <rangineni.balu@gmail.com> wrote:
|
|
Re: can zephyr sdk support macos?
Marti Bolivar <marti@...>
On Fri, Nov 16, 2018 at 12:03 AM Andrei
<andrei.emeltchenko.news@gmail.com> wrote: The Zephyr SDK covers the toolchain, which is not discussed on that page at the moment. The main document has information on toolchain installation: https://docs.zephyrproject.org/latest/getting_started/getting_started.html
|
|
Re: can zephyr sdk support macos?
Andrei
Hi,
On Thu, Nov 15, 2018 at 10:52:55AM -0700, Marti Bolivar wrote: The Zephyr SDK is Linux-only.https://docs.zephyrproject.org/latest/getting_started/installation_mac.html Best regards Andrei Emeltchenko On Thu, Nov 15, 2018 at 6:14 AM cstyle <cstyle.z.zhou@outlook.com> wrote:
|
|
Re: NRF52 Scanning stops without indication
Chettimada, Vinayak Kariappa
Hi Jon,
toggle quoted messageShow quoted text
Could you please share a simple application or an upstream Zephyr sample that can reproduce this memory leak? From the look of it, the controller's rx buffers have been leaked. Is there any chance, any of the threads aborted? (incorrect application code in direct call path of stack's callbacks can crash or stall the stack). Something that can help me debug is the SHA hash of the Zephyr source code, a simple application that will reproduce it and an approximate duration you want me to wait for the issue be reproduced. Regards, Vinayak
-----Original Message-----
From: <devel@lists.zephyrproject.org> on behalf of Jon Pry <jon@stel.life> Date: Thursday, 15 November 2018 at 5:54 PM To: "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org> Subject: [Zephyr-devel] NRF52 Scanning stops without indication Hi, We are running continuous active scan on NRF52 with duplicate filtering disabled. Under some circumstances all scan data stops being generated. This has been difficult to reproduce but is a serious bug for our application. It takes thousands of hours of device run time for us to create and identify this issue. I was able to capture a memory dump of such a device and am trying to examine it for any indication of the problem. I'm looking primarily at _radio state, but if anyone has any pointers I would appreciate it. The zephyr version that create this dump is master branch as of 10/26. (gdb) p 'ctrl.c'::_radio $20 = { hf_clock = 0x20007668 <__device_clock_nrf5_m16src>, entropy = 0x20007680 <__device_entropy_nrf5>, ticks_anchor = 3215498, remainder_anchor = 0, is_k32src_stable = 1 '\001', ticker_id_prepare = 5 '\005', ticker_id_event = 0 '\000', ticker_id_stop = 0 '\000', role = ROLE_NONE, state = STATE_NONE, advertiser = { hdr = { ticks_xtal_to_start = 39, ticks_active_to_start = 0, ticks_preempt_to_start = 0, ticks_slot = 150 }, chan_map_current = 0 '\000', rfu = 0 '\000', is_hdcd = 0 '\000', is_enabled = 1 '\001', phy_p = 1 '\001', chan_map = 7 '\a', filter_policy = 0 '\000', rl_idx = 255 '\377', adv_data = { data = {"`\033\070\r\230X't\002\001\004\021\a\236\312\334$\016\345\251\340\223\363\243\265\001\000@n\000\000\000\000\000\000\000\000\000", "`\033\070\r\230X't\002\001\004\021\a\236\312\334$\016\345\251\340\223\363\243\265\001\000@n\000\000\000\000\000\000\000\000\000"}, first = 0 '\000', last = 0 '\000' }, scan_data = { data = {"D\022\070\r\230X't\v\tStarGateΛ", '\000' <repeats 18 times>, "D\022\070\r\230X't\v\tStarGateΛ", '\000' <repeats 18 times>}, first = 0 '\000', last = 0 '\000' }, conn = 0x20002220 <_radio> }, scanner = { hdr = { ticks_xtal_to_start = 39, ticks_active_to_start = 0, ticks_preempt_to_start = 10, ticks_slot = 5948 }, is_enabled = 1 '\001', state = 0 '\000', chan = 0 '\000', rfu = 0 '\000', phy = 0 '\000', type = 1 '\001', filter_policy = 0 '\000', adv_addr_type = 0 '\000', init_addr_type = 1 '\001', rpa_gen = 1 '\001', rl_idx = 255 '\377', init_addr = "8\r\230X't", adv_addr = "\344\350\016\036\341", <incomplete sequence \364>, ticks_window = 5939, conn_interval = 40, conn_latency = 0, conn_timeout = 400, ticks_conn_slot = 37, conn = 0x0 <z_clock_driver_init>, win_offset_us = 2 }, conn_pool = 0x20002220 <_radio>, conn_free = 0x0 <z_clock_driver_init>, connection_count = 1 '\001', conn_curr = 0x0 <z_clock_driver_init>, packet_counter = 1 '\001', crc_expire = 0 '\000', data_chan_map = "\377\377\377\377\037", data_chan_count = 37 '%', sca = 5 '\005', default_tx_octets = 27, default_tx_time = 328, default_phy_tx = 3, default_phy_rx = 3, pkt_rx_data_pool = 0x200023d8 <_radio+440>, pkt_rx_data_free = 0x0 <z_clock_driver_init>, packet_data_octets_max = 27, packet_rx_data_pool_size = 208, packet_rx_data_size = 52, packet_rx_data_count = 4 '\004', packet_rx = 0x20002374 <_radio+340>, packet_rx_count = 5 '\005', packet_rx_last = 0 '\000', packet_rx_acquire = 2 '\002', link_rx_pool = 0x200024a8 <_radio+648>, link_rx_free = 0x200024d0 <_radio+688>, link_rx_head = 0x200024a8 <_radio+648>, link_rx_tail = 0x200024a8 <_radio+648>, link_rx_data_quota = 2 '\002', pkt_tx_ctrl_pool = 0x200024d8 <_radio+696>, pkt_tx_ctrl_free = 0x200024d8 <_radio+696>, pkt_tx_data_pool = 0x20002520 <_radio+768>, pkt_tx_data_free = 0x20002520 <_radio+768>, packet_tx_data_size = 36, pkt_tx = 0x20002388 <_radio+360>, pkt_release = 0x200023b0 <_radio+400>, packet_tx_count = 5 '\005', packet_tx_first = 1 '\001', packet_tx_last = 1 '\001', packet_release_first = 1 '\001', packet_release_last = 1 '\001', fc_handle = {0, 0, 0}, fc_req = 2 '\002', fc_ack = 2 '\002', fc_ena = 1 '\001', ticks_active_to_start = 0, conn_upd = 0x0 <z_clock_driver_init> } Thanks, Jon Pry
|
|
Getting started with ARM GNU Compiler | errors |
#gettingstartedguide
Balasubramanyam
Hi Team,
I am just getting started with Zephyr and trying to setup development environment. I followed all the steps described to setup ARM GNU GCC toolchain and compilation ENV. After setting up everything required, I got the following error after trying to compile a sample project. " CMake Error at ../../cmake/extensions.cmake:1086 (message): Assertion failed: The toolchain is unable to build a dummy C file. See
CMakeError.log.
Call Stack (most recent call first):
../../CMakeLists.txt:28 (assert)
-- Configuring incomplete, errors occurred!
See also "../zephyr/samples/hello_world/build/CMakeFiles/CMakeOutput.log".
See also "../zephyr/samples/hello_world/build/CMakeFiles/CMakeError.log". "" I went through the log files and it seems build failed at following "" The output was:
1
c:/gnu_arm_embedded/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib\libc.a(lib_a-exit.o): In function `exit':
exit.c:(.text.exit+0x2c): undefined reference to `_exit'
collect2.exe: error: ld returned 1 exit status""
Thanks,Seems ARM compiler issue, after bit of google found out that these options "--specs=nosys.specs" needs to be passed as command line params to run gcc. I am not able to figure out where i can exactly instruct build environment to use these command line options for GCC. I have attached both error and output log. Any help will be appreciated to be able to compile a project successfully. Balasubramanyam Rangineni
|
|
Re: can zephyr sdk support macos?
Marti Bolivar <marti@...>
The Zephyr SDK is Linux-only.
toggle quoted messageShow quoted text
On Thu, Nov 15, 2018 at 6:14 AM cstyle <cstyle.z.zhou@outlook.com> wrote:
|
|
NRF52 Scanning stops without indication
Jon Pry
Hi,
We are running continuous active scan on NRF52 with duplicate filtering disabled. Under some circumstances all scan data stops being generated. This has been difficult to reproduce but is a serious bug for our application. It takes thousands of hours of device run time for us to create and identify this issue. I was able to capture a memory dump of such a device and am trying to examine it for any indication of the problem. I'm looking primarily at _radio state, but if anyone has any pointers I would appreciate it. The zephyr version that create this dump is master branch as of 10/26. (gdb) p 'ctrl.c'::_radio
$20 = {
hf_clock = 0x20007668 <__device_clock_nrf5_m16src>,
entropy = 0x20007680 <__device_entropy_nrf5>,
ticks_anchor = 3215498,
remainder_anchor = 0,
is_k32src_stable = 1 '\001',
ticker_id_prepare = 5 '\005',
ticker_id_event = 0 '\000',
ticker_id_stop = 0 '\000',
role = ROLE_NONE,
state = STATE_NONE,
advertiser = {
hdr = {
ticks_xtal_to_start = 39,
ticks_active_to_start = 0,
ticks_preempt_to_start = 0,
ticks_slot = 150
},
chan_map_current = 0 '\000',
rfu = 0 '\000',
is_hdcd = 0 '\000',
is_enabled = 1 '\001',
phy_p = 1 '\001',
chan_map = 7 '\a',
filter_policy = 0 '\000',
rl_idx = 255 '\377',
adv_data = {
data = {"`\033\070\r\230X't\002\001\004\021\a\236\312\334$\016\345\251\340\223\363\243\265\001\000@n\000\000\000\000\000\000\000\000\000", "`\033\070\r\230X't\002\001\004\021\a\236\312\334$\016\345\251\340\223\363\243\265\001\000@n\000\000\000\000\000\000\000\000\000"},
first = 0 '\000',
last = 0 '\000'
},
scan_data = {
data = {"D\022\070\r\230X't\v\tStarGateΛ", '\000' <repeats 18 times>, "D\022\070\r\230X't\v\tStarGateΛ", '\000' <repeats 18 times>},
first = 0 '\000',
last = 0 '\000'
},
conn = 0x20002220 <_radio>
},
scanner = {
hdr = {
ticks_xtal_to_start = 39,
ticks_active_to_start = 0,
ticks_preempt_to_start = 10,
ticks_slot = 5948
},
is_enabled = 1 '\001',
state = 0 '\000',
chan = 0 '\000',
rfu = 0 '\000',
phy = 0 '\000',
type = 1 '\001',
filter_policy = 0 '\000',
adv_addr_type = 0 '\000',
init_addr_type = 1 '\001',
rpa_gen = 1 '\001',
rl_idx = 255 '\377',
init_addr = "8\r\230X't",
adv_addr = "\344\350\016\036\341", <incomplete sequence \364>,
ticks_window = 5939,
conn_interval = 40,
conn_latency = 0,
conn_timeout = 400,
ticks_conn_slot = 37,
conn = 0x0 <z_clock_driver_init>,
win_offset_us = 2
},
conn_pool = 0x20002220 <_radio>,
conn_free = 0x0 <z_clock_driver_init>,
connection_count = 1 '\001',
conn_curr = 0x0 <z_clock_driver_init>,
packet_counter = 1 '\001',
crc_expire = 0 '\000',
data_chan_map = "\377\377\377\377\037",
data_chan_count = 37 '%',
sca = 5 '\005',
default_tx_octets = 27,
default_tx_time = 328,
default_phy_tx = 3,
default_phy_rx = 3,
pkt_rx_data_pool = 0x200023d8 <_radio+440>,
pkt_rx_data_free = 0x0 <z_clock_driver_init>,
packet_data_octets_max = 27,
packet_rx_data_pool_size = 208,
packet_rx_data_size = 52,
packet_rx_data_count = 4 '\004',
packet_rx = 0x20002374 <_radio+340>,
packet_rx_count = 5 '\005',
packet_rx_last = 0 '\000',
packet_rx_acquire = 2 '\002',
link_rx_pool = 0x200024a8 <_radio+648>,
link_rx_free = 0x200024d0 <_radio+688>,
link_rx_head = 0x200024a8 <_radio+648>,
link_rx_tail = 0x200024a8 <_radio+648>,
link_rx_data_quota = 2 '\002',
pkt_tx_ctrl_pool = 0x200024d8 <_radio+696>,
pkt_tx_ctrl_free = 0x200024d8 <_radio+696>,
pkt_tx_data_pool = 0x20002520 <_radio+768>,
pkt_tx_data_free = 0x20002520 <_radio+768>,
packet_tx_data_size = 36,
pkt_tx = 0x20002388 <_radio+360>,
pkt_release = 0x200023b0 <_radio+400>,
packet_tx_count = 5 '\005',
packet_tx_first = 1 '\001',
packet_tx_last = 1 '\001',
packet_release_first = 1 '\001',
packet_release_last = 1 '\001',
fc_handle = {0, 0, 0},
fc_req = 2 '\002',
fc_ack = 2 '\002',
fc_ena = 1 '\001',
ticks_active_to_start = 0,
conn_upd = 0x0 <z_clock_driver_init>
}
Thanks, Jon Pry
|
|
Re: Proper way to handle GPIO IRQ enablement
Lincoln Simmons
Nice, thanks Tomasz!
toggle quoted messageShow quoted text
It might be a few days before ill be able to test it, but I'll get back to you. -Lincoln
On Thu, Nov 15, 2018, 6:11 AM Tomasz Bursztyka <tomasz.bursztyka@...> wrote: Hi Lincoln,
|
|
can zephyr sdk support macos?
cstyle
can zephyr sdk support macos?
|
|
Re: Proper way to handle GPIO IRQ enablement
Tomasz Bursztyka
Hi Lincoln,
Can you try https://github.com/zephyrproject-rtos/zephyr/pull/11396 (1st commit) That should solve your issue. Instead of returning -EALREADY if already installed, I just return 0. Tomasz
|
|
Re: Proper way to handle GPIO IRQ enablement
Tomasz Bursztyka
Hi,
Knowing this, I have a couple of questions:Actually you found a bug. It's not up to the user to know that the cb is already installed (even though, logically it does not make sense to add the same cb many times), in other words: gpio should not blindly install an already installed cb. I'll open an issue. I think it should check the status of the node, if already set up, it will try to find it and return an error: -EALREADY if found, or -EINVAL as it might have been inserted into another controller's list and we should not touch it. Once my IRQ pin is configured and my callback added, it looks like II think my fix proposal above should clarify that. If it returns 0 or -EALREADY, all will be fine. Any recommendation or comments are appreciated! Or perhaps I'm offNo that was a good catch! Thanks, Tomasz
|
|
Proper way to handle GPIO IRQ enablement
Lincoln Simmons
Hi, I'm attempting to use the Zephyr GPIO API for the first time. It seems full featured, but I think this has caused me some confusion. I was debugging my application and found that I got stuck in an infinite loop in _gpio_fire_callbacks(). (For what it's worth, I'm using an nRF52832 chip, so this was called from gpio_nrfx.c)
I am trying to interface with an IRQ pin on a peripheral, so I wrote a couple of enable/disable functions for my driver that look similar to this: https://gist.github.com/Lncn/49174feb32c2d96dc4e82924b6163c8f This code was ported from another platform & RTOS where I simply reconfigured the pin entirely when enabling/disabling the device IRQ. In hindsight this may have been heavy handed. I was unknowingly calling my "x_enable_irq" function twice in the process of initializing my application and I think this caused my infinite loop. It appears you cannot call gpio_add_callback twice with the same callback struct, as sys_slist_prepend() will create a circular linked list if the struct gpio_callback reference is already in the list. Knowing this, I have a couple of questions:
Thanks, Lincoln Simmons lincolnsimmons@...
|
|
Re: #nrf52480 Calling a function not compiled as part of Zephyr from within Zephyr
#nrf52480
lairdjm
Hi,
I sent a reply using the reply function on the message board site but it seems to have been a private message not a general reply. I fixed this off-by-one issue as I was calling at the function minus one by mistake, I've changed it
and can confirm it works fine.
Thanks,
Jamie
From: Marti Bolivar <marti@...>
Sent: Wednesday, November 14, 2018 4:56:57 PM To: Jamie Mccrae Cc: devel@... Subject: Re: [Zephyr-devel] #nrf52480 Calling a function not compiled as part of Zephyr from within Zephyr Hi Jamie,
You might want to take a look at how MCUboot invokes the reset vector in an NVIC table after having found the image: https://github.com/runtimeco/mcuboot/blob/master/boot/zephyr/main.c#L53 As you can see, you can cast the address to a function of the appropriate type and it does work on nRF52840. If it's an MPU issue in your environment, the kernel developers who work on userspace would probably benefit from seeing any relevant Kconfig options in your build/zephyr/.config file. HTH, Marti On Mon, Nov 12, 2018 at 6:24 AM <jamie.mccrae@...> wrote: > > Hi, > > I am attempting to run an external function on an nRF52840 which is present on the module's flash at a known address but is not part of the Zephyr environment (consider it external). The function doesn't do much except update some pointers which are provided to it, however when attempting to run the function from Zephyr, it generates a usage fault error, "Illegal use of the EPSR". I assume this is caused by a kernel security feature, so how would one go about calling an external function generated in a different build environment from Zephyr without it causing a fault? >
|
|
Re: Confirm your gabriel.wang@arm.com email address
Hi Gabriel, Confirming that you are subscribed to the devel mail list, so you should have no issues sending, or receiving, messages - Thanks! Brett
On Wed, Nov 14, 2018 at 9:06 AM, Gabriel Wang <gabriel.wang@...> wrote:
--
|
|