Freertos 202406LTS release supports TI J784S4 R5F core ? If supported, there are 3 versions port function in freertos for CRx:
GCC/ARM_CR5
GCC/ARM_CRx_MPU
GCC/ARM_CRx_No_GIC
Which one should be used for TI J784S4 R5F?
Hi @freertosuser
Welcome to the FreeRTOS Community Forums!
Use GCC/ARM_CR5, unless:
- You need MPU-based memory protection (
GCC/ARM_CRx_MPU). - You have a specific requirement for the No_GIC variant (
GCC/ARM_CRx_No_GIC), which is unlikely for J784S4. TI’s J784S4 typically uses a TI-specific interrupt controller rather than a standard GIC (Generic Interrupt Controller )
Looking at this link, the TI provided SDK has support for FreeRTOS. I’d suggest to use the port that is included in the SDK.
I tried ARM_CR5, but found that the register mapping defined in the file portmacro.h does not match J784S4 R5F. Either those registers do not exist, or the offsets are incorrect.
/* Interrupt controller access addresses. */
#define portICCPMR_PRIORITY_MASK_OFFSET ( 0x04 )
#define portICCIAR_INTERRUPT_ACKNOWLEDGE_OFFSET ( 0x0C )
#define portICCEOIR_END_OF_INTERRUPT_OFFSET ( 0x10 )
#define portICCBPR_BINARY_POINT_OFFSET ( 0x08 )
#define portICCRPR_RUNNING_PRIORITY_OFFSET ( 0x14 )
#define portINTERRUPT_CONTROLLER_CPU_INTERFACE_ADDRESS ( configINTERRUPT_CONTROLLER_BASE_ADDRESS + configINTERRUPT_CONTROLLER_CPU_INTERFACE_OFFSET )
#define portICCPMR_PRIORITY_MASK_REGISTER ( *( ( volatile uint32_t * ) ( portINTERRUPT_CONTROLLER_CPU_INTERFACE_ADDRESS + portICCPMR_PRIORITY_MASK_OFFSET ) ) )
#define portICCIAR_INTERRUPT_ACKNOWLEDGE_REGISTER_ADDRESS ( portINTERRUPT_CONTROLLER_CPU_INTERFACE_ADDRESS + portICCIAR_INTERRUPT_ACKNOWLEDGE_OFFSET )
#define portICCEOIR_END_OF_INTERRUPT_REGISTER_ADDRESS ( portINTERRUPT_CONTROLLER_CPU_INTERFACE_ADDRESS + portICCEOIR_END_OF_INTERRUPT_OFFSET )
#define portICCPMR_PRIORITY_MASK_REGISTER_ADDRESS ( portINTERRUPT_CONTROLLER_CPU_INTERFACE_ADDRESS + portICCPMR_PRIORITY_MASK_OFFSET )
#define portICCBPR_BINARY_POINT_REGISTER ( *( ( const volatile uint32_t * ) ( portINTERRUPT_CONTROLLER_CPU_INTERFACE_ADDRESS + portICCBPR_BINARY_POINT_OFFSET ) ) )
#define portICCRPR_RUNNING_PRIORITY_REGISTER ( *( ( const volatile uint32_t * ) ( portINTERRUPT_CONTROLLER_CPU_INTERFACE_ADDRESS + portICCRPR_RUNNING_PRIORITY_OFFSET ) ) )
Because of this, I was thinking that this variant is GIC based, so I chose ARM_CRx_No_GIC variant. I still have issue with the ARM_CRx_No_GIC variant.
TI SDK example uses the own version of port variant: TI_CGT. This variant has dependency on TI SDK APIs, which I am trying to avoid.
I am just trying to confirm what variant in the freertos release should be used. wonder if anyone had successfully used one of those variants in their J784S4 R5F system
TI supports FreeRTOS common functions, but the port function, they are using the own version TI_CGT. I am using GCC, so I can not use TI version of port function
You are likely right in choosing ARM_CRx_No_GIC.
You can still use that port as a reference.
Gaurav:
Do you know if FreeRTOS release ARM_CRx_No_GIC officially support J784S4 R5F ? Is there a company or person who has successfully used ARM_CRx_No_GIC for J784S4 R5F ? If nobody has done this way, I will have to port TI_CGT to gcc compiler
Thanks
IMThis port should work on a Cortex-R5 core. It will require some work on your end to make it work with your interrupt controller.
I am not aware of any.
IMO, this might be the fastest way. Have you tried compiling this port with the GCC compiler?
I got this working, but still some issue. If it is not officially supporting J784S4 R5F core, I may not use it. I don’t want to take risk to put it to prod this way
I am checking with TI and find out if they have an example of using the official release ARM_CRx_No_GIC for J784S4 R5F
If TI replies that the official FreeRTOS ARM_CRx_No_GIC release is not tested with J784S4 R5F, I will start port TI_CGT to GCC. That way we can at least get support from TI
The port is generic for Cortex-R5, so it officially supports your R5 core. I am not sure whether anyone has tried it on this specific part.
If you share the issue, we may try to help.
Sounds like a good plan!