FAQ

Why I can’t download application?

Case 1: Remote communication error. Target disconnected.: Success.

Nuclei OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev-00014-g0eae03214 (2019-12-12-07:43)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Remote communication error.  Target disconnected.: Success.
"monitor" command not supported by this target.
"monitor" command not supported by this target.
"monitor" command not supported by this target.
You can't do that when your target is ``exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.

Please check whether your driver is installed successfully via replace target upload to run_openocd as the board user manual described, especially, for RV-STAR and Nuclei Demo SoC Evaluation boards, For windows, you need to download the HummingBird Debugger Windows Driver from https://nucleisys.com/developboard.php, and install it.

If still not working, please check whether your JTAG connection is good or your CPU core is OK.

Note

The USB driver might lost when you re-plug the USB port, you might need to reinstall the driver.

Case 2: bfd requires flen 4, but target has flen 0

bfd requires flen 4, but target has flen 0
"monitor" command not supported by this target.
"monitor" command not supported by this target.
"monitor" command not supported by this target.
You can't do that when your target is `exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.

bfd is abbreviation for Binary File Descriptor.

This is caused by the target core flen is 0, which means it didn’t have float point unit in it, but your program is compiled using flen = 4, single point float unit used, which is incompatible, similar cases such as bfd requires flen 8, but target has flen 4

Just change your CORE to proper core settings and will solve this issue.

For example, if you compile your core with CORE=n307, just change it to CORE=n305.

Case 3: bfd requires xlen 8, but target has xlen 4

bfd requires xlen 8, but target has xlen 4
"monitor" command not supported by this target.
"monitor" command not supported by this target.
"monitor" command not supported by this target.
You can't do that when your target is ``exec'
"monitor" command not supported by this target.
"monitor" command not supported by this target.

This issue is caused by the program is a riscv 64 program, but the core is a riscv 32 core, so just change your program to be compiled using a riscv 32 compile option.

For example, if you compile your core with CORE=ux600, just change it to CORE=n305.

How to select correct FDTI debugger?

From Nuclei SDK release 0.2.9, the openocd configuration file doesn’t contain ftdi_device_desc line by default, so if there are more than one FTDI debuggers which has the same VID/PID(0x0403/0x6010) as Nuclei Debugger Kit use, then you might need to add extra ftdi device_desc line in the openocd configuration file to describe the FTDI device description.

Or you can add extra adapter serial your_serial_no for your debugger, you can check its serial number via windows FT_PROG tool.

NOTE: for windows, you need to add an extra A to the serial number, eg. your serial number is FT6S9RD6, then this extra openocd config line should be adapter serial "FT6S9RD6A" for windows.

For Nuclei FPGA Evaluation Board, you can check the openocd configuration file in SoC/evalsoc/Board/nuclei_fpga_eval/openocd_evalsoc.cfg.
For Nuclei RVSTAR Board, you can check the openocd configuration file in SoC/gd32vf103/Board/gd32vf103v_rvstar/openocd_gd32vf103.cfg.

Why I can’t download application in Linux?

Please check that whether you have followed the debugger kit manual to setup the USB JTAG drivers correctly. The windows steps and linux steps are different, please take care.

Why the provided application is not running correctly in my Nuclei FPGA Evaluation Board?

Please check the following items:

Did you program the correct Nuclei Evaluation FPGA bitstream?
Did you re-power the board, when you just programmed the board with FPGA bitstream?
Did you choose the right CORE as the Nuclei Evaluation FPGA bitstream present?
If your application is RTOS demos, did you run in flashxip mode, if yes, it is expected due to flash speed is really slow, you’d better try ilm or flash mode.
If still not working, you might need to check whether the FPGA bitstream is correct or not?

Why ECLIC handler can’t be installed using ECLIC_SetVector?

If you are running in FlashXIP download mode, it is expected, since the vector table is placed in Flash area which can’t be changed during running time.

You can only use this ECLIC_SetVector API when your vector table is placed in RAM which can be changed during running time, so if you want to write portable application, we recommended you to use exactly the eclic handler names defined in startup_<device>.S.

Access to github.com is slow, any workaround?

Access speed to github.com sometimes is slow and not stable, but if you want to clone source code, you can also switch to use our mirror site maintained in gitee.com.

This mirror will sync changes from github to gitee every 6 hours, that is 4 times a day.

You just need to replace the github to gitee when you clone any repo in Nuclei-Software or riscv-mcu.

For example, if you want to clone nuclei-sdk using command git clone https://github.com/Nuclei-Software/nuclei-sdk, then you can achieve it by command git clone https://gitee.com/Nuclei-Software/nuclei-sdk

`.text’ will not fit in region `ilm’ or `.bss’ will not fit in region `ram’

If you met similar message as below when build an application:

xxx/bin/ld: cifar10.elf section `.text' will not fit in region `ilm'
xxx/bin/ld: cifar10.elf section `.bss' will not fit in region `ram'
xxx/bin/ld: section .stack VMA [000000009000f800,000000009000ffff] overlaps section .bss VMA [00000000900097c0,00000000900144eb]
xxx/bin/ld: region `ilm' overflowed by 43832 bytes
xxx/bin/ld: region `ram' overflowed by 0 bytes

It is caused by the program is too big, our default link script is 64K ILM, 64K DLM, 4M SPIFlash for Nuclei Demo/Eval SoC.

If your core has bigger ILM or DLM, you can change related linker script file according to your choice.

For example, if you want to change linker script for evalsoc on nuclei_fpga_eval ilm download mode: ILM to 512K, DLM to 256K, then you can change link script file SoC/evalsoc/Board/nuclei_fpga_eval/Source/GCC/gcc_evalsoc_ilm.ld as below:

diff --git a/SoC/evalsoc/Board/nuclei_fpga_eval/Source/GCC/gcc_evalsoc_ilm.ld b/SoC/evalsoc/Board/nuclei_fpga_eval/Source/GCC/gcc_evalsoc_ilm.ld
index 1ac5b90..08451b3 100644
--- a/SoC/evalsoc/Board/nuclei_fpga_eval/Source/GCC/gcc_evalsoc_ilm.ld
+++ b/SoC/evalsoc/Board/nuclei_fpga_eval/Source/GCC/gcc_evalsoc_ilm.ld
@@ -28,8 +28,8 @@ ENTRY( _start )
 MEMORY
 {

-  ilm (rxa!w) : ORIGIN = 0x80000000, LENGTH = 64K
-  ram (wxa!r) : ORIGIN = 0x90000000, LENGTH = 64K
+  ilm (rxa!w) : ORIGIN = 0x80000000, LENGTH = 512K
+  ram (wxa!r) : ORIGIN = 0x90000000, LENGTH = 256K
 }

cc1: error: unknown cpu ‘nuclei-300-series’ for ‘-mtune’

This mtune option is introduced in Nuclei SDK 0.3.5, used to select optimized gcc pipeline model for Nuclei RISC-V Core series such as 200/300/600/900 series, and this feature required Nuclei GNU Toolchain 2022.01, please upgrade to this version or later ones.

undefined reference to __errno when using libncrt library

When you are using libncrt library, and linked with -lm, you may face below issues

/home/share/devtools/toolchain/nuclei_gnu/linux64/newlibc/2023.10.14/gcc/bin/../lib/gcc/riscv64-unknown-elf/13.1.1/../../../../riscv64-unknown-elf/bin/ld: /home/share/devtools/toolchain/nuclei_gnu/linux64/newlibc/2023.10.14/gcc/bin/../lib/gcc/riscv64-unknown-elf/13.1.1/../../../../riscv64-unknown-elf/lib/rv32imafdc/ilp32d/libm.a(libm_a-w_exp.o): in function `.L1':
w_exp.c:(.text.exp+0x4a): undefined reference to `__errno'
/home/share/devtools/toolchain/nuclei_gnu/linux64/newlibc/2023.10.14/gcc/bin/../lib/gcc/riscv64-unknown-elf/13.1.1/../../../../riscv64-unknown-elf/bin/ld: /home/share/devtools/toolchain/nuclei_gnu/linux64/newlibc/2023.10.14/gcc/bin/../lib/gcc/riscv64-unknown-elf/13.1.1/../../../../riscv64-unknown-elf/lib/rv32imafdc/ilp32d/libm.a(libm_a-w_exp.o): in function `.L0 ':
w_exp.c:(.text.exp+0x6e): undefined reference to `__errno'
/home/share/devtools/toolchain/nuclei_gnu/linux64/newlibc/2023.10.14/gcc/bin/../lib/gcc/riscv64-unknown-elf/13.1.1/../../../../riscv64-unknown-elf/bin/ld: /home/share/devtools/toolchain/nuclei_gnu/linux64/newlibc/2023.10.14/gcc/bin/../lib/gcc/riscv64-unknown-elf/13.1.1/../../../../riscv64-unknown-elf/lib/rv32imafdc/ilp32d/libm.a(libm_a-w_log.o): in function `log':
w_log.c:(.text.log+0x28): undefined reference to `__errno'
/home/share/devtools/toolchain/nuclei_gnu/linux64/newlibc/2023.10.14/gcc/bin/../lib/gcc/riscv64-unknown-elf/13.1.1/../../../../riscv64-unknown-elf/bin/ld: w_log.c:(.text.log+0x46): undefined reference to `__errno'
/home/share/devtools/toolchain/nuclei_gnu/linux64/newlibc/2023.10.14/gcc/bin/../lib/gcc/riscv64-unknown-elf/13.1.1/../../../../riscv64-unknown-elf/bin/ld: /home/share/devtools/toolchain/nuclei_gnu/linux64/newlibc/2023.10.14/gcc/bin/../lib/gcc/riscv64-unknown-elf/13.1.1/../../../../riscv64-unknown-elf/lib/rv32imafdc/ilp32d/libm.a(libm_a-math_err.o): in function `with_errno':
math_err.c:(.text.with_errno+0x12): undefined reference to `__errno'
collect2: error: ld returned 1 exit status

You can fix it by not link -lm library, since libncrt library already provided math library feature, so no need to link this math library.

undefined reference to fclose/sprintf similar API provided in system libraries

From 0.5.0 release, we no longer use --specs= option to select library we want to use, and we also passed -nodefaultlibs options to not use standard system libraries, this changes are made to support both gcc and clang toolchain, so in Nuclei SDK build system, we control the needed system libraries to be linked as required by STDCLIB make variable, for details, please check Build/toolchain/*.mk makefiles, and also we use linker’s group libraries feature --start-group archives --end-group to repeatly search undefined reference in the group libraries, but this feature is not enabled in Eclipse CDT based IDE like Nuclei Studio, which undefined reference is searched in the order of library specified on the command line, so you may meet issue like undefined fclose reference even you linked newlib nano c library -lc_nano if the library order is not good, so to fix this issue, you may need to place the library in a good order and need to repeatly link it, such as -lgcc -lc_nano -lm -lsemihost -lgcov -lgcc -lc_nano, and also we have opened an issue to track it, see https://github.com/eclipse-embed-cdt/eclipse-plugins/issues/592

fatal error: rvintrin.h: No such file or directory

If you are using Nuclei Toolchain 2023.10, rvintrin.h no longer exist for B extension, please don’t include this header file. If you want to use an intrinsic API for B extension, you need to write using c asm intrinsic.

riscv-nuclei-elf-gcc: not found when using Nuclei Studio 2023.10

``riscv-nuclei-elf-gcc``(gcc10) has changed to ``riscv64-unknown-elf-gcc``(gcc13) since Nuclei Studio 2023.10 or Nuclei RISC-V Toolchain 2023.10, so if you are using older toolchain created npk package or ide project, you may face this build fail issue, you can follow the user guide of Nuclei Studio 2023.10 to fix this issue, see chapter 8.