Hello, I’m moving my first steps with FREERtos 7.6.0 running on an STM32L1 (cortex M3 based). In my basic application i have two tasks, one blinking leds and the other one sending alphabet charachters to the USB virtual com port. Everything goes well only if I do not add a 500 millisecond task delay after each charachter print in the last of the two tasks. Actually it looks like if adding vTaskDelay(..) in the aforementioned task, stops USB interrupts. The USB library is the standard one delivered with ST micros and does not use FreeRTOS APIs. Here the code snippets for more details, starting from the task from where the issue comes out : static void MTask( void *pvParameters ) { uint8_t k = 0;

for( ;; ){
  putchar(65 + k); /* sends out a char to the USB port */
  k=(k+1)%90;
  vTaskDelay( 500 / portTICK_RATE_MS ); /* chars go out to USB only if I delete this line!! */
}

} static void LedTask( void *pvParameters ) { static uint8_t toggle = 0; signed short temp;

for( ;; ){       
            if (toggle) {
                    GPIO_LOW(GPIOC,GPIO_Pin_1);  //ORANGE lED
                    GPIO_LOW(GPIOC,GPIO_Pin_4);  //BLUE LED
                    GPIO_HIGH(GPIOD,GPIO_Pin_2); //RED lED          
            } else {
                    GPIO_HIGH(GPIOC,GPIO_Pin_1);
                    GPIO_HIGH(GPIOC,GPIO_Pin_4);
                    GPIO_LOW(GPIOD,GPIO_Pin_2);
            }                
            toggle = 1 - toggle;
    vTaskDelay( 250 / portTICK_RATE_MS );       
} 

} ..in main I have: int main(void) {
MainHWInit();

xTaskCreate( MTask, ( signed char * ) "MainTask", (configMINIMAL_STACK_SIZE * 2), NULL, M_TASK_PRIORITY, &xMemsTaskHandle);
xTaskCreate( LedTask,  ( signed char * ) "LED",  (configMINIMAL_STACK_SIZE * 2), NULL, Led_TASK_PRIORITY,  &xLedTaskHandle);

/* Start the scheduler. */
vTaskStartScheduler();

/* we should never get here */
for( ;; );

} The two tasks run with same priority, within my settings I have :

define configLIBRARYLOWESTINTERRUPT_PRIORITY 10

define configLIBRARYMAXSYSCALLINTERRUPTPRIORITY 5

define configKERNELINTERRUPTPRIORITY ( configLIBRARYLOWESTINTERRUPTPRIORITY << (8 – configPRIOBITS) )

define configMAXSYSCALLINTERRUPTPRIORITY ( configLIBRARYMAXSYSCALLINTERRUPTPRIORITY << (8 – configPRIOBITS) )

Cortex M3 priority group set to 4 (NVICPriorityGroupConfig(NVICPriorityGroup_4);) Regarding USB priorities I have tested 13,7,1 ranging from lower to higher, really expecting 1 was high enough priority on cortex M3 but didn’t work. ..hoping I didn’t forget other significant details.. do you see anything that is so evidently wrong in what I’m doing? Thank you in advance, Adalberto

Do you have configASSERT () defined? Have you called NVICPriorityGroupConfig( NVICPriorityGroup_4 );? Regards.

Back to your questions, NVICPriorityGroupConfig(NVICPriorityGroup4) was called and already within the premises of my initial support request, while configAssert() was added only after your latest suggestion, but it’s not providing any warning in my IAR debug window (please let me know if it’s the wrong place to look for configAssert() messages…). I set configAssert as in the example you provided in CORTEXSTM32L152DiscoveryIAR project for FREERtos V8.0.0ReleaseCandidate_2 although I am on V7.6.0 from which I was missing a configAssert() example. Digging deeper : whatever millisecond parameter I set for vTaskDelay(…) as long as it is > 0 the result will allways be that the char is not sent out through USB virtual COM but in contrast to my previous post I found out that I was wrong in saying that the USB interrupt was stopped… it actually keeps on triggering but with error within the interrupt status register flag. When you get that error flag the “Correct Transfer interrupt’s service callabck” (contained in an if statement) is not called anymore within the interrupt context, and this is why I was (by mistake) thinking it was the overall interrupt to be stopped. However the final outcome remains the same : the two tasks keep running (leds toggle and putchar keeps on getting called as I can see with log breakpoints) but chars are not coming out from USB My doubts: What can vTaskDelay(>0) be touching to cause such an impact on the way USB works? Why is USB putchar() working well as soon as I delete vTaskDelay(>0) right after it? This is strange. Please let me know if you have any other suggestion, Thanks for your help, Adalberto

When you are not sure where configASSERT() is being called from it is best not to rely on it outputting any messages, but instead use a break point to see if it gets called. You can use standard assert semantics to see the file and line that triggered the assert, as per: In FreeRTOSConfig.h:

extern void vAssertCalled( unsigned long ulLine, const char * const pcFileName );
#define configASSERT( x ) if( ( x ) == 0 ) vAssertCalled( __LINE__, __FILE__ )

then in a C file:

void vAssertCalled( unsigned long ulLine, const char * const pcFileName )
{
   /* Add some code here on which you can set a break point - an inline assembly NOP
   is good, but if you use a variable instead make sure it is volatile so the compiler
   doesn't just remove it.   Generally use an infinite loop so you can get out of the   
   function but can inspect the parameters. */
}    

If adding the LINE and FILE macros bloats your code to much then just change the prototype of the function so it doesn’t take any parameters and define vAssertCalled() in such a way that you can stop on a break point and then single step through the code out of the vAssertCalled() function to see where it was called (or inspect the call stack in the debugger if practical). ….but back to the point, You would imagine that the slowing you sent the characters (that is, the longer the delay specified in vTaskDelay()) the more likely it was to work, so this is indeed strange. Can you see anything in the USB driver itself that is relying on being called within any particulate time – that is – is there any kind of time dependency built into the driver itself? The ‘interrupt’ USB mode (as opposed to bulk or isochronous) requires periodic servicing but you would image that was dealt with completely by the interrupt service routines provided by the driver itself. You say the interrupt still executes but the callback is not being called. Are you able to place a break point in the driver code then step through it to see why it is deciding not to call the callback? I’m afraid I’m not familiar with the drivers and it is a little out of the normal support scope. Regards.

Hi, I stepped over. Just realized I should had erased a statement that was running with no consequences in the idleHook of your stm32l152 eval board demo (sending out charachters through UART in FreeRTOS7.6.0) : PWREnterSleepMode( PWRRegulatorON, PWRSLEEPEntry_WFI ) ; this is not harmful in your USART demo but looks like it causes something evil to my USB functionalities eventhough as far as I knew and based on evidence when HW debugger is ON the micro wakes up istantaneously after each attempt to put it at sleep. Probably continuous writes without vTaskDelay(..) were not leaving the idleTaskHook any chance to run therefore I was having success …or whatever, now I have some clues from which I can start. Thanks for you efforts, I’m sorry that my lack of awareness kept you busy for a while but it was good to know how to use the vAssertCalled(…) and any other suggestion on analysis tools might be also useful. Adalberto