I've been using HALCoGen for the past months, during which I encountered some possible bugs, summarised below. For reference, I'm using GCC tools.
FreeRTOS RTI Compare 0 ISR name
From what I could infer from reading some old posts, the name of the ISR for the RTI Compare 0 interrupt was refactored from vPreemptiveTick to vPortPreemptiveTick over time. The refactoring seems to be incomplete, as the following files still reference vPreemptiveTick
- drivers/FreeRTOS/portable/CCS/CortexR4v000.xml
- drivers/FreeRTOS/portable/CCS/CortexM3v000.xml
- drivers/FreeRTOS/portable/CCS/CortexR5v000.xml
- examples/TMS570LS20x/example_FreeRTOSRxQueueBlocking.c
- examples/TMS570LS20x/example_freeRTOSBlinky.c
- examples/TMS570LS20x/example_freeRTOSIdleHook.c
This causes problems, for example, when unchecking and checking the "Use Task Preemption" checkbox in the "OS" tab in HALCoGen (for a FreeRTOS project), as the default name vPortPreemptiveTick will be changed to vPreemptiveTick, and the VIM module will call a function (vPreemptiveTick) that is not implemented.
Undefined __interrupt keyword in FreeRTOS file os_port.c
In the above file, the function vPortNonPreemptiveTick is defined as
__interrupt void vPortNonPreemptiveTick( void )
but the __interrupt attribute is not defined anywhere. For instance, for use with the GCC compiler, that would have to be defined as
#define __interrupt __attribute__((interrupt("IRQ"))
Weak notification functions when using GCC tools
The notification functions in the file HL_notification.c should be marked as weak (for GCC that is __attribute__((weak))), as it's already done for TI tools, such that the user can re-define these functions somewhere else without getting a "multiple definition" linking error.
Are you planning on fixing these issues in the next release? When is the next release planned for?
Thanks,
Carlo
