RH850 U2A8 multicore porting (R7F702301A)

Kernel
1

Hello,

I have a working reference for FreeRTOS v10.4.1 ported to RH850 single core (R7F701645) which uses the Renesas CCRH compiler

From my desk research, the multi-core support is added from v11 so I will be attempting to upgrade the existing RTOS version of mine on single core first

I can sum up the porting as an implementation of 6 functions (in port.c assembly syntax) and making changes to boot up code for the single-core MCU that I used

  1. trap_set
  2. portSAVE_CONTEXT
  3. portRESTORE_CONTEXT
  4. vPortYield
  5. vPortStart
  6. vPortSetupTimerInterrupt

Similarly, I am looking for a reference for the RH850 port that has the changes to be done to enable multi-core support

  • Are there any additional port assy functions to be implemented for this?
  • Is there any reference port available for reference that closely matches RH850 U2A8 R7F702301A

Kindly suggest

2

Hi @Eshwar
Welcome to the FreeRTOS Community Forums !

Here is an example of a basic port of FreeRTOS to RH850 .

This is the discussion thread for the porting mechanism.

Let us know if this helps.
Thanks.

3

Hi,

Thanks for the reply.

I have achieved porting on RH850 single-core CPU

Kindly suggest the necessary steps (or porting) for enabling multi-core support

Is there any reference port?

4

Hi,
Thanks for reporting back.
This discussion thread provides a good starting point for porting your single-core to multi-core support.

5

Here are some SMP ports -

6

Hi Eshwar,

I have a U2A8 CS+/CCRH project sample that demonstrate multiple instances of FreeRTOS running on different cores (Asymmetric multiprocessing).
If you think this could be helpful, please provide me with your contact details, I am happy to share it with you.

Best Regards,
Tri Nguyen

1 Like
7

You can also contribute your sample here - GitHub - FreeRTOS/FreeRTOS-Community-Supported-Demos.

1 Like
8

Thanks for the suggestions.

The AMP project on U2A8 is currently using an older version of FreeRTOS.
I will create a PR after testing with the latest FreeRTOS version, following the provided demo template.
Meanwhile, I am working on an SMP port and have encountered an issue.
Question:
How do secondary cores manage their task scheduling after the primary core triggers their first task via an IPI?
Issue:
During SMP porting, Core 1 is getting stuck in an infinite sequence loop involving trap interrupts.
The sequence call of core 1 as the below:

IPI ISR -> _vPortStartFirstTask -> _vPortYield -> (loop: _vTRAP0_Handler -> _vTaskSwitchContext -> _vTRAP0_Handler_Exit -> Core 1 first task -> vTaskDelay -> xTaskResumeAll -> _vPortYield)

This results in Core 1 continuously calling the same task regardless of its cycle and almost occupies the spinlock on Core 0.

I am testing with simple demo where each core is just running a cyclic task, and the porting code is not significantly different from the porting code provided, FreeRTOS-Kernel/portable/CCRH/F1Kx at main · FreeRTOS/FreeRTOS-Kernel · GitHub.

Any insights or guidance would be greatly appreciated.

Thank you in advance!

1 Like
9

Why does Core 1 not pick the idle task when the currently running task is blocked (because it called vTaskDelay)?

10

Thank you for your hint.
The issue is that the ‘uxCoreAffinityMask’ for the idle task on core 1 is set to ‘1’.
Where is this 'uxCoreAffinityMask` assigned to ‘2’ for core 1?
I have tried to modify it manually in prvCreateIdleTasks()

image
image858×178 11 KB
, but core 0 raised an exception while core 1 only executes its idle task after a while. There may be an issue with both cores accessing the same pxReadyTasksLists, which causes it to break (core 0 raises an exception at the line: if( listCURRENT_LIST_LENGTH( &( pxReadyTasksLists[ tskIDLE_PRIORITY ] ) ) > ( UBaseType_t ) configNUMBER_OF_CORES in prvIdleTask)

11

This seems correct as core affinity is a bitmask. Why do you think it is an issue?

This should not happen assuming that you have implemented all the SMP related lock macros correctly. Take a look here for example - FreeRTOS-Kernel/portable/ThirdParty/GCC/RP2040/include/portmacro.h at main · FreeRTOS/FreeRTOS-Kernel · GitHub.

12

Thank you for your response.

The core affinity is not an issue; the problem is due to an incorrect implementation of the inter-processor interrupt, which inadvertently triggers the ISR on both cores.

For reference, there’s a branch porting FreeRTOS to RH850/U2Ax and U2Bx here: FreeRTOS-Kernel-Partner-Supported-Ports/CCRH/U2x at u2x_port.

Once again, I really appreciate your valuable feedback.

1 Like
13

Ah, I see - Good find! I think the solution should be to fix this?

1 Like
14

Yes, the issue was fixed by making a correction in IPI initialization.

15

Thank you for sharing!

1 Like