Comments (5)
Hmm, judging by the variable name, and where it is used, it was intended to be 64-bit. Suspect this has just not been tested on a device where that register appears beyond a 32-bit address.
Interested to know which device you are using to see if it can be part of our test setup.
from freertos-kernel.
I was trying to compile for a 64-bit machine (with actually configMTIMECMP_BASE_ADDRESS
being lower than 2³²-1) and the compiler failed given the address constant had ull
as a suffix (included from a device HAL, so I can't change it). Maybe the data type should be uintptr_t
instead.
Another related problem (I should probably file another bug): while during timer re-arming the XLEN is checked (32 or 64) and the accesses to the mtime
and mtimecmp
are done using lw
or ld
accordingly, in the timer initialization function mtime
is always accessed as (two) 32-bit numbers, which is a problem in our platform (I can't tell which) because the timer IP only supports 64-bit accesses. And yet another problem: our platform has an isolated Hart with a mhartid
much bigger than 0 and it has its own timer, so in this platform, assuming that each hart has its own mtimecmp
at: ullMachineTimerCompareRegisterBase + ( ulHartId * sizeof( uint64_t ) )
is wrong. Maybe we could introduce a boolean macro like configMTIMECMP_ADDRESS_DEPENDS_HARTID
to enable/disable + mhartid * 8
when accessing mtimecmp
.
from freertos-kernel.
Another small issue with the RISC-V 64-bit port: https://www.freertos.org/Using-FreeRTOS-on-RISC-V.html#GCC_COMMAND_LINE_OPTIONS
void external_interrupt_handler( uint32_t cause );
cause
is read from the mcause
CSR, which is MXLEN
in length, and it is probably 64-bits on most 64-bit platforms.
from freertos-kernel.
Really appreciate you taking the time to report these!
from freertos-kernel.
I see that when there's an unknown synchronous exception (the only ones currently handled by FreeRTOS are ECALLs), the code spins forever in a loop:
is_exception:
csrr t0, mcause /* For viewing in the debugger only. */
csrr t1, mepc /* For viewing in the debugger only */
csrr t2, mstatus
j is_exception /* No other exceptions handled yet. */
I think it would be nice to be able to jump to a platform-specific routine to handle things like emulated instructions, unaligned memory accesses, etc, and to also pass the saved context as a parameter to that C-function handler (custom_exception_handler(mcause, mepc, mstatus, regs)
?) so that one can modify the registers with something like: regs[x] = y;
Something similar to portasmHANDLE_INTERRUPT
for external interrupts, but for exceptions in this case.
And the same capability (custom platform-specific handler) for Software Interrupts (IPIs. (custom_software_interrupt_handler
).
from freertos-kernel.
Related Issues (20)
- [BUG] Violation of MISRA 2012 Rule 5.5: Identifiers shall be distinct from macro names HOT 3
- Minimize the use of the taskENTER_CRITICAL and taskEXIT_CRITICAL HOT 3
- [DOC] xQueueOverwrite Queue Length HOT 2
- [BUG] Missing `extern "C"` guard in MSVC portmacro.h HOT 1
- [BUG] Violation of MISRA 10.4: Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category HOT 2
- [BUG] vTaskDelay raises configASSERT when SMP is on HOT 2
- [Feature Request] Add CodeSonar example to the repository HOT 1
- FreeRTOS posix port hangs when issuing interrupt-safe calls from an external thread HOT 3
- [BUG] FreeRTOS install with Pico-SDK fails (CMAKE_C_COMPILER_OBJECT) HOT 1
- [BUG] I used Posix gcc to compile on glibc 2.24 and gcc 6.3.0, but failed to compile the demo HOT 5
- [BUG]traceMALLOC() memory count is inaccurate HOT 3
- [BUG] SMP mode - vTaskCoreAffinitySet does not yield HOT 10
- [BUG] __VFP_FP__ Macro Does Not Correctly Indicate Floating Point Enabled for ARM Targets HOT 1
- [BUG] When configUSE_PREEMPTION=0, removing own task does not switch to another task HOT 1
- [BUG] xEventGroupBitsFromISR API doesn't work correctly for RL78 MCU(same as No.740 Issue) HOT 8
- [BUG] with configUSE_STREAM_BUFFERS==0 stream_buffer.c still requires xTaskGetCurrentTaskHandle and TASK_NOTIFICATIONS HOT 1
- [BUG] listGET_OWNER_OF_HEAD_ENTRY in fucntion xTaskResumeAll is over-optimized on xtensa platform HOT 8
- [BUG] listGET_OWNER_OF_HEAD_ENTRY results in null ptr dereference when xTaskIncrementTick is called prior to xTaskCreate HOT 2
- Real time task statistics in the uxTaskGetSystemState() HOT 3
- Port IA32_flat assembly code no longer compiles correctly. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from freertos-kernel.