FreeRTOS

Hello all, We have just finished an initial port of FreeRTOS for the HiFive1 and E31 Coreplex FPGA platforms into Freedom-E-SDK under the FreeRTOS branch. Please be sure to read the readme file first:
https://github.com/sifive/freedom-e-sdk/tree/FreeRTOS/software/FreeRTOSv9.0.0

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.

4 Likes

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. :slight_smile:

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.

Thanks.

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

Load access fault?

Can you print out mbadaddr?

I apologise, I wasn’t expecting a response in real-time so reset the board and lost the bad state. :confounded:

x 0x343 when it comes up again?

GDB should know the names of the csrs and also you can use (base-10) numberings:

p $mbadaddr
or
p $csr835

But it does seem like a stack overflow issue is the root cause. What program are you running?

Just the Demo/RISCV_HiFive1_GCC application, without any modifications other than the config value.

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.

Great. Btw, I left it plugged in on my desk if there’s anything useful I can gleam for you?

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?

I do not know of any ongoing work to port the RISC-V FreeRTOS support for OpenOCD, you’d be the first I believe.

At SiFive, we have been working on the FreeRTOS port itself, currently in draft form at https://github.com/sifive/freedom-e-sdk/tree/FreeRTOS.

Is there any news regarding the SiFive FreeRTOS port?

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.

I will update this thread as progress is made.