Forum Replies Created
August 13, 2019 at 3:11 am #430
it’s something wrong with your environment settings. Suggest to follow the RV32M1_Vega_Develop_Environment_Setup.pdf to set up your Eclipse environment.April 18, 2019 at 8:25 am #394
Hello VS Eschholz,
The system definition determines the BLE stack run on zero-risky core. So the radio module only is mapped to the memory space of zero-riscy.March 6, 2019 at 11:07 am #376
Nice! Thanks for your work and enthusiasms on the VEGAboard.
HowardMarch 1, 2019 at 6:06 am #369
Any 8-byte writing, even all bytes are set to 0xFF, is a real write operation to the 8-byte a program flash block. As a result, the ‘invisible’ check bit of that program flash block will be updated. Then the next writing will fail because of the updated check bit if having no erasing. The check bit will be reset only in the erase.
All source code of the release packages for VEGAboard are available. Especially, the SDK release package includes all source code of examples that run on VEGAboard. The c code of drivers of RV32M1 are under rv32m1_sdk_riscv\devices\RV32M1\drivers folder, the registers definition and interrupt handlers are under rv32m1_sdk_riscv\devices\RV32M1. The startup code can be found under rv32m1_sdk_riscv\devices\RV32M1\gcc.
For example, the LPUART issue you met can reference the fsl_lpuart.h .c files under rv32m1_sdk_riscv\devices\RV32M1\drivers.
Suggest to install eclipse and import the examples to view the source code structure in the eclipse, then you can well understand the structure of SDK.February 27, 2019 at 8:25 am #366
Hi, which features are supported in the current porting?February 11, 2019 at 6:11 am #356
There’re 4 cores on the chip, but only two cores, one of CM4 and RI5CY, one of CM0+ and Zero-riscy, are recommended because of the two sides feature of Message Unit (MU) module. One side is CM4 or Ri5cy and another side is CM0+ or zero-riscy. In theory, you can use 4 cores together, but MU will only manage two cores. Your software needs to process the communication with additional cores. If you want to try it, you can reference the 2.3 System Boot and Reset in the Develop a Multicore Application for RV32M1-VEGA application note for more information .
HowardJanuary 25, 2019 at 7:06 am #347
Follow the below steps:
1. Dependency preparation
brew install gawk gnu-sed gmp mpfr libmpc isl zlib
2. Build the PULP GNU toolchain To support RV32M1, some patches are applied to the PULP GNU toolchain
# clone pulp-riscv-gnu-toolchain git clone --recursive https://github.com/pulp-platform/pulp-riscv-gnu-toolchain # clone RV32M1 GNU toolchain patch git clone https://github.com/open-isa-rv32m1/rv32m1_gnu_toolchain_patch.git # Copy and apply the patch cp rv32m1_gnu_toolchain_patch/apply_rv32m1_patches.sh pulp-riscv-gnu-toolchain/ cp -r rv32m1_gnu_toolchain_patch/rv32m1_patches pulp-riscv-gnu-toolchain/ cd pulp-riscv-gnu-toolchain bash ./apply_rv32m1_patches.sh # Build the toolchain ./configure --prefix=/opt/riscv --with-arch=rv32imc --with-cmodel=medlow --enable- multilib make
HowardJanuary 21, 2019 at 7:59 am #332
All SRAM and Flash can be accessed by two cores. But Each core accessing to the SRAM/Flash associated with another core has low performance.
HowardJanuary 21, 2019 at 7:53 am #331
Main reason is that DAPLINK cannot be used to debug non-arm core according to the license of CMSIS-DAP. And the JTAG support isn’t included in the latest official cmsis-dap implementation.
If someone has a standalone debugger running daplink firmare with JTAG support, he can use it to debug RISC-V core just for try and test by changing the interface from jlink to cmsis-dap in the .cfg file under boards/rv32m1_vega folder.