You can check the FreeRTOS branch issuing git checkout FreeRTOS
From your freedom-e-sdk directory.
I’m not a FreeRTOS expert, so please let me know if something is missing (very possible) or if you find any bugs (also very possible). On the HiFive1, I’m using the wake button as a button interrupt by jumping Pin 2 to Wake. Memory is very tight, and the demo application uses almost all available. You may find it necessary to increase the minimum stack size in the FreeRTOS config file if things start acting funny.
Please give it a try and let me know how it works for you. We will likely move FreeRTOS out of Freedom-E-SDK and into it’s own repo in the coming weeks which is why we have kept it on a separate branch.
I’ve recently made a few changes to the FreeRTOS context save and restore code. Please be sure to check out the latest on the FreeRTOS branch and let me know if you run into any issues.
I’ve encountered a few times where, after leaving the demo running for a few hours, I’ll find the HiFive1 locked up and my UART session dead. I’ll try and reproduce it under more methodical debug conditions.
EDIT: Nevermind. I think a slightly dodgy USB hub was the culprit. I’ll leave it running overnight just to be sure.
Thanks Dave, let me know what you find out. I’ll also take a look at a few things on my end and let you know if I find anything. I’m thinking this could be either a timer overflow issue or a stack overflow issue.
I removed the hub and bumped configCHECK_FOR_STACK_OVERFLOW up to 2 then was able to capture it again. It’s triggering a system trap before FreeRTOS’s own stack overflow callback can kick in:
#1 0x2040390e in ulSynchTrap (mcause=5, epc=541065370) at main.c:480
#2 0x20403c06 in trap_entry () at entry.S:139
Wow. This has taken eight days of near-continuous running to reproduce again.
Cheers, result:
(gdb) p $mbadaddr
$1 = -2147467264
(gdb) bt
#0 __wrap__exit (code=6)
at /Users/drew/Projects/SiFive/freedom-e-sdk/bsp/libwrap/sys/_exit.c:14
#1 0x2040394e in ulSynchTrap (mcause=5, epc=541065370) at main.c:480
#2 0x20403c46 in trap_entry () at entry.S:139
Backtrace stopped: frame did not save the PC
(gdb) p /t $mbadaddr
$2 = 10000000000000000100000000000000
(gdb) p /x $mbadaddr
$3 = 0x80004000
Thanks Dave. I’m working on getting a new version of Freedom Studio on the website. Once that is done (any day now), I’ll see if I can figure this out. Looks like we are running out of space in the SRAM.
I made a post in the RISC-V board, but perhaps this is a better place for my question. As I have the FreeRTOS port running on my HiFive board.
My question is concerning OpenOCD and FreeRTOS primitives. I found that OpenOCD support various rtos primitives for task tracking. So commands like ‘info threads’ in gdb are task-aware when running FreeRTOS.
Here is the code I believe will need to be ported:
Has there been effort in doing this and I failed to find it in my google searches?
Any updates to FreeRTOS? The FreeRTOS demo repository at https://www.freertos.org/Using-FreeRTOS-on-RISC-V.html has a SiFive port of FreeRTOS, but that port seems to be for QEMM and is missing the interrupt handlers. I have never used QEMM so I don’t know what the timer tick mechanism is, but that port seems to be missing the vector table and handlers for interrupts. In this thread there are references to a hiFive port of FreeRTOS on github, but that branch seems to have been cleaned out. The Interrupt handlers are blocked by the -D DONT_USE_PLIC and DONT_USE_M_TIME flags but if these are changed to USE_xx then handle_m_ext_interrupt() becomes undefined. Any pointers would help.
Hi Greg, Sorry there hasn’t been a lot of progress on SiFive ports of FreeRTOS for some time. The good news is that we are planning to create a port of FreeRTOS to Freedom Metal so that it will be portable across all SiFive devices.