FatFS Partition issues

Can you post screenshot of diskmgmt.msc showing your pendrive partitions?

Regards,
Maciej

The partition Windows sees has one directory and one sub-directory, with 7 files in the sub-dir that I created in Windows:  \TestDir\TestSubDir\

The partition my board sees has one directory and one sub-dir, with 2 files in the sub-dir that the board created:  \LINCOLN\MEMORIES\

Disk 1 is the USB drive -- it is a SanDisk Cruzer 4GB drive, USB 2.0, and it's brand new.  As you can see below, Disk Management only sees one partition on the USB drive.  I've tried this on other USB drives as well -- some have this problem, and some work correctly (the partition the board sees is the partition Windows sees).

Sorry but I have no idea what is going on there. If I were you I would open pendrive in hex editor and try to figure out what is the difference between windows data and "embedded" data. 

The partition shown by Disk Management seems to be the only one.

Hi Mitchell,

I also can't pin-point why only "certain" drives are showing this behavior.

Have you tried to re-format the USB drive? You can reformat it using window's format tool (just don't do the quick format). Does your drive have some "special" features, such as encryption and stuff like that?

I haven't tried this, but you could also try to use the FatFs API's directly to format the drive by using f_mkfs(). The "FatSD Raw" example shows how to use the FatFs APIs directly without C standard I/O APIs.

If that doesn't work, it may be a USB related issue...

Unfortunately, yes, I have tried reformatting through Windows, and that has not fixed the issue.  And no, my drive does not have any "special features".

I don't think f_mkfs() will solve my problem -- Windows is putting the FAT (or FAT32, I've tried both) file system onto the drive, so f_mkfs() is not required.  From my understanding, f_mkfs() creates a new partition on my drive, which is not what I want to do.  I'd like to be able to use a drive with an existing file system.

Thanks for the suggestions.

I'm thinking my issue may be with the USBMSCHFatFs driver -- the problem seems to happen more frequently when I use multiple USB drives, e.g. I have a USB drive plugged in, I remove it, and then I plug in a different USB drive.  It's possible restarting the driver may help with the problem -- maybe the driver is holding onto information from the first USB drive, and using it on the second USB drive, causing it to read incorrectly.

Hi Mitch,

can you see if the USB drives work with the StellarisWare "usb_host_msc" example? There is an example for the LM3S9D92 (LM3S9B92 should also work). It would be extremely helpful in determining if the USBMSCHFatFs driver is causing this or if the underlying USB stack can't support certain USB drives...

Mitchell Rackovan said:

I was able to solve the issue I was seeing.  When a USB drive is unplugged from the system, I had to close the USBMSCHFatFs driver, delete the Hwi for INT_USB0, and re-open the driver.  It then waits for a new USB drive to be connected with "waitForConnect".  I seems I was correct in thinking the driver was holding onto information from the last USB drive.

//Unmount drive and close driver
USBMSCHFatFs_close(usbmschfatfsHandle);

//Delete USB Hwi (recreated in USBMSCHFatFs_open)
temp_hwi = Hwi_getHandle(INT_USB0);
Hwi_delete(&temp_hwi);

//Open driver and mount drive
usbmschfatfsHandle = USBMSCHFatFs_open(USBMSCHFatFs0, USB_DRIVE_NUM, &usbmschfatfsParams);

Mitchell,

This is great. Thank you for posting answer! 

Regards,
Maciej 

Hi Mitch,

I've submitted a bug ID to track the issue of the driver not removing the hwi (SDOCM00100492).

After giving your partitioning problem some more thought, I think you are right and I might have found the problem in the driver. I'm suspecting that one of the FatFs disk functions isn't returning the correct return code to tell FatFs to reinitialize the media after the USB drive was removed. It's too early to confirm if that's really the issue, but I have also filed a bug ID to track this (SDOCM00100493).

Thanks Tom!

I'll keep an eye on those bug IDs.

I am using the Tiva TM4C123GH6PGE and I dont see a Hwi_getHandle function - were is this located?

Hi Teresa Ainsworth,

What version of TI-RTOS are you using?

The problem should be fixed in the latest release (version 1.20):

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/1_20_00_28/index_FDS.html

Steve

Teresa Ainsworth said:

I am using the Tiva TM4C123GH6PGE and I dont see a Hwi_getHandle function - were is this located?

Teresa,

As Steve said, this problem is fixed in the newest release of TI-RTOS (I saw the fix in the release notes) -- so there is no need to use the workaround I posted here.  However, to answer your question, the Hwi_getHandle function is defined in Hwi.h (I'm using the Stellaris M3 specific Hwi.h).

Mitch

I have upgraded my TI-RTOS to version 1_20_00_28 , XDCTool 3_25_04_88, TivaWare_C_Series-2.0b and I still have the same problem when I run fatsdusbcopy_TivaTM4C123GH6PGE.

It works fine the first time and if I unplug the USB stick and plug back in and then run the code I get

ti.sysbios.family.arm.m3.Hwi: line 1140: E_noIsr: id = 60, pc = 00000000

Bogus Exception return value: 00001057.

Core 0: Exception occurred in ThreadType_Hwi.

Hwi name: {unknown-instance-name}, handle: 0x0.

Hwi stack base: 0x20004e80.

Hwi stack size: 0x1000.

R0 = 0x00000000  R8  = 0x00013d28

R1 = 0x000029d1  R9  = 0x00013ab4

R2 = 0x00000000  R10 = 0x00013ac0

R3 = 0x00000000  R11 = 0x00000000

R4 = 0x20002c00  R12 = 0x00000000

R5 = 0x00000038  SP(R13) = 0x200009c8

R6 = 0x40050000  LR(R14) = 0x00000000

R7 = 0x00013ab0  PC(R15) = 0x00000000

PSR = 0x00000000

ICSR = 0x0042383c

MMFSR = 0x00

BFSR = 0x00

UFSR = 0x0000

HFSR = 0x00000000

DFSR = 0x0000000b

MMAR = 0xe000ed34

BFAR = 0xe000ed38

AFSR = 0x00000000

Terminating execution...

 Then if I run the code again it all works fine.

Hmm, well I'm not sure why you would be receiving a Hwi exception.  I've confirmed that the issue I was having originally in this thread has been fixed with the newest version of TI-RTOS, so what you're seeing may be a different issue entirely.

What does your code do when a USB drive is unplugged?  Do you shut down the USBMSCHFatFs driver and re-open it?

The code I am running is actually from the TI Resouce exampels for the Tiva series I am using. What it does it takes a file form the SD card and copies to the USB stick and then the code exits. It closes the driver before exiting. Then I unplug and plug the USB stick back in and when I run it this time I get the hwi exception when I call he open function.

I'm not sure that code is meant to be run twice, since Bios_exit() is at the end of the task that does all the work (at least for my Stellaris "fatsdusbcopy" example, which is what I'm guessing you're referencing).  But at the same time, I couldn't tell you why it wouldn't work -- my code does the same function calls as the example.  My code is pretty simple and I don't see the problem you have:

Initialization (start-up sequence for chip)

USBMSCHFatFs_open (opens FatFs MSC driver)

USBMSCHFatFs_waitForConnect (waits for USB drive to be plugged in)

[file i/o calls available when USB drive plugged in]

Then, when a USB drive is unplugged:

USBMSCHFatFs_close (closes FatFs MSC driver)

USBMSCHFatFs_open (opens FatFs MSC driver)

USBMSCHFatFs_waitForConnect (waits for USB drive to be plugged in)

As long as you follow that basic structure, the USB MSCH FatFs driver shouldn't cause you any problems.  Can you look up a debugger and see what function is causing the Hwi exception?

How does the software detect that the USB has been unplugged?

USBMSCHFatFs_waitForConnect will return whether or not a drive is mounted.  I have that function call at the top of a while loop, and based on the return of that function and the current state of some variables, I go into other operations.  E.g. if the waitForConnect returns FALSE, but the last time through my while loop it returned TRUE, then I know a USB drive has been unplugged and I want to close and re-open the driver.

Michell thanks for the help. I got it going today. One reason I think is that when I updated to the latest version of the RTOS it had an empty project in there for the DK-TM4C123G series. I did not see this yesterday but today when i was search for the GPIO_Callbacks since a variable was added to the structure I found it.

Have you found that all USB memory sticks work for you? We are having a debate at work whether USB stick should be supported in a embedded system since not all sticks seem to conform to a standard.

No problem.  Right now, I have not run into a USB drive that has not worked -- although that's not to say they work every time.  Some issues I've run into:

- Some USB drives are much slower than others, so if you have any time-sensitive reads or writes, you must take this into account.  I've seen a mkdir call take almost 10 seconds on an almost-full 32GB drive (must take a while to find a free sector).  Speed seems to depend on protocol, obviously (USB v1/2/3), manufacturer, and size of the drive.

- Some USB drives were causing a "reset" or "babble" interrupt on connections/disconnections, causing the Stellaris to switch from Host to Device mode, even though I wasn't using OTG functionality.  More on this here, and the workaround I used:  http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/p/303822/1080425.aspx

- I've seen random lockups of the Stellaris (once a month or so) with USB drives I use regularly (and successfully) with my board.  I'm yet to catch this with a debugger available, so I'm not sure what is causing this, but it is a concern of mine.

I'm yet to find a USB drive that absolutely doesn't work.  In my opinion though, with the memory constraints of an embedded system, as long as most drives work, that's a successful implementation of USB functionality.