I resolve apparently this problem when change the structure FAT16_BootSector FAT16 to FAT32. I don't know if this is correct but I´m testing the system. Inclusive Ubuntu Linux recongnize the memory normaly in the system.
The differences between FAT16 and FAT32, we can see in the next file: http://www.writeblocked.org/resources/FAT_cheatsheet.pdf
I want our opionion and dereksnell.
I work whit 51JM128, AN3927 USB MSD Bootloader.
FAT32 has licensing issues from Microsoft that the lower FATs do not have.
Bob
FAT12/FAT16/FAT32 are open and have no licensing issues - it is only if LFN (long file names) are used, which is the same with FAT12/16 or 32. In fact it is the write part that is patented and so needs to be licensed; reading is not an issue. Linux works around this by not using the same backward-compatible technique, which is generally not an issue nowadays since it is unlikely that pre-LFN systems need to be used. I believe this is the original source of the workaround: https://lkml.org/lkml/2009/6/26/314
SREC operation on Win8, Win10, MAC is not usually an issue - it is more complicated when working with binary files.
The uTasker Kinetis project solves this for all Kinetis parts USB-MSD loading:
http://www.utasker.com/kinetis.html
here is a discussion of the techniques used to ensure compatibility with all Windows versions, MAC and Linux:
http://www.utasker.com/kinetis/USB-MSD-MAC.html
Regards
Mark
I will endeavor to be more accurate in the future.
To me LFN is implied with FAT32.
'...patents in question are #5,579,517 and #5,758,352 which cover techniques for implementing a "common name space for long and short filenames."'
Microsoft suit over FAT patents could open OSS Pandora’s Box | Ars Technica
Microsoft licenses out exFAT file system | Ars Technica for $300,000.
Details on FAT with legal updates in 2011:
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc
Bob
I think that FAT32 is older than LFN, which is also used with FAT12 and FAT16. LFN in fact has nothing to do with the FAT12/16/32 part because FAT12/16/32 specified mainly how the clusters are stored and not how the files are managed. LFN is a part of file management which is identical to all.
Regards
Mark
It works in Windows 8.0, but not Windows 8.1. You need to make a change to SCSIList2A() in SCSI_Process.c to get it to work for Windows 8.1.
As written, SCSIList2A() assumes that all writes to the data sector will be an S19 file. Windows 8.1 tries to write some data to the data sector every time it is connected, so it erroneously thinks that this is part of the S19 file. You need to add a check to SCSIList2A() to check and makes sure the incoming data is part of an S19 file.
Also, you can try the steps in this link to disable the Windows 8.1 feature that is causing the bootloader to fail in the first place:
How do I prevent system volume information files from showing up in my - Microsoft Community
My S19 files always start with "S003", so I wrote a simple check in SCSIList2A(void) to check for this:
void SCSIList2A(void)
{
.
.
.
if(S19FileDone) {
while(!BlockWriteDone) { // Receive all USB data
if((v_LBA >= FATDataSec0)
&& ((BootloaderStatus == BootloaderReady) || (BootloaderStatus == BootloaderStarted))) // Host writing first file to Data sector of drive
{
SRecCharPointer = SRecBufferAddress;
if (GetUSBchar() == 'S' &&
GetUSBchar() == '0' &&
GetUSBchar() == '0' &&
GetUSBchar() == '3')
{
S19FileDone = FALSE;
return;
}
else
{
GetUSBOutFileData(); // Host trying to write to data sector or non S19 file
}
} else // Host trying to write to FAT table
GetUSBOutFileData();
}
.
.
.
}
I had to include ParseS19.h and make SRecCharPointer an extern to get it all to compile