Hi – I am using FreeROS 8.2.0 The USB OTG fun continues. I discovered the issue with getting the USB OTG to function, and it now works good. I had the Systick timer divided down, a piece of legacy code accidentally left in from another project. Now that the USBOTG functions, it seems to break something in FreeRTOS. The USB code is inserted in MAIN before any calls to anything FreeRTOS related. The only calls before the USB code loop is just system initialization and GPIO configuration. After running the few lines of code that writes data to the USB drive, it de-initializes the interface, and exits out of the loop. Code continues on to the code that sets up tasks, queues, and semaphores. I also have a 2 second WDT task that runs. I have a print statement just before scheduler launch, which prints. But no tasks will execute. Any print statements in the tasks don’t print out. There does not appear to be any stack overflow. None of the FreeRTOS functions: vApplicationIdleHook, vApplicationMallocFailedHook, vApplicationStackOverflowHook, and vApplicationTickHook ever get executed. When I “#ifdef 0” the entire USB code section out, all runs normally. What could be happening…? Thanks for any help on this.

Unfortunately ….

But no tasks execute.

….does not tell us anything that would allow us to help debug the problem. For example, do no tasks execute because the call to vTaskStartScheduler() returns, or because an assert is called, or because there is a hard fault, or because the tick interrupt is not executing, etc. etc. Regards.

Thanks for replying. I commented out all FreeRTOS functions except the task that kicks the WDT. When the scheduler launches, xPortGetFreeHeapSize() returns 19560 bytes. The FreeRTOS config assert (using Atollic 5.3) is defined: define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); } Here’s the order I call the functions: int main(void) { ResetGPIO(); //set up fault & clear LED’s, UP indicator drive pins LEDSConfig(); //try initializing and de-initializing to test if system crashes UBUSBMSCHOSTInit(); USBMSCHOSTDeInit(); xTaskCreate( prvWDGTask, ( const char * ) “WDG”, 160, NULL, 1, &WDG_Task ); vTaskStartScheduler(); while(1); } If I comment out the call to UBUSBMSCHOSTInit, everything runs OK. I can see nothing in the initialization of the USB that would cause this. It’s pretty much the STM32F4 implementation of OTG. Can you please provide some direction as to how to troubleshoot this further? Unbelievably frustrating… Thanks…

If you put a break point at the top of prvWDGTask(), is it ever reached? If the break point is reached, step through the code to see what it does, how far it gets. If the break point is not reached, pause the debugger and let us know what is being executed (for example, is it stuck in a loop somewhere, is it in a fault handler, etc.). Regards.

Hi, Thanks so much for helping me on this. Here’s what I found. The code runs to the call in port.c @line 370: prvPortStartFirstTask(); I step the debugger into that, and it goes to line 282: static void prvPortStartFirstTask( void ) As soon as it hits this first line, it then jumps to the startupstm32f4ss.s module: InfiniteLoop: b InfiniteLoop .size DefaultHandler, .-DefaultHandler /****************************************************************************** * * The minimal vector table for a Cortex M3. Note that the proper constructs * must be placed on this to ensure that it ends up at physical address * 0x0000.0000. * *******************************************************************************/ .section .isrvector,”a”,%progbits .type gpfnVectors, %object .size gpfnVectors, .-g_pfnVectors etc, etc The debugger loops here. Best regards, Gary

If it is hitting a default handler, then an interrupt has occurred, but there is no handler installed for the interrupt. If it is the svc instruction in prvPortStartFirstTask() that is causing it to execute the default handler, then it sounds like the FreeRTOS interrupts are no longer in the vector table – perhaps the vector base address has been changed. If it is not the svc instruction then could it possibly be a USB interrupt? The next thing you are going to have to do is work out which interrupt was triggered, and caused the default interrupt handler to be executed.

Before I run any FreeRTOS instructions or assignments, I run the 2 USB instructions: UBUSBMSCHOSTInit(); USBMSCHOSTDeInit(); Is it perhaps that the Init function is moving the interrupts on the table? If that’s the case,
and I think I understand you correctly, do I need to restore the interrupt vectors to the same state as what they were before running the UBUSBMSCHOSTInit function ? I may be going a bit ahead here, but after initialization, is there any way to save the state of the table before running USB init and restore it after USB code has run? Why doesn’t the function call “SystemInit()” in STM32F4 restore it back? In the meantime, I’ll see if the UB interrupt is still being triggered. Regards, Gary

Fixed. Many things I don’t yet understand…the mysteries of the STM32F4 devices are deep. All I do is call this: __get_PRIMASK(); before the initialization of the USB interface. Can anyone can explain how that fixes the problem? Thanks for responding back and helping me with this. (my hair pulling is over)

Umm, don’t know. That function should just return the PRIMask value, and not change anything. Anyway, I’m glad it is working for you now. Regards.

Thanks again…so bizarre. I confirmed the running of FreeRTOS with, and without this call over a few test passes and not there, FreeRTOS hangs. I really hope someone reading this thread in future if they have time could try this out out their STM32F4 system.