fix[RL78 Port] incorrect register image for pvParameters in FAR mode (#1316) #1317
Conversation
|
@KeitaKashima What do you think about this change? |
|
@aggarg san
My team will check the code. Could you please have some time to check it in about one or two weeks? |
|
@KeitaKashima Of course. Take your time. Thank you for your help with the review! |
|
@aggarg @TakeoTakahashi2020 and @ShunichiroNakamura of my team members, will check and answer the result. |
|
@KeitaKashima No worries at all! Please take your time. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
@ShunichiroNakamura and @TakeoTakahashi2020, thank you for reviewing the code. @sauleThsQuin Would you please address the comments? |
sauleThsQuin
force-pushed
the
fix/rl78-port-far-param-init
branch
2 times, most recently
from
8138738 to
4898f93
Compare
…FreeRTOS#1316) In the RL78 FAR data model, pxPortInitialiseStack() did not initialize the register image for the task parameter (pvParameters) correctly. A:DE registers were saved with dummy values instead of the actual pointer. Effect: on first context restore the function prologue read a corrupted parameter. NEAR builds were not affected. This patch aligns the FAR path with the calling convention and compiler version: - IAR V2: pass pvParameters via registers → DE = low 16 bits, A = high 8 - IAR V1 (fallback): keep legacy stack write Also keeps the original stack-frame layout and updates the comment to reflect that pointer sizes depend on __DATA_MODEL__. Result: tasks in FAR receive the correct parameter at entry; NEAR remains unchanged.
…reeRTOS#1314) * cortex-M ports: Clarify hardware-saved exception frame size variable - Rename ulStackFrameSize to ulHardwareSavedExceptionFrameSize to reflect the hardware-saved exception frame (8 or 26 words based on FPU/lazy stacking). - Add comments explaining standard vs extended frames. - Apply across Cortex-M ports. - No functional change, improves readability. Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com> Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com> * kernel-checker-script: Modify Arm copyright header regex Arm's copyright header regex is modified with the following: * Accept both single year copyright headers (e.g., "2024") and year range copyright headers (e.g., "2024-2025"). * Accept both single-line copyright header and also multi-line header. * Add the escape backslash to accept only literal dot not any character. Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com> Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com> --------- Signed-off-by: Ahmed Ismail <Ahmed.Ismail@arm.com> Signed-off-by: Gaurav Aggarwal <aggarg@amazon.com>
sauleThsQuin
force-pushed
the
fix/rl78-port-far-param-init
branch
from
4898f93 to
1612072
Compare
|
|
@aggarg |
Title
fix[RL78 Port] incorrect register image for pvParameters in FAR mode (#1316)
Description
In the RL78 FAR data model, pxPortInitialiseStack() did not correctly
initialize the register image in the task stack for the parameter (pvParameters).
The saved A:DE registers were filled with dummy values instead of the actual pointer value.
As a result, when the first context restore occurred, the compiler's function prologue read a corrupted parameter from the register image.
This only affected FAR builds; NEAR model was not impacted.
This patch updates the RL78 FAR path so that the register image matches the RL78 calling convention:
DE = low 16 bits of pvParameters
A = high 8 bits of pvParameters (via AX register image, X = 0)
With this change, tasks in FAR model receive the correct parameter at entry, while NEAR model remains unchanged.
Test Steps
Before fix: value corrupted (dummy registers A:DE = 0x1111/0xDEDE).
After fix: value matches the pointer passed to xTaskCreate.
Confirm no regression with NEAR model build.
Checklist
I have tested my changes. No regression in existing tests.
I have modified and/or added unit-tests to cover the code changes in this Pull Request.
Related Issue
#1316