Maybe we can have a VSCode plugin for nuclei sdk in future, which provide the following features:

• Automatically download or use existing Nuclei SDK source code base
• Create or use existing nuclei-sdk project as templates
• Create project wizard support choosen of SoC, Board, Core, Download
• Support build and debug application directly in VSCode using Makefile build system

Currently we have platformio-nuclei which also provide Nuclei SDK intergation in VSCode, but maybe there will be a good try to have a native plugin to directly use Nuclei SDK build system.

I followed nuclei_sdk Manual on Linux with longan nano GD3VF103CBT6.

Building example ./application/baremetal/helloworld according to the manual is OK. Then I uploaded with sipeed-rv-debugger-lite by make SOC=gd32vf103 BOARD=gd32vf103c_longan_nano upload:

Download and run helloworld.elf
riscv-nuclei-elf-gdb helloworld.elf -ex "set remotetimeout 240" \
-ex "target remote | openocd  -c \"; gdb_port pipe; log_output openocd.log\" -f ../../../SoC/gd32vf103/Board/gd32vf103c_longan_nano/openocd_gd32vf103.cfg" \
--batch -ex "thread apply all monitor reset halt" -ex "thread apply all set \$pc=_start" -ex "thread 1" -ex "load" -ex "monitor resume" -ex "quit"
Open On-Chip Debugger 0.11.0+dev-01897-gc8fc2a168 (2022-04-01-08:40)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
_start0800 () at ../../../SoC/gd32vf103/Common/Source/GCC/startup_gd32vf103.S:372
372         j 1b

Thread 1 (Remote target):
JTAG tap: riscv.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing) Inc), part: 0x9000, ver: 0x7)

Thread 1 (Remote target):
[Switching to thread 1 (Remote target)]
#0  _start () at ../../../SoC/gd32vf103/Common/Source/GCC/startup_gd32vf103.S:214
214         csrc CSR_MSTATUS, MSTATUS_MIE
Loading section .init, size 0x2f4 lma 0x8000000
Loading section .text, size 0x254c lma 0x8000300
Loading section .rodata, size 0x490 lma 0x800284c
Loading section .data, size 0x6c lma 0x8002cdc
Start address 0x08000180, load size 11580
Transfer rate: 2 KB/sec, 2895 bytes/write.
A debugging session is active.

        Inferior 1 [Remote target] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
[Inferior 1 (Remote target) detached]

However, the serial output is wired (115200 8N1):

Nu, *
lmY'R &22	3'&4S
DloXjdY'21S
A
CAU2q]Yk148MS J5
*t bMI 00N1j
Sj RIMP
! lol2o[rcRRcYK
CHYWK  eZ%Sooj
!&HY Kd2mrlYZ%SCKocY!CC lorl2o[rc RRVcYrHCH ol2o[rcRRooj
HYWK  ei%SCKooj
!HY Kd2mrlYZ%MCKocYrH
7'BlWKd m leZ%MCKcYK
C!HeWK  eZ%Sooj
 HYWK mrclY%SCKoorH
1HeWKd  eZ%Sooj
 lorl2mrc RRVcYrHCH(:BlrFN], j5VocY!CC:Blll2o[rc j5V %ceK
C: lorl2o[rc RRVcYrHCH(:BlrFN], j5VocY!CC:Blll2o[rclY%Sooj
: lorl2o[rcRRVcYrHCH1 HY Kd2mrlYZ%SCKocY!CC:Blll2o[rclY%Sooj

I tried different baudrate(9600...) but none of it was right.

Besides, multiple reset will get different results.

I noticed that some headers use the register keyword, e.g.:

AFAICS, those register keywords are superfluous because the following inline assembler directives specify the register-constraint for those variables.

However, OTOH, the asm register constraint can't be left out because the C register keyword is just a hint (in contrast to the GCC local register variable extension which is only supposed to be used if constraints aren't sufficient).

So I suggest to simply remove those register keywords.

Background: The register keyword was deprecated in C++ 17 and hence GCC warns about this when compiling with C++17 features enabled, even when wrapping the gd32vf103 headers in extern "C" { }.

As a workaround I #define register before including and gd32vf103 headers and so far I don't see any issues.

At least for now, one can also compile with -Wno-register.

If you want to take a try with gcc13 for nuclei sdk, you need to download our prebuilt still in development gcc13/clang17 toolchain from https://drive.weixin.qq.com/s?k=ABcAKgdSAFcdQ1noOT, and use a develop branch of nuclei sdk https://github.com/Nuclei-Software/nuclei-sdk/tree/develop.

From 2023.10.9, now develop branch is changing to use gcc13, and merged all the changes from feature/llvm branch, please switch to use develop branch.

Latest qemu for this branch can be found here: https://drive.weixin.qq.com/s?k=ABcAKgdSAFcWD95meC

About how to use this toolchain, please click(In Chinese) https://doc.weixin.qq.com/doc/w3_ASUAMQZqALwUNtgZUvFTH2hR2F7KD?scode=ABcAKgdSAFc1u2vvWl

Download the toolchain, and export it to system PATH, and just try it.

If you want to try nuclei llvm toolchain, just pass TOOLCHAIN=nuclei_llvm when run make command.

$ riscv64-unknown-elf-gcc --version
riscv64-unknown-elf-gcc (gfc04c1213) 13.1.1 20230713
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cd application/baremetal/benchmark/coremark
$ make TOOLCHAIN=nuclei_llvm clean all
Clean all build objects
Current Configuration: TOOLCHAIN=nuclei_llvm RISCV_ARCH=rv32imafdc RISCV_ABI=ilp32d RISCV_TUNE=nuclei-300-series RISCV_CMODEL=medlow SOC=evalsoc BOARD=nuclei_fpga_eval CORE=n307fd ARCH_EXT= DOWNLOAD=ilm STDCLIB=newlib_small SMP= BOOT_HARTID=0
Compiling  :  ../../../../SoC/evalsoc/Common/Source/evalsoc_common.c
Compiling  :  ../../../../SoC/evalsoc/Common/Source/system_evalsoc.c
... ...
Compiling  :  core_list_join.c
Compiling  :  core_main.c
Compiling  :  core_matrix.c
Compiling  :  core_portme.c
Compiling  :  core_state.c
Compiling  :  core_util.c
Linking    :  coremark.elf
   text    data     bss     dec     hex filename
  22836    4072    4812   31720    7be8 coremark.elf

If you want to test gnu toolchain support Zc and Xxlcz, you can try it like this:

nuclei llvm not yet support Zc

cd application/baremetal/benchmark/coremark
# default TOOLCHAIN is nuclei_gnu, no need to pass TOOLCHAIN=nuclei_gnu
## Test cpu arch rv32imafc, which means n300 with single float point, and C extension
make CORE=n300f ARCH_EXT=_zca_zcb_zcf_zcmp_zcmt clean
make CORE=n300f ARCH_EXT=_zca_zcb_zcf_zcmp_zcmt all

## Test cpu arch rv32imaf_zca_zcb_zcf_zcmp_zcmt, which means n300 with single float point, and Zc extension
make CORE=n300f ARCH_EXT=_zca_zcb_zcf_zcmp_zcmt clean
make CORE=n300f ARCH_EXT=_zca_zcb_zcf_zcmp_zcmt all

## Test cpu arch rv32imaf_zca_zcb_zcf_zcmp_zcmt_xxlcz, which means n300 with single float point, and Zc extension, and Xxlcz extension
make CORE=n300f ARCH_EXT=_zca_zcb_zcf_zcmp_zcmt_xxlcz clean
make CORE=n300f ARCH_EXT=_zca_zcb_zcf_zcmp_zcmt_xxlcz all

You can also switch different c library by using https://doc.nucleisys.com/nuclei_sdk/develop/buildsystem.html#develop-buildsystem-var-stdclib

Feature: Add CI support for Nuclei SDK

• Add CI support for build Nuclei SDK in windows and Linux
• Tasks need to do:
  • CI choice: https://circleci.com/, github actions, or travis ci and appveyor
  • Build application in Windows and Linux
  • Build application for hbird and gd32vf103 soc and its board

Feature: Add documentation for Nuclei SDK

Tasks need to be done:

• Add documentation structure using Sphinx and reStructuredText
• Document about Nuclei SDK source code structure and NMSIS
• Document about Build system of Nuclei SDK
• Document about Nuclei SDK supported Board
  - Must describe the board's necessary information, so software developer can easily use this board without looking into the hardware manual too much
  - Must contain nessary steps about how to use Nuclei SDK on this board
• Document about the applications and how to run
• Document about how to add a new application
• Document about how to add new BSP support in Nuclei SDK
• Document about contributing guide

When debug in Nuclei Studio, met the the following issue, how to solve this issue?

Hi Huaqi,

Does Nuclei have any plan of support FreeRTOS? or supported already?
Thanks a lot.

B.R
Fang Yuan

The GD32CVF103 User Manual (1.3) specifies the RTC clock calibration value (RCCV) as:

RTC clock calibration value The value indicates how many clock pulses are ignored or added every 2^20 RTC clock pulses.

(Section 4.4.2, page 59, emphasis mine)

After implementing a calibration procedure I don't think that the second (emphasized) part is true. That means it looks like the RCCV can only be used to ignore clock pulses.

(In which case, when having a clock that is too slow, one would need to decrement the prescaler and calibrate from a (then) too fast clock.)

My tests show that RCCV isn't interpreted as signed (two's complement) value.

And I can't find any other field that would work as a sign bit, either. I mean, e.g. in contrast to the GD32F1x0 where the RTC_HRFC register contains the CMSK (Calibration mask number) and FREQI fields.

Can you clarify this point?

setup.bat

**** ПРЕВЫШЕНИЕ РАЗМЕРОВ СТЕКА ****
**** ПРИ ВЫПОЛНЕНИИ РЕКУРСИИ В ПАКЕТНОМ РЕЖИМЕ ****
Глубина рекурсии=317, Использование стека=90 проц.
**** ПАКЕТНАЯ ОБРАБОТКА ПРЕРВАНА ****

Issue translated using google:

setup.bat

**** OVERSTACK SIZES ****
**** WHEN PERFORMING RECURSION IN BATCH MODE ****
Recursion depth = 317, Stack usage = 90 percent.
**** BATCH PROCESSING INTERRUPTED ****

According to the _read function requirements defined here: https://www.embecosm.com/appnotes/ean9/html/ch05s03s14.html, current stub code for _read is not implemented correctly, need to be fixed.

When working with Nuclei SDK 0.4.1, build and compile with semihosting library, the semihosting feature is not working as expect.

make STDCLIB=newlib_nano CORE=n300fd SEMIHOST=1 clean all

The program stop at early_exc_entry and no output in openocd console, which is not as expected.

Currently some of the common function names are prefixed with the board name.

void gd_eval_led_init(led_typedef_enum lednum);
void gd_eval_led_on(led_typedef_enum lednum);
void gd_eval_led_off(led_typedef_enum lednum);
void gd_eval_led_toggle(led_typedef_enum lednum);
void gd_eval_key_init(key_typedef_enum keynum, keymode_typedef_enum key_mode);
uint8_t gd_eval_key_state_get(key_typedef_enum key);

void gd_rvstar_led_init(led_typedef_enum lednum);
void gd_rvstar_led_on(led_typedef_enum lednum);
void gd_rvstar_led_off(led_typedef_enum lednum);
void gd_rvstar_led_toggle(led_typedef_enum lednum);
void gd_rvstar_key_init(key_typedef_enum keynum, keymode_typedef_enum keymode);
uint8_t gd_rvstar_key_state_get(key_typedef_enum keynum);

Looking at the source I could not find any technical reason for this. Function signatures and behaviour are the same. Could the function names be unified to be the following?

void gd_led_init(led_typedef_enum lednum);
void gd_led_on(led_typedef_enum lednum);
void gd_led_off(led_typedef_enum lednum);
void gd_led_toggle(led_typedef_enum lednum);
void gd_key_init(key_typedef_enum keynum, keymode_typedef_enum keymode);
uint8_t gd_key_state_get(key_typedef_enum keynum);

This way you could use the same code for different dev boards.

in portasm.s of freertos file ,there are a undefined reference to `_sp'.
where to define the "_sp" in la to _sp?
how to solve this problem?

When cloning the repository over a slow connection I noticed that it contains a bunch of prebuilt libraries:

$ du -chs NMSIS/Library/
117M	NMSIS/Library/
117M	total

I'm kind of afraid that those prebuilt libraries will bloat this repository in the future even more, when each change to them basically adds another 100 MBs or so to the git index.

Is it really necessary to include those artifacts?

Perhaps there are alternatives such as using Git Large File Storage or building them from source like the rest?

Hi!
Can I use this sdk with Logan nano GD32VF103CBT6 board.

Hi
openocd reg command can't display all values of all registers. So i have to invoke command "reg a0", "reg a1" and so on, which is very slow. Any workaround?
thanks
Peter

Currently, SDK is still using the driver which is 2 years old. Driver from gigadevice has updated a lot since then, so better update to newer version.

I create a smp demo by "SMP Helloworld in baremetal environment @app-nsdk_smphello" on NucleiDemo.
But it can't run into main() when i debug it with qemu, does i need to do any other configuration?
I also build it from nuclei-sdk/application/baremetal/smphello by hand. Only one cpu run.
LOGS:

Nuclei SDK Build Time: Jun 15 2022, 18:01:00
Download Mode: ILM
CPU Frequency 46858 Hz
Hello world from hart 0
Some harts boot failed, only 1/2 booted!

I think nuclei-n307fd which demo use by default does not support smp?

I test by below:

qemu-system-riscv32.exe  -machine nuclei_n -cpu nuclei-n307fd -smp 2 -serial stdio -nodefaults -S -s
qemu-system-riscv32.exe: Invalid SMP CPUs 2. The max CPUs supported by machine 'nuclei_n' is 1

__set_exc_entry and the other functions related to mtvec take and return the integer rv_csr_t type, although the values you would pass in are pointers. They should probably take and return void * types?

I'm wondering if it is possible to jump to the embedded bootloader that is present at 0x1FFFB000 in the devices ROM without a reset and externally pulling Boot0 high?

So far I have tried to jump to 0x1FFFB000 immediately after the device has been reset in the startup code. Observing the execution path with a debugger I can confirm that this indeed produced a valid jump, but the bootloader code is not executed successfully e.g. with a USB connection it doesn't show up as a USB-DFU device.

I know that this is possible with STM32F103 and GD32F103, so there is a chance that this possible as well?

nmsis_gcc.h forcibly disables some warnings:

https://github.com/Nuclei-Software/nuclei-sdk/blob/master/NMSIS/Core/Include/nmsis_gcc.h#L46

This is very bad form for a system library. I want those warnings in my code, I do not want them silently disabled. If any headers are causing warnings, that code should be fixed, and warnings should not be silenced.

Currently there is two known versions of Longan Nano. The official version has GD32VF103CBT6 which has 128K flash and 32K sram. Apparently some Aliexpress sellers also make version with GD32VF103C8T6 which has 64K flash and 20K sram. This is also sometimes referred as the Longan Nano Lite.

Currently the Nuclei SDK linker script for Longan Nano assumes the Lite version. This causes the linking to fail with memory heavy applications.

Linking    :  firmware.elf
/opt/nuclei/gcc/bin/../lib/gcc/riscv-nuclei-elf/9.2.0/../../../../riscv-nuclei-elf/bin/ld: firmware.elf section `.bss' will not fit in region `ram'
/opt/nuclei/gcc/bin/../lib/gcc/riscv-nuclei-elf/9.2.0/../../../../riscv-nuclei-elf/bin/ld: section .stack VMA [0000000020004800,0000000020004fff] overlaps section .bss VMA [0000000020000268,0000000020006a23]
/opt/nuclei/gcc/bin/../lib/gcc/riscv-nuclei-elf/9.2.0/../../../../riscv-nuclei-elf/bin/ld: region `ram' overflowed by 0 bytes
collect2: error: ld returned 1 exit status
../nuclei-sdk-roman/Build/Makefile.rules:71: recipe for target 'firmware.elf' failed
make: *** [firmware.elf] Error 1

When changing the linker script to support 32kB sram linking succeeds.

Linking    :  firmware.elf
   text	   data	    bss	    dec	    hex	filename
  72022	    612	  28604	 101238	  18b76	firmware.elf

This issue is to start discussion how to support the different variations of the Longan Nano board. Separate linker scripts chosen with a Makefile variable is one possibility.

Build system already supports LINKER_SCRIPT variable. Can this be used or should a new variable be introduced?

test/core/test_compiler.c:

now:

{
    uint32_t __ALIGNED(2) data_aligned1;
    uint32_t __ALIGNED(16) data[4];
    uint32_t __ALIGNED(64) data2[4];
    unsigned long p_data = (unsigned long)(&data_aligned1);
    CTEST_LOG("Aligned 2 Byte Data address 0x%x", p_data);
    ASSERT_EQUAL(p_data & (1 - 1), 0);
    p_data = (unsigned long)(&data[0]);
    CTEST_LOG("Aligned 16 Byte Data address 0x%x", p_data);
    ASSERT_EQUAL(p_data & (16 - 1), 0);
    p_data = (unsigned long)(&data2[0]);
    CTEST_LOG("Aligned 64 Byte Data address 0x%x", p_data);
    ASSERT_EQUAL(p_data & (64 - 1), 0);
}

data_aligned1 is __ALIGNED(2), but ASSERT_EQUAL(p_data & (1 - 1), 0), shoule ASSERT_EQUAL(p_data & (2 - 1), 0)?

In NMSIS/Core/Include/core_feature_timer.h, there are codes like:

addr = (void *)(&(SysTimer->MTIMER));
high0 = __LW(addr + 4);

which will cause many compiling warnings in g++.

When doing arithmetic operations, void * will be treated as char * in GCC, but it is not defined in the C standard,
I guess it will be better to replace them by something like

addr = (void *)(&(SysTimer->MTIMER));
high0 = __LW((int *) addr + 1);

or

addr = (void *)(&(SysTimer->MTIMER));
high0 = __LW((char *) addr + 4);

When I build the example application with upstream RISC-V toolchain (12.2.0) for Longan Nano equipped with GD32VF103C8T6, it will show the error:

Assembling :  ../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S: Assembler messages:
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:162: Error: unrecognized opcode `csrrwi x0,0x7EE,11', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:162: Error: unrecognized opcode `csrrwi x0,0x7EF,12', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:162: Error: unrecognized opcode `csrrwi x0,0x7EB,13', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:169: Error: unrecognized opcode `csrr a0,mcause', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:179: Error: unrecognized opcode `csrw 0x7C4,x5', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:179: Error: unrecognized opcode `csrw 0x341,x5', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:179: Error: unrecognized opcode `csrw 0x342,x5', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:206: Error: unrecognized opcode `csrrwi x0,0x7EE,11', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:206: Error: unrecognized opcode `csrrwi x0,0x7EF,12', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:206: Error: unrecognized opcode `csrrwi x0,0x7EB,13', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:213: Error: unrecognized opcode `csrrw ra,0x7ED,ra', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:216: Error: unrecognized opcode `csrc 0x300,0x00000008', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:219: Error: unrecognized opcode `csrw 0x7C4,x5', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:219: Error: unrecognized opcode `csrw 0x341,x5', extension `zicsr' required
../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S:219: Error: unrecognized opcode `csrw 0x342,x5', extension `zicsr' required
make: *** [../../../Build/Makefile.rules:100: ../../../SoC/gd32vf103/Common/Source/GCC/intexc_gd32vf103.S.o] Error 1

The SDK uses riscv-nuclei-elf-gcc to compile by default. If I want to compile with Clang, what needs to be modified for the Makefile?

hi
openocd can't view register mtvt , why?
thanks
Peter

For instance, core_feature_eclic.h uses the rv_csr_t type which is defined in core_feature_base.h, but it does not #include it. This means that the header does not work if it is included on its own, and even if you include both headers, the order in which you do so matters.

Headers should #include whatever other headers they need.

The comments for __set_exc_entry says that address should be aligned to 4 bytes, but the code itself forces alignment to 64 bytes:

https://github.com/Nuclei-Software/nuclei-sdk/blob/master/NMSIS/Core/Include/core_feature_eclic.h#L757

This looks like a mistake copied from the earlier n200_func.c file, which also incorrectly aligned the address to 64 bytes. The address should be masked by ~3, not ~0x3f.

This code probably works by accident since a lot of startup code seems to place the interrupt table at the start of Flash memory, so it is accidentally aligned.

EDIT: It seems that the address written to mtvec does have to be aligned to 64 bytes, or else the hardware refuses to work. So the actual bug here is that this requirement is not correctly documented for this function.

https://github.com/Nuclei-Software/nuclei-sdk/blob/master/NMSIS/Core/Include/core_feature_eclic.h#L751

This comment says the address has to be aligned to 4 bytes, but it should be aligned to 64 bytes.

in test_csr.c:

CTEST(core, icache)
{
    EnableICache();
    ASSERT_NOT_EQUAL(__RV_CSR_READ(CSR_MCACHE_CTL) & CSR_MCACHE_CTL_IE, 0);
    DisableICache();
    ASSERT_EQUAL(__RV_CSR_READ(CSR_MCACHE_CTL) & CSR_MCACHE_CTL_IE, 0);
}

should do

__RWMB();
__FENCE_I();

before EnableICache();andEnableICache();?
Now，If my compilation option is -02,CPU may be abnormal。