After Running USB OTG Code, FreeRTOS hangs / WDT Reboot

groger57 wrote on Saturday, November 07, 2015:

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.

rtel wrote on Saturday, November 07, 2015:

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.


groger57 wrote on Saturday, November 07, 2015:

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)
//set up fault & clear LED’s, UP indicator drive pins

//try initializing and de-initializing to test if system crashes

xTaskCreate( prvWDGTask, ( const char * ) “WDG”, 160, NULL, 1, &WDG_Task );



If I comment out the call to UB_USB_MSC_HOST_Init, 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…


rtel wrote on Sunday, November 08, 2015:

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.).


groger57 wrote on Sunday, November 08, 2015:


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 startup_stm32f4ss.s module:
b Infinite_Loop
.size Default_Handler, .-Default_Handler

  • 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 .isr_vector,“a”,%progbits
.type g_pfnVectors, %object
.size g_pfnVectors, .-g_pfnVectors

etc, etc

The debugger loops here.

Best regards,

rtel wrote on Sunday, November 08, 2015:

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.

groger57 wrote on Sunday, November 08, 2015:

Before I run any FreeRTOS instructions or assignments, I run the 2 USB instructions:

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 UB_USB_MSC_HOST_Init 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.


groger57 wrote on Monday, November 09, 2015:

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)

rtel wrote on Monday, November 09, 2015:

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.


groger57 wrote on Monday, November 09, 2015:

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.