Visual Code issues

[Evluma]

While using Visual Code I have noticed that:

• First compile always generates errors, which is fine. The error notifications are persistent even after they have been fixed. The only thing that clears these errors is exiting Visual Code and restarting the program.
• Adding a second build within the same project consistently cause all builds to fail with missing file errors
• While creating custom applications, such as the Hello World App from the DevAcademy, the printk function does not output to any terminal. Also the DevAcademy still references the NRF Terminal, which has been removed
• Many of the sample applications or examples do not copy over correctly into target directories with several files having hard coded directory paths which are not valid due to the path move

These are annoyances and can be worked around but having to close and reopen VC to clear errors is troublesome and not being able to reliably create multiple builds in the same project without bricking the original build is limiting the versatility of the system.

[Evluma]

Ignore printk issue, this was solved with an overlay change

[runsiv]

Hi Warren

Which version of NCS and the toolchain are you using? This does not sound like the normal behavior so I hope you can give me a bit more information regarding the issue. 

Could you also show the errors you get and name some of the samples you have seen issues with so I can see if I can reproduce them on my end?

I would also suggest that you open the nRF Connect terminal in VScode and run "west update"

Regarding the errors, is it a error that stops the compiling of the application or is it found in the "Problems" tab in the terminal view in VScode?

Regards

Runar

[runsiv]

Hi

I had a little chat with Johnny and he mentioned a couple of samples. I tested the samples myself and they did not build out of the box outside the folder which they are located in due a relative file path in the overlay. I have reported the issue internally as this is not how it should be. 

Regards

Runar

[Evluma]

Hey thanks for the responses.  I am working in 2.6.0 currently but the issues I have seen are in several of the older versions as well. The removal of the error messages seems to be better in 2.6.0 its just delayed, but in 2.6.0 delayed less than the older SDK versions. Perhaps this is a change in VC not the SDK. 

As to the adding a second build to an existing build, to recreate:

- use (as an example) tx_rx_non_blocking (TWI sample)

- create a build for the nrf52dk_nrf52832

- fix path error, get clean build.

- add a second build, same as previous, note that there is no need to fix any files as all files will be common

- hit the build EDIT, and you get the following 

NOTE: I am using build and build_1

-------------------------------------------------------------------------- <begin>

* Executing task: nRF Connect: Generate config nrf52840dk_nrf52840 for c:\mySamples\tx_rx_non_blocking_3

Building tx_rx_non_blocking_3...

[2/142] Generating include/generated/version.h
-- Zephyr version: 3.5.99 (C:/ncs/v2.6.0/zephyr), build: v3.5.99-ncs1
[41/142] Building C object CMakeFiles/app.dir/main.c.obj
FAILED: CMakeFiles/app.dir/main.c.obj
C:\ncs\toolchains\cf2149caf2\opt\zephyr-sdk\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DKERNEL -DNRF52840_XXAA -DPICOLIBC_LONG_LONG_PRINTF_SCANF -D_FORTIFY_SOURCE=1 -D_POSIX_C_SOURCE=200809 -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR__=1 -IC:/mySamples/tx_rx_non_blocking_3/common -IC:/ncs/v2.6.0/zephyr/include -IC:/mySamples/tx_rx_non_blocking_3/build_1/zephyr/include/generated -IC:/ncs/v2.6.0/zephyr/soc/arm/nordic_nrf/nrf52 -IC:/ncs/v2.6.0/zephyr/soc/common/nordic_nrf/. -IC:/ncs/v2.6.0/zephyr/soc/arm/nordic_nrf/common/. -IC:/ncs/v2.6.0/nrf/include -IC:/ncs/v2.6.0/nrf/tests/include -IC:/ncs/v2.6.0/modules/hal/cmsis/CMSIS/Core/Include -IC:/ncs/v2.6.0/zephyr/modules/cmsis/. -IC:/ncs/v2.6.0/modules/hal/nordic/nrfx -IC:/ncs/v2.6.0/modules/hal/nordic/nrfx/drivers/include -IC:/ncs/v2.6.0/modules/hal/nordic/nrfx/mdk -IC:/ncs/v2.6.0/zephyr/modules/hal_nordic/nrfx/. -IC:/ncs/v2.6.0/modules/debug/segger/SEGGER -IC:/ncs/v2.6.0/modules/debug/segger/Config -IC:/ncs/v2.6.0/modules/debug/segger/SEGGER/DebugMon/include -isystem C:/ncs/v2.6.0/zephyr/lib/libc/common/include -isystem C:/ncs/v2.6.0/nrfxlib/crypto/nrf_cc310_platform/include -fno-strict-aliasing -Og -imacros C:/mySamples/tx_rx_non_blocking_3/build_1/zephyr/include/generated/autoconf.h -fno-printf-return-value -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m4 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft --sysroot=C:/ncs/toolchains/cf2149caf2/opt/zephyr-sdk/arm-zephyr-eabi/arm-zephyr-eabi -imacros C:/ncs/v2.6.0/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -ftls-model=local-exec -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=C:/mySamples/tx_rx_non_blocking_3=CMAKE_SOURCE_DIR -fmacro-prefix-map=C:/ncs/v2.6.0/zephyr=ZEPHYR_BASE -fmacro-prefix-map=C:/ncs/v2.6.0=WEST_TOPDIR -ffunction-sections -fdata-sections --specs=picolibc.specs -std=c99 -MD -MT CMakeFiles/app.dir/main.c.obj -MF CMakeFiles\app.dir\main.c.obj.d -o CMakeFiles/app.dir/main.c.obj -c C:/mySamples/tx_rx_non_blocking_3/main.c
In file included from C:/ncs/v2.6.0/modules/hal/nordic/nrfx/nrfx.h:38,
from c:\ncs\v2.6.0\zephyr\soc\arm\nordic_nrf\common\soc_nrf_common.h:14,
from C:/ncs/v2.6.0/zephyr/soc/arm/nordic_nrf/nrf52/soc.h:14,
from c:\ncs\v2.6.0\zephyr\modules\cmsis\cmsis_core_m.h:24,
from c:\ncs\v2.6.0\zephyr\modules\cmsis\cmsis_core.h:10,
from C:/ncs/v2.6.0/zephyr/include/zephyr/arch/arm/mpu/arm_mpu_v7m.h:10,
from C:/ncs/v2.6.0/zephyr/include/zephyr/arch/arm/mpu/arm_mpu.h:14,
from C:/ncs/v2.6.0/zephyr/include/zephyr/arch/arm/arch.h:268,
from C:/ncs/v2.6.0/zephyr/include/zephyr/arch/cpu.h:19,
from C:/ncs/v2.6.0/zephyr/include/zephyr/kernel_includes.h:37,
from C:/ncs/v2.6.0/zephyr/include/zephyr/kernel.h:17,
from C:/ncs/v2.6.0/zephyr/include/zephyr/logging/log_ctrl.h:9,
from C:/mySamples/tx_rx_non_blocking_3/common/nrfx_example.h:38,
from C:/mySamples/tx_rx_non_blocking_3/main.c:34:
C:/ncs/v2.6.0/modules/hal/nordic/nrfx/drivers/include/nrfx_twis.h:71:35: error: 'NRFX_TWIS1_INST_IDX' undeclared here (not in a function); did you mean 'NRFX_TWIS_INSTANCE'?
71 | .drv_inst_idx = NRFX_CONCAT_3(NRFX_TWIS, id, _INST_IDX), \
| ^~~~~~~~~
C:/ncs/v2.6.0/modules/hal/nordic/nrfx/drivers/nrfx_common.h:189:36: note: in definition of macro 'NRFX_CONCAT_3_'
189 | #define NRFX_CONCAT_3_(p1, p2, p3) p1 ## p2 ## p3
| ^~
C:/ncs/v2.6.0/modules/hal/nordic/nrfx/drivers/include/nrfx_twis.h:71:21: note: in expansion of macro 'NRFX_CONCAT_3'
71 | .drv_inst_idx = NRFX_CONCAT_3(NRFX_TWIS, id, _INST_IDX), \
| ^~~~~~~~~~~~~
C:/mySamples/tx_rx_non_blocking_3/main.c:88:32: note: in expansion of macro 'NRFX_TWIS_INSTANCE'
88 | static nrfx_twis_t twis_inst = NRFX_TWIS_INSTANCE(TWIS_INST_IDX);
| ^~~~~~~~~~~~~~~~~~
C:/ncs/v2.6.0/modules/hal/nordic/nrfx/drivers/include/nrfx_twim.h:63:35: error: 'NRFX_TWIM0_INST_IDX' undeclared here (not in a function); did you mean 'NRF_TWIM_INST_GET'?
63 | .drv_inst_idx = NRFX_CONCAT_3(NRFX_TWIM, id, _INST_IDX), \
| ^~~~~~~~~
C:/ncs/v2.6.0/modules/hal/nordic/nrfx/drivers/nrfx_common.h:189:36: note: in definition of macro 'NRFX_CONCAT_3_'
189 | #define NRFX_CONCAT_3_(p1, p2, p3) p1 ## p2 ## p3
| ^~
C:/ncs/v2.6.0/modules/hal/nordic/nrfx/drivers/include/nrfx_twim.h:63:21: note: in expansion of macro 'NRFX_CONCAT_3'
63 | .drv_inst_idx = NRFX_CONCAT_3(NRFX_TWIM, id, _INST_IDX), \
| ^~~~~~~~~~~~~
C:/mySamples/tx_rx_non_blocking_3/main.c:91:32: note: in expansion of macro 'NRFX_TWIM_INSTANCE'
91 | static nrfx_twim_t twim_inst = NRFX_TWIM_INSTANCE(TWIM_INST_IDX);
| ^~~~~~~~~~~~~~~~~~
In file included from C:/ncs/v2.6.0/zephyr/include/zephyr/arch/arm/irq.h:19,
from C:/ncs/v2.6.0/zephyr/include/zephyr/arch/arm/arch.h:27:
C:/mySamples/tx_rx_non_blocking_3/main.c: In function 'main':
C:/ncs/v2.6.0/modules/hal/nordic/nrfx/drivers/include/nrfx_twim.h:397:55: error: 'nrfx_twim_0_irq_handler' undeclared (first use in this function); did you mean 'nrfx_twim_evt_handler_t'?
397 | #define NRFX_TWIM_INST_HANDLER_GET(idx) NRFX_CONCAT_3(nrfx_twim_, idx, _irq_handler)
| ^~~~~~~~~~
C:/ncs/v2.6.0/zephyr/include/zephyr/sw_isr_table.h:201:47: note: in definition of macro 'Z_ISR_DECLARE'
201 | {irq, flags, (void *)&func, (const void *)param}
| ^~~~

....

there was more but I could not past it all for some reason

-------------------------------------------------------------------------- <end>

This has been pretty consistent with the samples

Cheers

[runsiv]

Hi sorry for the delay. 

Thanks for the clarification. There is some background talk going around at our end regarding the samples. 

The response I have gotten on my end is that they should be viewed the following way: 

"

These samples are available to show how nrfx can be used instead of Zephyr drivers (or shims). They are designed to build using different frameworks including Zephyr and bare metal, which is why this build configuration in Zephyr has its flaws.

As nrfx is a set of drivers which are os-agnostic and focusing on individual peripherals. Therefor any Zephyr-specific frameworks such as pin control, power management, cache, will never be a part of nrfx. Given this, nrfx is not (and not ment) to be a direct replacement for Zephyr drivers.

Low Level is on the course of delivering features and functions within Zephyr APIs so hopefully nrfx will once become a hacker’s tool and internal low-level drivers in Low Level.

Please try use Zephyr drivers first, then nrfx, and unfortunately you will need to manually trigger all Zephyr frameworks such as pin control, power management, cache and any other framework that may be needed." 

Regards

Runar