XleraSolutions
New ContributorJoined 5 years ago
User Profile
New Contributor
User Widgets
Contributions
- 1.3KViews0likes0Comments
- 1.3KViews0likes0Comments
Re: NIOS V with FreeRTOS
I can confirm this is still a problem in Q25.1. It seems it may be worse, in that fewer Altera drivers are picked up. Here's a work around we are using... 1. Build the bsp for HAL in another directory. This will pull in all those drivers. Then just copy the <your bsp dir for hal>\drivers (inc and src directories) to your FreeRTOS bsp drivers directory. You could also just pick the missing Altera drivers from inc and src if you'd rather not see 'overwrite' messages for those that were already in FreeRTOS bsp. 2. Edit your FreeRTOS bsp alt_sys_init.c file to add the missing drivers' init function calls and the storage reservation macros. Basically you are pulling the HAL bsp's alt_sys_init.c data. 3. It seems the FreeRTOS system.h -is- getting correctly setup for those drivers even though they are not there. But if you find it is not (like base address or interrupt vector are wrong or missing) you can manually update system.h. If you'll rebuild the bsp a lot you can write a python script to do the patching.1.4KViews0likes2CommentsRe: RiscFree debugging fails after first debug
I agree, I have been dealing with the same behavior to the point that reloading the SOF is a habit. Posing a problem now that development is further along (plus QSPI booting now), since reloading the SOF is a full reset to everything. Thought the issue was related to using off chip DDR, but reduced the case to minimal nios-v running from block ram with only the essentials. Nios-II didn’t have this issue.6.7KViews0likes0CommentsRe: RiscFree debugging fails after first debug
Hi all, I see this same issue, for about 6mo now. I had thought it was because I was running the Risc-V from external DDR3. However, I eventually built a reduced case that had nothing but the minimum required for Risc-V, running from internal blockram. Still the issue persists. Only way to get it to work is reload the SOF. A similar issue it that the processor traps on a bad event when loading the elf and running. Often just hitting restart several times will get it to make it to main(). Nios-II never exhibited this behavior. A working theory is that the Risc-V core is executing garbage or still executing your elf from the last run. I've noticed that stopping or disconnecting seems to release the processor to run from there (I don't think the Nios-II did that). In any event, something seems to not get reset correctly in the Risc-V core when reloading.7KViews0likes0Comments- 3.1KViews0likes0Comments
- 3.3KViews0likes0Comments
- 3.3KViews0likes0Comments