How should we start with USB FS to read out a QSPI flash memory without filesystem on an STM32F7 device?

[Kevin Lehzen]

Hi there,

recently we successfully implemented our functions to read from and write to our QSPI NOR flash with an STM32F746VG customized board. Its working fine. From now on we also want to get the stored data via an windows application over USB from our device.

In my research I saw many developers use the USB middleware but this sounds like much overhead for our easy task. We do not need the mass storage class or anything like that. So is there a easier way with low level driver to just receive data from the STM32 chip via USB to the PC? Some example code would also be nice. I just found some for the middleware. Thanks in advance!

Best regards,

Kevin

[waclawek.jan]

> this sounds like much overhead for our easy task.

USB is complex.

JW

[Kevin Lehzen]

ok, guess I will go with the Middleware. But which class wuld be the best for our purpose? Technically its a mass storage device but we have no filesystem so we can not use it, right? In that case is there a class to just transfer blocks of data? Or am I understanding something wrong? Thanks!

[Tesla DeLorean]

Depends on how much code you want to write on the PC side, including​ drivers.

​

You could be a serial device and implement something with a Terminal and X-Modem to pull pseudo files​, or perhaps MTP, or a MSC that pretends to be a CDROM. Depends on if you're more comfortable for complexity on the embedded or PC side of the problem.

[Kevin Lehzen]

definitely embedded side

[Kevin Lehzen]

I was now thinking of adapting this example:

...\STM32Cube_FW_F7_V1.8.0\Projects\STM32746G-Discovery\Applications\USB_Device\MSC_Standalone

Instead of the SD card part of the code I want to use QSPI read and write functions like:

int8_t STORAGE_Write(uint8_t lun, uint8_t *buf, uint32_t blk_addr, uint16_t blk_len)
{
 int8_t ret = -1; 
 
 if(IS25_QSPI_IsDetected() != FLAH_NOT_PRESENT)
 {
	IS25_QSPI_Write_DMA((uint32_t *)buf, blk_addr, blk_len)
 //BSP_SD_WriteBlocks_DMA((uint32_t *)buf, blk_addr, blk_len);
 
 /* Wait for Tx Transfer completion */
 while (writestatus == 0)
 {
 }
 writestatus = 0;
 
 /* Wait until SD card is ready to use for new operation */
 while (IS25_QSPI_GetCardState() != FLASH_TRANSFER_OK)
 {
 }
 
 ret = 0;
 }
 return ret;
}

Would this be a feasible approach? As I read the only requirement for MSC are the block size and number.

Greetings,

Kevin

[Tesla DeLorean]

A PC is going to want to put a file system on there. Raw block access is possible but rather convoluted.​

[Kevin Lehzen]

So what would be the better way when more effort on embedded side is desired?

[Kevin Lehzen]

We also want to develop a windows app to read from and write to the flash on the device. Maybe we can just use the read and write functions of the MSC without formatting with the standard windows driver?

[Tesla DeLorean]

It's been a while since I did this, but it should be possible to open a connection to the driver, or raw drive and send IOCTL, IRP or URB to interact with it.

Presenting as a FAT file system volume would be the easiest to pull off, and be platform agnostic.

Being an MTP device would allow you to manage "files" without having a file system.

For large amounts of storage eMMC would likely be more efficient than NOR. The draw with QSPI is that you can map the memory for reading and execute-in-place, but writing and erasing tend to be slower and more involved.

With a serial CDC/VCP you can define your own protocols and interactions, baud rates don't really have any context in the virtual connection, so the data interactions can be quite rapid.