Hello, I’m using the IAR debugger – I’ve noticed the following: The last task created seems to execute at least once before the debugger starts. I have counters in my tasks that will count how many times they run, errors, etc. similar to those in the example code. I’ve noticed that the last task created seems to execute at least once before the debugger starts (halts the system – that is, for a debugging session). Since the scheduler is started in main() – and that isn’t called (allegedly) before the debugger starts – I don’t know how vTaskStartScheduler() gets called before the debugger starts. xTickCount shows something like 10 and the run counter for the last task created shows 1. Just wondering if anyone else has seen something similar and can give any insight as to what’s going on. It obviously seems that the scheduler starts somehow before the debugger begins. The other odd thing here is that the last task created seems to be the one that runs – even though vTaskSuspend() is immediately called after it’s created. Thanks, John W.
Which processor are you using? Where are you placing the break point? If you are placing the break point on the vTaskStartScheduler() function then you should find that no tasks have yet executed, and your execution counts are all zero (naturally). If one of your execution counts is not zero then there is a hint of memory corruption occurring some place. The last task created is not necessarily the first task to execute, depending on priorities. Are you saying that placing a break point in the task itself before a call to vTaskStartScheduler() you find that the execution count has already incremented when the break point is first hit? That would be odd. Again maybe the variable is corrupted, rather than legitimately incremented. Try switching to the cooperative scheduler, just for a test, then stepping through the startup of the scheduler so you can see which tasks run and in which order.
MSP430F1611IPM The debugger starts at main() . Possible the task execution variable is invalid I suppose – all others read 0 (zero). xTickCount shows something like 10 – which indicates it ran briefly. I’ll try the cooperative scheduler to see if the same thing occurs. Thanks.
The tick counter cannot be incremented by the kernel until after the scheduler has been started simply because the timer interrupt is not configured until that time! However, an incorrect debugger configuration may actually cause this to happen as per item 2) below….. Two possibilities: 1) The variables are not being initialised correctly by the startup code prior to main() being called. 2) Does this happen on the first execution after the hardware has been turned on? I suspect not, and that it only happens following at least one download, debug cycle. If the latter is the case then I strongly suspect that the problem will be with the debugger macros. If the MSP430 IDE works in the same way as the ARM7 IDE then there are various macros that can be called to configure the hardware at various times during the download process. These macros basically reset the hardware to its initials state (turn timers off, reset UARTS, uninstall interrupt handlers, etc.). If you have downloaded and executed the code once then the tick interrupt will have been configured. When you download the code again the debugger macros should ‘unconfigure’ it again. If this is not happening then the timer will continue to generate interrupts as the code is downloaded, and during the startup code, and this is a really, really bad thing as the scheduler will be in an inconsistent state during the initialisation. I have had a similar experience using IAR with ARM. Is there a .mac file that is being used by your project? If so take a look in it to see what it is doing. Also as you download the code you should get some print out in the IDE about what the debugger is doing as far as initialisation goes. Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.