vTaskDelay help

Kernel
1

tomirtos wrote on Wednesday, October 15, 2014:

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 configCPU_CLOCK_HZ				( ( unsigned long ) 40000000 )  /* Fosc / 2 */

I also define the tick rate to be 100 Hz.

#define configTICK_RATE_HZ				( ( 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/portTICK_PERIOD_MS);
}
}

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.

2

davedoors wrote on Wednesday, October 15, 2014:

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?

3

tomirtos wrote on Wednesday, October 15, 2014:

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/portTICK_PERIOD_MS);
C=xTaskGetTickCount();
A=A+1;
}
}
4

davedoors wrote on Wednesday, October 15, 2014:

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 configUSE_TICK_HOOK to 1 in FreeRTOSConfig.h, then write a function call vApplicationTickHook() that toggle the pin.

5

tomirtos wrote on Wednesday, October 15, 2014:

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;

}
6

rtel wrote on Wednesday, October 15, 2014:

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.

7

tomirtos wrote on Wednesday, October 15, 2014:

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.

8

tomirtos wrote on Wednesday, October 15, 2014:

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

9

tomirtos wrote on Wednesday, October 15, 2014:

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.

10

davedoors wrote on Wednesday, October 15, 2014:

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.

11

tomirtos wrote on Wednesday, October 15, 2014:

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.

12

tomirtos wrote on Wednesday, October 15, 2014:

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?

13

rtel wrote on Wednesday, October 15, 2014:

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.

14

tomirtos wrote on Thursday, October 16, 2014:

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

15

tomirtos wrote on Thursday, October 16, 2014:

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?

16

rtel wrote on Friday, October 17, 2014:

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

17

tomirtos wrote on Friday, October 17, 2014:

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 configUSE_IDLE_HOOK and configUSE_CO_ROUTINES. 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!!!

18

heinbali01 wrote on Sunday, October 19, 2014:

Hi Heri,

Why did the debugger mode only reset when compiled in 0 optimization?

configUSE_IDLE_HOOK : 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