FatFs - not reading Boot Record, USB boot loader

[Cdn_aye]

Hi

I am using the code base from AN4368 for the USB MFS bootloader.

For some reason I am not getting the boot record being read. I return from the check_fs(...), with a fmt = 2, or no file system found.

This happens because the field a 510 is supposed to be 0xAA55; which it is when I look at the boot record; I can see at offset 510 = 0x55AA

But in the fs structure I get 0x000 at 510

    if (disk_read(fs->drv, fs->win, sect, 1) != RES_OK) /* Load boot record */

    if (LD_WORD(&fs->win[BS_55AA]) != 0xAA55)       /* Check record signature (always placed at offset 510 even if the sector size is >512) */

        return 2;

The disk is formatted as fat32. I did note in the comments of ffconf.h that if the code page index is wrong, a file open failure will occur, which is what I am getting. The code page currently is #define _CODE_PAGE  1258, Vietnam

If I set _CODE_PAGE to 437, US I get a compile error. I think I have to change other modules as well.

My question is, do we have to bother with the Language? Will this make a difference and is it the cause of block 0 being read is wrong?

The drive is formatted as FAT32 and windows doesn't report any errors.

thanks

Robert

Message was edited by: Robert Lewis Well I just tried a different flash drive and it works as expected; that is the boot record is correct. I never tried this before because I replaced the last drive with this one because it was getting errors in the main app. The problem is, the current flash drive that I was using was consistently working with the MQX USB MFS stack in the main app. The flashdrive I just got to work was pulled because it would fail during writes in the main app. So now I have a problem... the failed drive(not working correctly in the main app) works in the bootloader. The working drive in the main app, fails in the bootloader...could this be related to the bootloader USB stack?. I know that the USB stack was improved under mqx 4.0... should I try and move the code from mqx into the boot loader. If anyone has a suggestion it would be appreciated. I don't want to deal with restructuring the boot loader right now. Thanks Robert

[Martin_]

Hi Robert,

I can share my user experience with AN4368SW. It seems the code is based on USB bare metal stack, some earlier version. I met several usb flash drives that failed to enumerate or mount file system with the original AN4368SW. So I upgraded the AN4368SW with the USB bare metal stack 4.0.3 (and moved to CodeWarrior 10.3) and with this upgrade, the flash drives that didn't work with the original AN4368SW started to work with the updated version of AN4368SW. I have attached it for your test.

[Cdn_aye]

Hi Martin

I merged the code but still no success. The boot loader works on one stick, not the other. The app works on the stick the boot loader fails on, the boot loader works on the stick the app fails on.

I will check your USB modules with the latest I have from the 4.0.1 beta 3 and report back.

Thanks

Robert

[Martin_]

I just found there is brand new USB bare metal stack V4.1.1

USB Stack Product Summary Page

In the release notes of this software, there is chapter 4 "Known Issues and Limitations":

<--

Regarding the usage of USB flash drives with the FAT File System MSD host projects, there have been issues reported, unrelated to the USB stack, for various such commercially available devices, such as:

o Non-strict conformance to the USB MSD class

o Non-strict conformance to the FAT format specification, for instance in the BIOS parameter block, the boot signature (offset 0x1FE) may differ from 0xAA55 or the "FAT" string may differ for FAT12/16 (offset 0x36) or for FAT32 (0x52)

o Hidden partitions at the beginning of the memory space

o Non-strict conformance to the 500 milliseconds device readiness before the host polls it requirement in the USB 2.0 specification

o U3 smart USB drives are not supported

-->

Seems like the FAT table on your usb stick is non-strict conformant to FAT format specification. There are tools to create new disk images including FAT (like "winimage" What is WinImage) perhaps you can use this to change the FAT table on the usb stick to make it work with the bare metal usb stack (bootloader).

[nmay]

I've got the same problem as described here where a flash drive is installed into the DEMO JM board with my code running.  I'm using the 4.0.3 version of the USB stack.  When the flash drive is attached, the f_getfree() routine was failing.  I noticed that if I call it twice, the second time it would work.  Probing further down the line I found that the read from the USB drive boot record needed a dummy read before the access would work.  Patterns in the boot record (such as the 0xaa55) would be incorrect the first time and correct the 2nd time.

Moving down the call chain, I got to ff.c in the check_fs() routine.  I duplicated the disk_read and that was enough to make my system not fail on the first f_getfree call.  I can still move down a few more routines.  It could be something to do with the coordination of the callback routines or the need for the ioctl?

--Norm

[Cdn_aye]

I see your using the JM board and we're using the kenetis now, but we also had exactly the same experiences as you on a custom 51jm128 board.

My conclusions are similar to yours regarding the timing. I think that the USB stack has timing problems in some parts of a code. Either it is not waiting long enough and/or it is not accounting for all the return status's properly with proper exception handling.

All USB sticks we have work on Windows and IOS, but the same USB sticks may or may not work under MQX. Some work on the boot loader others only on the app.

As per my post above the MFS works consistently but the USB stack does not.

We don't see how we will release our product to the customer with this kind of reliability. If you find out any solution we would really appreciate knowing.

[Cdn_aye]

Hi Martin

Thank you for the link, I will test that and report back.

Regarding non-conforming FAT tables, I understand and agree... but the problem is that both USB sticks are formatted on the same windows 7 system. I copy the image.s19 file to both sticks and the bare metal system works on one stick but not the other. I then use the same two sticks in the app running mqx and the opposite stick works but the other one doesn't. Hence my assumption that the boot loader in the mqx components USB need updating.

I realize there is a second variable here that might be  a potential problem. The FAT MFS system in the app is MQX, but the FAT MFS in the boot loader is FATFS from the open source forum (CHan). But even so the only common component that seems to not work here is the USB driver which is MQX on both systems.

Regards

Robert

[Cdn_aye]

Hi Martin

I will upgrade this and report back the results. This really had me worried... without a reliable, repeatable USB stack, the whole product is a dead loss. The customer cannot be expected to find working flash drives.

Thank you very much

Robert