Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world.
And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download two short videos (registration required) highlighting:

System Workbench for STM32


USB FS Host , MSC class not starting under FreeRTOS..

Hi,

Hoping for some pointers on using the CubeMX generated middleware correctly (Im using NucleoF767ZI in this case). I’ve been trying to get the USB host with FatFS running under FreeRTOS and struggled.

Once debug was enabled I can see this much progress  ;

USB Device Attached
PID: 751h
VID: 5e3h
Address (#1) assigned.
Manufacturer : USB Storage
Product : USB Storage
Serial Number : N/A
Enumeration done.
This device has only 1 configuration.
Default configuration set.
Switching to Interface (#0)
Class  : 8h
SubClass : 6h
Protocol : 50h
MSC class started.

And it progresses no further. I can see that in usb_host.c , USBH_UserProcess() is called a couple of times but it does not reach the HOST_USER_CLASS_ACTIVE: state , which should be the triggger that I can try mount the drive etc.

So looks like the MSC class did not start up correclty. After some fiddling around I created a more basic project with or without FreeRTOS generated by CubeMX.
With the no RTOS project , the debug looks better, the MSC class is working this way ......

Main() started
USB Device Attached
PID: 751h
VID: 5e3h
Address (#1) assigned.
Manufacturer : USB Storage
Product : USB Storage
Serial Number : N/A
Enumeration done.
This device has only 1 configuration.
Default configuration set.
Switching to Interface (#0)
Class  : 8h
SubClass : 6h
Protocol : 50h
MSC class started.

Number of supported LUN: 1
LUN #0:
Inquiry Vendor  : Generic
Inquiry Product : STORAGE DEVICE
Inquiry Version : 1402
MSC Device ready
MSC Device capacity : 1990196736 Bytes
Block number : 3887103
Block Size  : 512

It pretty much does that out of the box, from a generated cubeMX project including USB FS host, MSC class and FatFS (no FreeRTOS). The only thing to add was enabling printf() output , and flip the direction of the USB power control pin (cubeMX ouput for Nucleo F767ZI with FW1.40 does SET GPIOG 6 when it should be RESET and vice versa)

I have to be missing something here, the FreeRTOS project looks also like its set up ready to go and starts that way but stalls.

Maybe someone bumped into the same issue before, has an idea what could be causing it or how to debug further? I tried looking in the MSC class (usbh_msc.c) and saw a function looking like it should be being called USBH_MSC_Process() , but its never fired.

any thoughts appreciated!

thanks,
vik

France

Hi Vik,

Just a thought: did you create a “main” task and start the scheduler? I presume the MSC class is expected to run in a FreeRTOS task while the initialisation is done from th emain function, so if you do not start the scheduler, you will not get the class running...

Hope this helps,

Bernard (Ac6)

hi bernard,

yes, the scheduler is started in main() , and begins a startTask() wihch does the job of init of FAT FS , USB host etc, during which the log output is generated.

breakpointing around a little more last night I could see that in usb_core.c , the USBH_Process() is being called and progresses OK, USb attachement, enumeration etc as indicated in the logs, as far as reporting “MSC class started”.

After this it keeps coming back to line 559 - if(status == USBH_OK) never resolves since it remains USBH_BUSY

case HOST_CLASS_REQUEST:
/* process class standard control requests state machine */
if(phost->pActiveClass != NULL)
{
status = phost->pActiveClass->Requests(phost);

if(status == USBH_OK)
{
phost->gState = HOST_CLASS;
}
}
else
{
phost->gState = HOST_ABORT_STATE;
USBH_ErrLog (“Invalid Class Driver.”);

  1. if (USBH_USE_OS == 1)

osMessagePut ( phost->os_event, USBH_STATE_CHANGED_EVENT, 0);

  1. endif

}

break;


Managed to work it out in the end - it was the inclusion of printf support that was causing the grief :-( Im wondering if best to avoid printf in RTOS environment, and using alternate debug output to uart is better.
The way it was implemented anyway was very simple HAL UART send with a timeout , char by char. So, not great. I’ll come back to it after having improved..re-setup with DMA’s for the uarts and a housekeeping task that can receive debug events and stick them on the send buffer. Hopefully that way it will be stable to debug-out safely whilst not impact the rest of everything badly.