Tick issue with RISC-V port on renode

Partners & Sponsors Microchip
1

Hello,

I’m working with Microchip SoftConsole v6.5 and running the RISC-V_Renode_Emulator_SoftConsole demo located here:

I’m able to build and simulate using renode, but I’m having trouble related to the tick interrupt and breakpoints in gdb. Any time I hit a breakpoint and then try to continue executing the code, FreeRTOS gets stuck running the idle task. It seems that the tick interrupt is no longer generated (xTickCount is no longer incremented after continuing execution after a breakpoint).

This is only a problem on renode - on actual hardware (MiV on an IGLOO2) I can break/continue as much as needed and there are no issues.

Has anyone else observed this behavior with the FreeRTOS riscv port on renode?

2

If it works on the real hardware the port would seem to be correct. Is renode modeling the same hardware as that on which the port is known to run?

It is common to be in the idle task when you stop the debugger as that is where the cpu spends most of its time. Is the xTickCount variable increment if at all?

3

Thanks for the response.

The value of xTickCount never changes once execution has been halted, either at a breakpoint or by hitting ^C in gdb, regardless of how long renode is allowed to run after the initial halt:

launch renode
connect with gdb
run
break with ^C
p xTickCount
<see a sensible number, indicating that many ticks happened>
continue
<wait 10 seconds or so, during which time there should have been thousands of simulated ticks>
break with ^C
p xTickCount

What’s interesting is that there are ticks to begin with, but then they do not continue to happen after a break/continue.

To the best of my knowledge renode is correctly configured to model the underlying hardware – I guess that the most relevant configuration options for renode, with respect to the timer interrupt, would be for the PLIC and CLINT, and they do match the hardware.

plic: IRQControllers.PlatformLevelInterruptController @ sysbus 0x40000000
[0-3] → cpu@[8-11]
numberOfSources: 31
prioritiesEnabled : false

clint: IRQControllers.CoreLevelInterruptor @ sysbus 0x44000000
frequency: 66000000
[0, 1] → cpu@[3, 7]

Here is another data point that I believe is relevant. There is another FreeRTOS port for riscv provided by Microchip (then Microsemi):

The implementation of this port is significantly different from the one that lives in the FreeRTOS tree (portable/GCC/RISC-V) nowadays. In the Microsemi port, the tick timer behavior is implemented mostly using the vendor-provided HAL routines (in riscv_hal.c) rather than in the FreeRTOS port.c/portASM.S files.

I replaced the port in FreeRTOS/Demo/RISC-V_Renode_Emulator_SoftConsole with the port files from the above Microsemi project and was able to break and then continue in renode many times, and the tick continued to behave as expected. To me this indicates that the issue is probably not a problem with the renode configuration. More likely it’s some difference in how the two ports are implemented. But I can’t understand how that would make one of them misbehave after a breakpoint.

I could use the Microsemi port code as a workaround, but I’d like to understand the issue rather than blindly use an old port that I found on a random GH repo. Also, I believe this issue would affect anyone trying to run the FreeRTOS/Demo/RISC-V_Renode_Emulator_SoftConsole demo. I’ve certainly reproduced it on multiple machines, with multiple versions of SoftConsole/gdb/renode.

4

This is good information. Thanks. Does the port that works in renode also work on the real hardware? I suspect, but have not looked to confirm, that the port using the HAL will be using a different time to generate the tick interrupt, and that may (speculating) be working around an issue in the renode machine timer.

5

Yes, the working port runs correctly in renode and on the hardware.