Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logic in osEventFlagsSet() for xEventGroupSetBitsFromISR() return appears to be inverted #6

Closed
josephnobes-stfc opened this issue Apr 28, 2022 · 4 comments
Assignees
Labels
internal bug tracker Issue confirmed and reported into a ticket in the internal bug tracking system mw Middleware-related issue or pull-request. rtos RTOS-related issue or pull-request wontfix This will not be worked on

Comments

@josephnobes-stfc
Copy link

Set-up
STM32F205 project on custom board using STM32Cube FW_F2 1.9.2 with FreeRTOS middleware enabled (using CMSIS RTOS v2).

Issue
When program comes to execute osEventFlagsSet() from within an ISR, it returns osFlagsErrorResource after the flag has been created through the IOC editor.

Under investigation, it seems that the logic in the aforementioned function for handling the return value of xEventGroupSetBitsFromISR() may be inverted. When pdPass is returned to indicate a successful addition of the message to the queue internally, the resonse of the calling function is to report an error, which should be the response to pdFail.

As a comparison, osEventFlagsClear() calls xEventGroupClearBitsFromISR(), but returns the error if the return value is pdFail.

Checking the example code published by FreeRTOS, != pdFail test is used to trigger the yield, therefore I think the behaviour should be as follows:

if (xEventGroupSetBitsFromISR (hEventGroup, (EventBits_t)flags, &yield) != pdFAIL) {
    rflags = flags;
    portYIELD_FROM_ISR (yield);
} else {
    rflags = (uint32_t)osErrorResource;
}

Thanks for the help. I've check that this is still the case in the latest commit to master and can't find anything else about it. If this is the wrong forum for this suggestion please let me know.

@ALABSTM ALABSTM self-assigned this Apr 29, 2022
@ALABSTM ALABSTM added this to To do in stm32cube-mcu-fw-dashboard via automation Apr 29, 2022
@ALABSTM ALABSTM added mw Middleware-related issue or pull-request. rtos RTOS-related issue or pull-request labels Apr 29, 2022
@ALABSTM
Copy link
Contributor

ALABSTM commented Apr 29, 2022

Hi @josephnobes-stfc,

Thank you for this clear and detailed report. We will forward it to our development teams and get back to you once we have their feedback.

With regards,

@HBOSTM
Copy link

HBOSTM commented May 12, 2023

Hello @josephnobes-stfc,

Thank you for this contribution, this point has been reported to our development teams. I will get back to you as soon as I have any updates.

Best Regards,

@HBOSTM
Copy link

HBOSTM commented May 12, 2023

ST Internal Reference: 152007

@HBOSTM HBOSTM added the internal bug tracker Issue confirmed and reported into a ticket in the internal bug tracking system label May 12, 2023
@HBOSTM HBOSTM moved this from To do to In progress in stm32cube-mcu-fw-dashboard May 12, 2023
@HBOSTM HBOSTM moved this from In progress to To release in stm32cube-mcu-fw-dashboard Jun 14, 2023
@TOUNSTM TOUNSTM added the wontfix This will not be worked on label Nov 10, 2023
@TOUNSTM
Copy link
Contributor

TOUNSTM commented Nov 10, 2023

Hello @josephnobes-stfc,

I hope you are fine. The point you have raised has been fixed in the CMSIS-FreeRTOS v10.2.0. Unfortunately, there is no plan to upgrade the FreeRTOS version for STM32CubeF2 .

Please allow me to close this issue. Thank you for your comprehension and thank you again for having reported the point.

With Regards,

@TOUNSTM TOUNSTM closed this as completed Nov 10, 2023
stm32cube-mcu-fw-dashboard automation moved this from To release to Done Nov 10, 2023
@ALABSTM ALABSTM closed this as not planned Won't fix, can't repro, duplicate, stale Nov 22, 2023
@ALABSTM ALABSTM removed their assignment Nov 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal bug tracker Issue confirmed and reported into a ticket in the internal bug tracking system mw Middleware-related issue or pull-request. rtos RTOS-related issue or pull-request wontfix This will not be worked on
Projects
Development

No branches or pull requests

4 participants