Effect of optimization levels while using freertos on cortex-R52

Hi everyone,

When I’m using FreeRTOS with cortex R52, in optimization level O0, it works fine. context swithing is also fine.

But when i use optimization level O3, there are so many issues and they are very random. My question is …whether there is a problem with FreeRTOS in optimization level O3?

Any small suggestion will mean so much to me.

Thanks & Regards,

Jahnavi Guvvala.

Hi Jhanavi,

Not that we know of… all customers including us we test with O3 enabled.
What kind of issues are you seeing ?

Regards,

Alfred

Hi Alfred,

I see issues related to heap memory. I used the heap_4.c file provided by FreeRTOS source, for my project, which has functions for all heap management, like, malloc(), free(), and thus related.
With that file excluding from 03, things seem to be working fine.
Otherwise, we see random aborts in the code.

Thanks,
Jahnavi

Hi Jahnavi,

lets try and isolate the problem, to determine from where it is coming from.
Could you (if you haven’t already) compile the kernel with O3 and your code (main) with O0 and see if you still have the same problem?

Regards,
Alfred

Hi Alfred,

I compiled only the FreeRTOS source code in O3, and all others in 00.
Still i’m seeing the Program counter hangs at a particular location and not incrementing from there. As I see, the instruction where it is hanging is a Load instruction and nothing suspicious about it.

Thanks & Regards,
Jahnavi.

Hi Janhavi,

Do you know where that location is in terms of C source code?

Alfred

Hi Alfred,

For different runs , i see different issues. as the hang issue is concerned, the load instruction is from our application. But, i see the hang issue in FreeRTOS code also,
many a times in the functions related to events.
I’m also curious to know whether the vTaskDelay() function is effected in O3 or not.

Thanks & Regards,
Jahnavi

Yes vTaskDelay is effected in O3.
Can you post an example location in FreeRTOS where you have seen the hang?

Alfred

Hi Alfred,

The issue is resolved. The bug is in the port files where a register push to the stack is missing. Thanks for the information.

Regards,
Jahnavi

@JahnaviGuvvala Would you mind to post the fix that it gets integrated into mainline ?

1 Like

Hi Hartmut,

In FreeRTOS, there are port files which are dependent on the cpu we are using. These files should be written by ourselves, based o the other port files, according to our requirement. So,I have written a port file, in ASM, in which, I have used a cpu register r4, without actually pushing it to the stack. This is in the Interrupt handler(FreeRTOS_IRQ_Handler) function.
As a result, in O3,as the register usage is high in order to increase the speed, That corrupted r4 caused the issue.
In O0, for some reasons, at the time of corruption of r4, may be cpu not used that register and hence, no issue occured.
This issue is not actually related to the source files. It is in the port files we write ourselves.

Thanks &Regards,
Jahnavi Guvvala.

Ok - got it :slight_smile:
I was thinking you found a bug in the provided FreeRTOS port layer…
Thanks for the clarification !
And yes, getting (in-line) assembler code right is sometimes hard.
Once I got mad about an issue with the GCC in-line assembly clobber list with/out optimization. Since then I try to avoid using/mixing assembler and luckily needed it only in very rare cases.

Please you got it working, but I have to say, this was a pretty vital piece of missing information in your original post. “I wrote my own port layer and have a problem” could have taken this thread in a different direction.