Strange behavior of vTaskDelay() when optimization is turned off (O0)

[Marionette]

@jefftenney

Installing xPortPendSVHandler directly in the vector table will solve the problem. FreeRTOS does this typically with #define, but you can probably edit the vector table directly if you want.

Can I manually call the interrupt handler by writing a call in assembler?

The fact is that the interrupt table is generated by libopencm3, where it is not possible to integrate the FreeRTOS function. Or are there other ways? Describe the option with #define, if possible.

configUSE_PREEMPTION is set to 1. PendSV is called two times: one after SVC, and the second after xTickCount reaches 1000.

Is this the wrong behavior?

[jefftenney (Jeff)]

@Marionette

Is this the wrong behavior?

No, that’s the correct and expected behavior. But then with the 8-byte stack “error” occurring only twice, it’s not likely the main stack would grow out of bounds and corrupt other memory. Maybe your configuration isn’t providing a valid main stack area?

@Marionette

Describe the option with #define, if possible.

Ideally, the library-provided vector table is full of functions that are defined “weak” so you can provide your own function by the exact same name and the linker will use yours. Then you can #define xPortPendSVHandler to be the name used in the vector table (maybe pend_sv_handler? or maybe the CMSIS standard name PendSV_Handler?) like this:

#define xPortPendSVHandler PendSV_Handler

in FreeRTOSConfig.h.

And the vector table should be in the source code somewhere for you to inspect/hack if needed.

[Marionette]

@jefftenney

No, that’s the correct and expected behavior. But then with the 8-byte stack “error” occurring only twice, it’s not likely the main stack would grow out of bounds and corrupt other memory. Maybe your configuration isn’t providing a valid main stack area?

Can you please clarify? I do not quite understand what you mean.

Attached the source code you need the file in the previous message, look.
As I understand it (based on the source code of vector.c), I can declare the following define: #define xPortPendSVHandler pend_sv_handler?

[jefftenney (Jeff)]

@Marionette

Can you please clarify? I do not quite understand what you mean.

I guess what I’m trying to say is you likely have a second problem. The first problem is not having xPortPendSVHandler installed directly in the vector table. That problem alone doesn’t seem to be enough to be causing all your symptoms. But we’ll get there…

@Marionette

As I understand it (based on the source code of vector.c), I can declare the following define: #define xPortPendSVHandler pend_sv_handler ?

I don’t know what’s in vector.c, but sure give it a shot.

[Marionette]

vector.c (just in case): https://github.com/libopencm3/libopencm3/blob/master/lib/cm3/vector.c

[jefftenney (Jeff)]

OK, yes perfect. Just eliminate your implementations of pend_sv_handler and sv_call_handler and use #define instead (in FreeRTOSConfig.h).

[Marionette]

This is unbelievable! With the preprocessor directive, everything worked! Thanks!

[Marionette]

However, now I was interested in the second problem … Apparently, this thread is not worth discussing, is it? Perhaps it’s more logical to go into private messages?

[jefftenney (Jeff)]

No, I was wrong to think there was a second problem. I had figured (wrongly) that the main stack would just keep growing uncontrolled, but really those stacked words just became part of a task’s context, which of course isn’t safe on the main stack. Anyway, glad it’s working. We never would have figured it out if @rtel hadn’t asked about your PendSV installation.