write sequence of 512 byte MSC blocks mixed up? writing less than expected?

[caipifrosch]

Operating System

Windows 10

Board

custom LPC1788

Firmware

custom firmware

What happened ?

TinyUSB with msc example got configured with 48 msc_disk[] blocks, 512 bytes each. Adding up to 24kB in total.

Writing a 16k file will start on SRAM memory blocks msc_disk[6] to msc_disk[21], then proceeds writing on block msc_disk[3] to msc_disk[5].

First: written blocks are less than 16kB (reading back file shows missing bytes as undefined, see screenshot)

Second: would have expected writing 32 blocks starting at msc_disk[3]

How to reproduce ?

1. use tinyusb msc example
2. redefine tinyusb msc size
3. use file explorer to write 16k byte file to msc
4. use debugger to view sram content (OR check file with hex editor)

Debug Log

No response

Screenshots

[hathach]

hmm, I have a feeling this may not be TinyUSB bug at all. It probably has something to do with FAT FS. The msc ramdisk example is a quick hack. You probably need to have a better fatfs implementation. TinyUSB work well with elm-chan fatfs on actual flash device and ghostfast (virtual fs) https://github.com/adafruit/tinyuf2/blob/master/src/ghostfat.c.

However, lpc1788 isn't used much, It could be lpc1788 specific issue. Can you try to enable the LOG=3 to see if there is any abnormal in the output. Also provide your modified example e.g cdc_msc_modified.zip along with your 16k file used to reproduce the issue. I will give it a try when having time.

[caipifrosch]

Same with me. I suspect it in the msc example source as well. Today I will step throu the code and set some breakpoints in order to see how block number sequence is generated and why not all of them are written.

[hathach]

Do you happen to have any samd21/51 or nrf52, pico boards to test with. Those are most used and tested mcus, just to rule out lpc1788 specific issue. Note: If you need my help to test this, please attach

• modified example of cdc_msc
• your 16KB file that is used to write to the disk

Note: I forgot to mention, the ramdisk example have 1 cluser = 1 sector = 512 bytes, you need to keep it in mind when inteprete the fat data, and need to make sure the total data (file payload + overhead) is not exceed the total size. Maybe try to inrease the ramdisk size to 32KB for a quick test.

  //------------- Block0: Boot Sector -------------//
  // byte_per_sector    = DISK_BLOCK_SIZE; fat12_sector_num_16  = DISK_BLOCK_NUM;
  // sector_per_cluster = 1; reserved_sectors = 1;
  // fat_num            = 1; fat12_root_entry_num = 16;
  // sector_per_fat     = 1; sector_per_track = 1; head_num = 1; hidden_sectors = 0;
  // drive_number       = 0x80; media_type = 0xf8; extended_boot_signature = 0x29;
  // filesystem_type    = "FAT12   "; volume_serial_number = 0x1234; volume_label = "TinyUSB MSC";
  // FAT magic code at offset 510-511

[caipifrosch]

Thanks for picking this up. There is not enough ram to further increase ramdisk.

But after some debugging with 512byte sectors I can say:

1. all sectors are written to 24kB ramdisk now
2. unfortunately ramdisk is still starting 1st file at ramDisk sector 6
3. missing sectors in flash are related to an LPC ram to flash copy problem (IAP copy function raises source address problem, probably because of some AHB peripheral blocking its access)

Because of point 3, I decided to completely change approach. Instead of mirroring flash to ramdisk and vice versa, the LPC will directly read/write 4094 byte flash blocks (size given by lower LPC flash sectors).

Unfortunately MSC will not correctly show up in windows. I do see the drive, but name is not visible. Debugger tells me that USB buffer gets loaded from flash boot sector correctly.

I certainly increased block size (FAT bytes 11/12 to 0x10/0x00) and moved magic code to bytes 4095 and 4096, but my FAT knowledge might be limited and I do miss something here...

[caipifrosch]

Drive size is reported 0kb when using 4kB sectors with following FAT12 setting:

[hathach]

after reading your update, I am absolutely sure that this is purely application issue regarding the Fat filesystem which is not an USB bug. Since it is not within the scope of usb stack, I will move this to discussion, maybe there is other people with more FAT knowledge could help.