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.
…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.
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)
{
Reset_GPIO();
//set up fault & clear LED’s, UP indicator drive pins
LEDS_Config();
//try initializing and de-initializing to test if system crashes
UB_USB_MSC_HOST_Init();
USB_MSCHOST_DeInit();
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…
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.).
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:
Infinite_Loop:
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
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:
UB_USB_MSC_HOST_Init();
USB_MSCHOST_DeInit();
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.