Hi, It’s my first time using free rtos, and I got a problem while trying to run my tasks with vTaskDelay inside it, when i comment vTaskDelay() from the tasks I get no errors and it works, and when I get the vTaskDelay back to the code proteus pauses,
We need to isolate the problematic part. Start by just creating 2 tasks which do nothing but increment a counter and call vTaskDelay:
void Task( void * params )
{
uint32_t counter = 0;
for( ;; )
{
counter++;
vTaskDelay( pdMS_TO_TICKS( 1000 ) );
}
}
Once that works, you can add parts of your application logic one by one. This will help us narrow down the problematic part.
Sorry I think I deleted a section by accident while writing the post, now it’s edited to the right context, when I comment vTaskDelay the code works, when I get it back the problem appears
Is it also true for the task code snippet I shared? In other words, if you create 2 task with the task function set to the above definition, does it still crash?
yes it does crash any usage of vTaskDelay crashes the program
Could you put a break point at the vTaskDelay call and step through it. There is going to be a lot of things going on but the important one is that you should see the task transition to the ‘Blocked’ state (this is done through placing the task on a delayed list) and that the next highest priority task in turn executes. If you try this with only a single application task, rather than two, this will be the IDLE task which gets automatically created.
I can’t debug using a debugger because I don’t have one yet, and proteus just crashes when you use .elf file which supports debugging, so I have no means of doing this, however, I tried one task only and got the same issue, it seems to get to vTaskDelay and crashes, because it never transitioned from green led to any other, nor using the 7 segment only made the counter count anything, just reaches vTaskDelay and stops
Nothing seems wrong with your code at a glance. So we need to isolate if the problem is with your simulation tool or the code itself? Is it possible for you to create a simulation for another hardware? The reason I ask if because I have NUCLEO-H743ZI2 board from ST and if you can create a simulation project for that, then we can see if I can run the same code on the real hardware or not.
Hi @aggarg thank you and @kstribrn too, the problem was that proteus as a tool failed to run the simulation, I got a stlink v2 programmer/debugger and was able to flash the program and test it on real hardware, it worked flawlessly, so it appears to be a simulation tool issue, thanks for your time, now I got another problem🤣, if you take a look on the main.c and look for a function called xManualModeTask, whenever I use it in my program, the whole systems stops, like all processes not work, and it’s functions of switching mode isn’t working either, I checked the hardware it seems to be no issues, tried ground and vcc on the manual mode pins and nothing changed, if you got time can you give it a look please?
Glad that you are able to figure it out.
Nothing looks wrong other than the fact that you should remove these vTaskResume calls. Can you break the code in debugger and see what it is doing when it appears stuck?
It’s reading pins correctly but doesn’t seem to execute the code inside the conditions like vTaskSuspend,
How do you verify that? Can you remove that code and toggle an LED in those branches to confirm that the code in those branches is executing?
I used debug mode and checked variables, xMode that stores pin reading, it has 1 when the switch is on and 0 when off, when I put a break point inside the if conditions it doesn’t stop there for debugging
Not read the full thread, but from twenty years of supporting folk using simulators I can say nearly always the issue turns out to be in the simulator. Does your code run on the real hardware? [edit]Ah - I see I should have read the whole thread before posting 
[/edit]
It might just be your debugger issue. Make sure that you are compiling your code with all the optimizations disabled and maximum debug info - check the documentation for your toolchain to find out how to do that. Alternatively, use some other method, such as toggling an LED or increasing a counter, to confirm if a code branch is executing.
When anything “goes wrong” with vTaskDelay(), remember that the API will cause a yield. Maybe the task calling vTaskDelay() has no problem, but when the next run-able task will get the CPU, something goes wrong.
A bit more sample source code would be useful.
I solved the problem I was facing by implementing another simpler way of handeling vTaskDelay,
I used smaller delays and calculated the seconds based on a variable that’s incremented every time the function works after a delay,
so by making the delay 500ms instead of 6000 i could check for the gpio every 500ms which is good for my application,
also this enabled me to use less tasks as i deleted the task that was used to calculate seconds into a variable to display on a 7 seg display,
but the problem that I was facing I don’t understand it yet,
My goal was to make a manual control mode for the traffic lights that stops the traffic light task and light what the user chooses based on input pins,
I made a task that checks for pins every 200ms, and when it get pins input high it suspends the traffic light main task and works on it’s own until the user exits manual mode,
that didn’t work because the traffic light task stops completely before any user input, when testing the code to isolate the problem it appears that just creating that manual mode checking task makes the traffic light task stop, but not the other 2 that handle seconds counting and 7segment multiplexing, I tried using notifications but it stops the traffic light task, so I gave up to my simpler solution till I learn more about how free RTOS works.
I’m a CS student so I have the fundamentals of how OS work but just starting in the technical part of it.
Hi @htibosch I have mention the repo of my code in the end of my post, you can take a look at it, I didn’t push my last commit yet that has my work around.
will point out one issue with “suspending” the main task, if done via vTaskSuspend, is that one task does that to another, it has no idea where that task was. (if the suspending task has lower priority, it knows it is blocked on SOMETHING, but not what, if higher, just that it wasn’t in a critical section).
Having one task try to control another works best by setting a flag variable that the receiving task looks at frequently, but at controlled point, so it can orderly follow the request and keep the system in a correct state.