vTaskDelay help

Hello Everyone! I’m probably missing something very obvious but I don’t understand that when I use the vTaskDelay function the delay is so short, no matter how large the number I put in the argument. I have my internal oscillator set up to 80MHz and because dspic33fj128mc802 microcontroller needs two clock cycles for an instruction I define: ~~~~~~~~~~~~~

define configCPUCLOCKHZ ( ( unsigned long ) 40000000 ) /* Fosc / 2 */

~~~~~~~~~~~~ I also define the tick rate to be 100 Hz. ~~~~~~~~~~~

define configTICKRATEHZ ( ( TickType_t ) 100 )

~~~~~~~~~~ I use vTaskDelay like this: ~~~~~~~~~~ void send_task(void *p) { while (1) { //A=A+1; unsigned char data=’k’; UART1PutChar(data); vTaskDelay(5000/portTICKPERIODMS); } } ~~~~~~~~~~~ According to what I’ve read this should send a character in 5 second intervals. On the serial monitor I get a constant flood of the letter k, definately not 5 seconds apart.

vTaskDelay help

First thing to see is if it thinks its sleeping for 500 ticks. If you call xTaskGetTickCount() before and after the call to vTaskDelay() is there a difference of 500 between the two returned values?

vTaskDelay help

Thank you for the reply. I’ve checked and the difference is exactly 500 between the two values. I get C=500 and B=0; Also whats strange is that if I count in my head to 5 thats when the next halt will occur inside the debugger. So to me it seems that in the debugger it is working correctly, but when its not in debugger I get a constant flood of letters… ~~~~~~~~~~~~~~ void send_task(void *p) { while (1) { unsigned char data=’k’; UART1PutChar(data); B= xTaskGetTickCount(); vTaskDelay(5000/portTICKPERIODMS); C=xTaskGetTickCount(); A=A+1; } } ~~~~~~~~~~~~

vTaskDelay help

So the FreeRTOS code is working, it thinks its sleeping for the right time. Next I would try toggling a pin from the tick interrupt and looking at the toggle frequency on a scope to see how quickly the tick interrupt is actually running. You can use a tick hook function for that. So set configUSETICKHOOK to 1 in FreeRTOSConfig.h, then write a function call vApplicationTickHook() that toggle the pin.

vTaskDelay help

I made the function so it toggles a led. I see the led is always red. In debug mode when stepping through the code I see the led beeing toggled when xTaskGetTickCoung(); gets called. I’ll check it with an oscillator soon. ~~~~~~~~~~~~ void vApplicationTickHook(void) {
LATAbits.LATA0 ^=1;
} ~~~~~~~~~~~~

vTaskDelay help

Note that, because the LED is being toggled each time it is called, the frequency you see on the scope will be half the actual tick frequency because the scope is counting complete cycles, not just edges. Regards.

vTaskDelay help

I see very stange things on the oscilloscope… I have impulses coming at about 17 ms intervals. Each impulse lasts 3.82 microsec with 3.313 Volts and then a very fast decrease to 0 Volts.

vTaskDelay help

When in debug mode and I have a break point set at A=A+1. Before the program hits the breakpoint I see a very nice square wave with 50Hz and 3.250 Volts

vTaskDelay help

If I open the serial monitor while in debugger mode I receive the letter ‘k’ in the expected 5 second intervals. I have no idea what could be going on. After a few cycles the dspic resets itself.

vTaskDelay help

So the frequency is right (50Hz = 100Hz toggle) until the break point is hit? So it sounds like the first sleep is working ok, but sleeps after that (after the a=a+1 line) are not? Very strange.

vTaskDelay help

Sorry I couldnt really understand your last sentence. I’ll rephrase what I wrote. The thing is if I’m in debugging mode and measuring without any breakpoints I see the 50Hz wave all the time and receive the letters 5 seconds apart on my serial monitor. The dspic reset itself because my watchdog timer wasnt turned off. The strange phenomena still prevails though, that the whole thing only works while in debug mode.

vTaskDelay help

I tried it with a very simple led_task: ~~~~~~~~~~~~~~ void led_task (void *p) { while (1) { LATAbits.LATA0 ^= 1;
    vTaskDelay(2000/portTICK_PERIOD_MS);

}
} ~~~~~~~~~~~~~~ The same thing is happening. The led is constantly turned on if not in debugger mode. When I am using debugger mode it stays on for two second and off for two seconds. If I measure the pin with the oscilloscope I get a nice square wave. Can anybody tell me whats the difference between the debug mode and the normal running mode?

vTaskDelay help

As far as FreeRTOS is concerned, there is no difference. I think there is a difference to the Microchip tools though, as I believe when creating a debug build it compiles a debug stub into your code – but I don’t know the details. I do know that if you switch from a stand alone download to a debug download (without changing the compiler options) it does a clean build of the code so it is obviously doing something. Assuming you have checked for the normal stack overflows, etc. I would look at the build options. Is the correct chip selected in the compiler tools (probably as I think you would get a warning when downloading otherwise)? Regards.

vTaskDelay help

On a different forum others have pointed out that for example the debugger sets all the pins to digital. So there are some difference between debug and normal run. Some other pin function might be in the way. For the UART module I dont use any pins that can be analog. I have checked, the device is the correct device. I think this might help: When I have this in the beginning of my main function : ~~~~~~~~~~~~~ TRISAbits.TRISA0=0; LATAbits.LATA0=0; ~~~~~~~~~~~~ On the oscilloscope I get spikes and a very fast damping. If in debug mode I get a 50Hz sqaure wave. If I change LATA0 to 1. ~~~~~~~~~~~~~~ TRISAbits.TRISA0=0; LATAbits.LATA0=1; ~~~~~~~~~~~~~~ This time when in normal run mode I see on the oscilloscope a 58 Hz square wave with a dutycycle of about 75%. The debug mode gives me again the desired 50Hz

vTaskDelay help

I’ve tried my code on a different computer. Also when I install the xc16 compiler for mplabx I installed the pro evaluation version of the compiler so it can compile with optimization 2 enabled. This time I got an error for the previously working project: (working in debugger mode) This project has __ICD2RAM defined as a symbol to the linker.” “Please go to the project properties dialog and in the x16-ld node, select the Symbols and Macros category. Then remove the __ICD2RAM symbol If I delete this the project compiles, but it wont be working. So my question is what is __ICD2RAM and what should I define instead of it?

vTaskDelay help

No idea I’m afraid – it is a question for a Microchip forum – but it does seem to point to a project configuration issue.

vTaskDelay help

My debugger problem got solved. I actually took it to one of the teachers at Budapest University of Technology, so someone could look at it in person. After a fair amount of time we realised if we turn the code optimization down to 0, the debugger mode will also reset itself periodically. The function called applicationidlehook and in that it another function called vCoRoutineSchedule(); was the cause of the problem. These remained in my project because of the demo application also had these in them and I was using the demo setup as an example for my own projects. I thought I had to include these in order to make my projects work. The microcontroller reset itself for some reason when entering vCoRoutineSchedule. We disabled configUSEIDLEHOOK and configUSECOROUTINES. After that my application was working in release mode and in debug mode. This also left us with a question but it doesn’t matter now because the problem is solved, but it is still interesting. Why did the debugger mode only reset when compiled in 0 optimization? When in optimization 2, why did the debugger solve the problem that the microcontroller couldn’t? Thank you for all your help!!!

vTaskDelay help

Hi Heri,
Why did the debugger mode only reset when compiled in 0 optimization?
configUSEIDLEHOOK : your routine will be called from the idle task which has a minimum of stack space. When code is not being optimised, every local variable and return address will be declared on stack. Could that be an explanation? It has been said that the Linux kernel can’t even run when compiled with -O0. Hein