ContributionsMost RecentMost LikesSolutionsRe: Nios-V alt_epcq_controller_write() Problem Hi Balerion, Regading to avl_mem slave: If you also place avl_mem slave in Peripheral Region, you can use the current altera_epcq_controller.c file as is. However, you may want to place avl_mem slave in cacheable (non-Peripheral) region to take advantage of the cache for read accesses. In that case, cache maintenance needed for flash memory write operation in Nios V/g system. Here is a code example (= not fully validated) to achieve this attached (please replace the file extension from ".txt" to ".c"). At the end of the alt_epcq_controller_write_block() function, cache flush function call and error checking are added. Thanks, ShoH Re: Nios-V alt_epcq_controller_write() Problem Hi Balerion, In any case, it is highly recommended to use non-cached access to Peripherals in order to ensure reliable and stable access to Peripherals. Thanks, ShoH Re: Ahsling RiscFree IDE 25.1.1: Unresolved inclusion Hi Frank, I can't attach XML file, so I'll just paste the contents of include_search_path_25.1.1_win.xml. Use this as the contents of the .xml file. Again, the xml file is an example for 25.1.1 RiscFree running on Windows PC, so named as include_search_path_25.1.1_win.xml. <?xml version="1.0" encoding="UTF-8"?> <cdtprojectproperties> <section name="org.eclipse.cdt.internal.ui.wizards.settingswizards.IncludePaths"> <language id="org.eclipse.cdt.core.g++" name="C++ Source File"> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\riscv32-unknown-elf\include\c++\13.2.0</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\riscv32-unknown-elf\include\c++\13.2.0\backward</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\lib\gcc\riscv32-unknown-elf\13.2.0\include</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\lib\gcc\riscv32-unknown-elf\13.2.0\include-fixed</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\riscv32-unknown-elf\include</includepath> </language> <language id="org.eclipse.cdt.core.gcc" name="C Source File"> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\riscv32-unknown-elf\include\c++\13.2.0</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\riscv32-unknown-elf\include\c++\13.2.0\backward</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\lib\gcc\riscv32-unknown-elf\13.2.0\include</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\lib\gcc\riscv32-unknown-elf\13.2.0\include-fixed</includepath> <includepath>C:\altera_pro\25.1.1\riscfree\toolchain\riscv32-unknown-elf\riscv32-unknown-elf\include</includepath> </language> </section> <section name="org.eclipse.cdt.internal.ui.wizards.settingswizards.Macros"> <language id="org.eclipse.cdt.core.g++" name="C++ Source File"/> <language id="org.eclipse.cdt.core.gcc" name="C Source File"/> </section> </cdtprojectproperties> Note: If you installed RiscFree in non-default folder, edit the attached xml with a text editor and replace path names accordingly. Also If you are running on Linux platform, need to change it as your Linux install folder and path format. Thanks, Sho Re: Ahsling RiscFree IDE 25.1.1: Unresolved inclusion Hi Frank, FvM First, As you may already know, RiscFree is based on Eclipse C/C++ Development Toolkit (CDT), and these "unresolved inclusion" messages are from Indexer, which is a component of Eclipse. Indexer parses and analyzes your project files to help your source code exploration in GUI. So these warnings are not related the build process for your binary and the build process can be successfully completed regardless the messages. (Back to the main topic) As you pointed out, fully automatic resolution of Indexer search path settings is not supported yet in RiscFree today, unfortunately. However, We can resolve "unresolved inclusion" issue by manually setting the search path for Indexer. To search files in BSP project: After you have imported both the application and BSP project: Right-click on the application project in Project Explorer Select Properties Navigate to the Project References tab Check the option box for the BSP project, then click Apply and Close To search C/C++ libraries: (This is how I workaround...) Add the default RISC-V gcc include file search paths into project properties. To do this, import the xml explained in my next post with the following steps. The xml file is an example for 25.1.1 RiscFree running on Windows PC, so named as include_search_path_25.1.1_win.xml. Right-click on the application project in Project Explorer Select Import... Select C/C++ -> C/C++ Project Settings, then click Next Click Browse..., then select the attached xml file: include_search_path_25.1.1_win.xml Click Finish After these setup, there is no "unresolved inclusion" in my RiscFree. Hope this helps, Sho Re: Ahsling RiscFree IDE 25.1.1: Unresolved inclusion Hi Frank, In case you want to create your own xml file (or to create an xml for different version of tool etc.), How the xml file was created: 1. Right-click on the application project in Project Explorer 2. Select Properties 3. Navigate to the "C/C++ General -> Paths and Symbols" tab 4. Select "Includes" tab in the "Paths and Symbols" pain on the right side 5. Click "Add...", then added the default riscv32 gcc include paths. 6. Click "Export Settings..." , and export your settings with an adequate filename. How to find the default riscv32 gcc include paths: In niosv-command-shell, run the command Windows : riscv32-unknown-elf-gcc -x c++ -v -E NUL Linux : riscv32-unknown-elf-gcc -x c++ -v -E /dev/null This command shows various info. Extract lines from "#include <...> search starts here:" to "End of search list." .... #include <...> search starts here: C:/altera_pro/25.1/riscfree/toolchain/riscv32-unknown-elf/bin/..... C:/altera_pro/25.1/riscfree/toolchain/riscv32-unknown-elf/bin/..... C:/altera_pro/25.1/riscfree/toolchain/riscv32-unknown-elf/bin/..... C:/altera_pro/25.1/riscfree/toolchain/riscv32-unknown-elf/bin/..... C:/altera_pro/25.1/riscfree/toolchain/riscv32-unknown-elf/bin/..... C:/altera_pro/25.1/riscfree/toolchain/riscv32-unknown-elf/bin/..... End of search list. .... Or if Linux, you can use awk command to extract necessary lines, like this: riscv32-unknown-elf-gcc -x c++ -v -E /dev/null 2>&1 | awk '/ <...> search starts here/{flag=1} flag {print} /End/{flag=0}' Regards, Sho Re: Nios-V alt_epcq_controller_write() Problem Hi Balerion, Yes, disable caching(0Kilobytes of cache) is another option and a good choice when you use Tightly Coupled Memories(TCMs). (In my design, I usually disable cache when I can use sufficient size of TCMs.) There is no difference between Peripheral A and Peripheral B for the core. You may use ether one. When you feel convenient with two separeate peripheral region, you can use both. These allow you to use separate regions for Peripheral. Accessing TCM always bypasses cache memory(=Cache is never used for TCM accesses). So you don't need to worry about peripheral region for TCM. https://www.intel.com/content/www/us/en/docs/programmable/683632/25-3/accessing-tightly-coupled-memory.html "peripheral access must be non-cached" : Caches store copies of data, and accessing peripheral registers through a cache can result in reading "stale" data, or a write could be held in the cache and never write to the peripheral hardware. Please note that this is due to the way CPU caches work and is not specific to Nios V. Please let me know if disabling cache or caring peripheral region helps to resolve the QSPI access issue. Thanks, ShoH Re: Nios-V alt_epcq_controller_write() Problem Hi Balerion, Thanks for checking. OK, I need to say: You must locate registers of peripheral IPs in a peripheral region. https://www.intel.com/content/www/us/en/docs/programmable/726952/25-1/peripheral-region.html If the jtag uart appears to work within your current system, please consider it a coincidence. At a minimum, in your system, you must define a Peripheral Region to place the jtag uart and the epcq avl_csr registers in peripheral region, such like: Peripheral Region Size : 64 KBytes or larger Peripheral Region Base Address : 0x48050000 Thanks, Sho Re: Nios-V alt_epcq_controller_write() Problem I see that you are using Serial Flash Controller. Cached and non-cached regions( = peripheral regions) are specified in your HW design (Nios V IP configuration in PlatformDesigner). If the HW design was not designed by you, please check with your HW designer. (I think UART or JTAG-UART is used in your design and the UART works as expected. If so, the UART registers should already be correctly located in a peripheral region. ) https://www.intel.com/content/www/us/en/docs/programmable/726952/25-1/memory-configurations-tab.html Regards, Sho Re: Nios-V alt_epcq_controller_write() Problem Thanks for the info. I'll check if I can prepare a similar set-up. Regarding flash controller, are you using Serilal Flash Controller, not Serial Flash Controller II ? And just to be sure, you are assigning avl_csr address of the flash controller in non-cached address region, right? Regards, Sho Re: Nios-V alt_epcq_controller_write() Problem Hi Balerion I'll try to reproduce the issue. Can you share Quartus version and FPGA device that you are using with? Regards, Sho