Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

vTaskDelay help

Posted by tomirtos on 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 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

Posted by davedoors on 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?


vTaskDelay help

Posted by tomirtos on 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/portTICKPERIODMS); C=xTaskGetTickCount(); A=A+1; } } ~~~~~~~~~~~~


vTaskDelay help

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


vTaskDelay help

Posted by tomirtos on 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;

} ~~~~~~~~~~~~


vTaskDelay help

Posted by rtel on 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.


vTaskDelay help

Posted by tomirtos on 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.


vTaskDelay help

Posted by tomirtos on 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


vTaskDelay help

Posted by tomirtos on 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.


vTaskDelay help

Posted by davedoors on 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.


vTaskDelay help

Posted by tomirtos on 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.


vTaskDelay help

Posted by tomirtos on 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?


vTaskDelay help

Posted by rtel on 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.


vTaskDelay help

Posted by tomirtos on 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


vTaskDelay help

Posted by tomirtos on 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?


vTaskDelay help

Posted by rtel on 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.


vTaskDelay help

Posted by tomirtos on 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 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

Posted by heinbali01 on October 19, 2014

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


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists