-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RISC-V GNU Toolchain #346
Comments
Thanks @eshankn, you're right. I have fallen a little behind in the maintenance of the I just need to update the repo with the latest VSCode-Maxim templates. I'll have a PR open asap. |
@eshankn I've just opened a PR that should fix the issue. To answer your question on the Eclipse environment - Eclipse sources the The build system itself defaults to calling |
@Jake-Carter thank you for the prompt fix and explanation! Please correct me if I am wrong in my understanding. The generated Eclipse environment settings have the When trying to build the above-generated C code in Eclipse, I get this unresolved symbol error. This error is, however not present in the similar statement in the provided mnist-riscv example. Rebuilding the index does not help either. In VS Code, the generated code does build successfully but is unable to further flash onto the board. |
@eshankn the In general I need to look into our Eclipse settings again. It looks like they've become a bit outdated too. That intellisense error is probably just a missing search path. I can replicate the flashing issue you mentioned. I'm getting a hard-fault. Is it the same for you? The target architecture is set to "armv7e-m".
Open On-Chip Debugger (Analog Devices 0.12.0-1.0.0-7) OpenOCD 0.12.0 (2023-09-27-07:53)
Licensed under GNU GPL v2
Report bugs to <processor.tools.support@analog.com>
0x00002124 in ?? ()
Loading section .sec1, size 0x9fd8 lma 0x10000000
Loading section .sec2, size 0x6000 lma 0x1000a000
Loading section .sec3, size 0x10000 lma 0x10010000
Loading section .sec4, size 0x308 lma 0x10020000
Start address 0x1000ae20, load size 131808
Transfer rate: 33 KB/sec, 11982 bytes/write.
Section .sec1, range 0x10000000 -- 0x10009fd8: matched.
Section .sec2, range 0x1000a000 -- 0x10010000: matched.
Section .sec3, range 0x10010000 -- 0x10020000: matched.
Section .sec4, range 0x10020000 -- 0x10020308: matched.
[max32xxx.cpu] clearing lockup after double fault
[max32xxx.cpu] halted due to debug-request, current mode: Handler HardFault
xPSR: 0x80000003 pc: 0xe7fee7fe msp: 0x20003fd0
Polling target max32xxx.cpu failed, trying to reexamine
[max32xxx.cpu] Cortex-M4 r0p1 processor detected
[max32xxx.cpu] target has 6 breakpoints, 4 watchpoints
none
[Inferior 1 (Remote target) detached] It seems the issue is caused by the Makefiles. They use an older method for linking the combined ARM+RISC-V binary that relies on some I can resolve the issue by using the latest Makefiles and the latest RISC-V loader I developed (see RV_ARM_Loader). This new loader dynamically offsets the RISC-V code based on the size of the ARM code. Attached is the updated project. Note the "mnist-riscv-ex" project inside the top-level "RV_ARM_Loader" project, and the contents of project.mk: # Enable the RISC-V loader
RISCV_LOAD = 1
# Set the RISCV application to load
RISCV_APP=./mnist-riscv-ex I've started work on another PR to get the Makefiles updated |
@Jake-Carter thank you for the update and files! The flash issue was related to the flash task itself failing. However, I am now unable to reproduce it. I now receive the HardFault but only during the |
This issue has been marked stale because it has been open for over 30 days with no activity. It will be closed automatically in 10 days unless a comment is added or the "Stale" label is removed. |
Thanks @eshankn, still working on this. It's actually not very straightforward to update the project generator to a nested structure... Much of the core architecture is built around the assumption that all files are going into a single root directory. Still WIP! |
This issue has been marked stale because it has been open for over 30 days with no activity. It will be closed automatically in 10 days unless a comment is added or the "Stale" label is removed. |
Hello!
After using the synthesis tool for generating the C code for the RISC-V processor, there are make build errors while further flashing the code on the MAX78000EVKIT board using VS Code.
In the generated VS Code settings.json file, xPack_GCC_path is set to the now deprecated
riscv-none-embed-gcc
. While the gcc_riscv.mk file usesriscv-none-elf-gcc
as the default RISC-V toolchain, which potentially causes the error.I can see that the argument
--riscv
defaults to the value ofriscv-none-embed-gcc
. Changing this argument setting does not change the behaviour either, as this value is only used for the eclipse settings but not for the VS Code settings.json file. The parameters for the settings.json file are taken from the template wherein xPack_GCC_path is set to use riscv-none-embed-gcc and its corresponding version.MSDK installation itself provides two RISC-V toolchains wherein riscv-none-embed-gcc is now deprecated. It would make sense to remove this toolchain and update the files consistently to use riscv-none-elf-gcc instead to avoid errors. Otherwise, it would also be useful to have the flexibility to choose the toolchain where more than one option is available through an argument option for the synthesis tool.
Steps to reproduce the error:
Another quick question, the settings for VS Code require each path to be set specifically and is quite clear. However, for the eclipse settings, there is no change in behaviour for either of the
riscv-none-embed-gcc
,riscv-none-elf-gcc
, andarm-none-eabi-gcc
GCC_PREFIX values. The code always compiles without any errors. Why does this happen?The text was updated successfully, but these errors were encountered: