Getting FreeRTOS task or Queue to Write To USB

Kernel
1

groger57 wrote on Sunday, July 09, 2017:

Hi:

On an STM32F4 target board, I have a USB flash port that works 100% OK. By this, I mean that I am able to transfer data from an FRAM chip to the USB flash. I can do this after initializing peripheral interfaces and going through the USB flash interface to verify the device is connected, then mounted, then transfer. The transfer takes under 1 second. This is using a C program, before I initialize FreeRTOS tasks or launch the scheduler (They are essentially commented out to test this functionality)

Now, I would like to do this through FreeRTOS, after I launch the scheduler. On my board, I have a push button that I can press and detect such that, when a USB flash is inserted, the user can push and hold the button, and a transfer can be executed. In FreeRTOS, after detecting the button press in a task, I send a message into the Queue and
then call the function

USBconnected = initializeUSB();

Which returns TRUE if device is mounted successfully. It returns true, then calls the function “usbTransfer()” and begins the data transfer from RAM to flash. However - that’s as far as it goes. It never finishes, and seems to hang up. The file never gets opened but never gets finished writing and not closed. I have tried things like using vTaskSuspend on other running tasks but to no avail.

I know that the USB interfaces can be quirky, and maybe I need to do other things in FreeRTOS to use it?
Any suggestions on what might be wrong?

Thanks…

2

richarddamon wrote on Sunday, July 09, 2017:

Is it possible that the USB program is expecting interrupt to be disabled but some interrupt is occurring and crashing the system?

3

groger57 wrote on Sunday, July 09, 2017:

If I put the code (below) at the start of my program, before even creating a task, it executes and transfers the data. I think this ascertains that interrupts are not interfering with the USB function, as the same ones are kept enable from the time initializeSystem() is called.
It is something after launching the scheduler that is causing it.

main()
{
// set up I/O and enable interrupts
initializeSystem();

sysData.USBconnected = initializeUSB();            

if( sysData.USBconnected )
{
    uint8_t xferStatus = usbTransferData();
}

//do Freertos task creation down here…
//launch scheduler here…

}

To try using the call in FreeRTOS, I comment out the call at main(), and execute a SendQueue fom the button press task:

void memQueueFunction( void *pvParameters )
{
uint8_t rxValue;
portBASE_TYPE xStatus;

for(;;)
{
    xStatus = xQueueReceive( memQueueHandle, &rxValue, rxQueueRATE );

    if( xStatus == pdPASS )
    {
        if( rxValue == 55 ) //value for USB transfer
        {
            sysData.USBconnected = initializeUSB();            

            if( sysData.USBconnected )
            {
                uint8_t xferStatus = usbTransferData();
            }                
        }
        else //another kind of message
        {
            memUpdateTask( MEM_STD );
        }
        
    }
}

}

Please let me know if I can provide anything else that might help solve this problem!

Gary

4

rtel wrote on Sunday, July 09, 2017:

Have you gone through the usual suspects?

First ensure you are using a recent version of FreeRTOS, as recent
versions have more assert points, then ensure to define configASSERT().
http://www.freertos.org/a00110.html#configASSERT

Next, as you are using an STM32, ensure to read the special note for
STM32 users, highlighted in red, on this page:
http://www.freertos.org/RTOS-Cortex-M3-M4.html

Finally, ensure you have stack overflow detection turned to 2:
http://www.freertos.org/Stacks-and-stack-overflow-checking.html

Do any of those highlight the cause?

5

groger57 wrote on Wednesday, July 12, 2017:

Hello:

I am using FreeRTOS 9.0.0, and have config Assert set as this:
-#define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }
To be clear, if assert is called, should halting execution in the IAR debugger stop at the point that assert is stopped (looping) at?

I found that the file usb_bsp.c was set to NVIC_PriorityGroup_2, and I have changed it to NVIC_PriorityGroup_4. I am unable to get to it and test for a couple of days though. It seems likely that this might be the cause of the problems by what I have read at your link.

Also - I have stack overflow check set to 2.

Thank you for your help.

6

rtel wrote on Wednesday, July 12, 2017:

taskDISABLE_INTERRUPTS() will probably only disable interrupts up to and
including the priority set by configMAX_SYSCALL_INTERRUPT_PRIORITY. If
all your interrupts are at or below that value (meaning a numerically
higher value on a Cortex-M) then no code other than the infinite loop
will run. If you have interrupts above that priority then they will
continue to run, but always return back to the infinite loop.