What's the difference... FAT32 and USB host for ARM and PIC?

[Sparky1039]

What’s the difference?

Not knowing where to put this forum post I decided to place it here.

I have 5 USB flash drives of varying capacities. These are…
1. PNY Attache 128MB
2. Unknown brand 512MB
3. Unknown brand 1GB
4. Sandisk 4GB Cruser
5. PNY 16GB

All drives have been formatted to FAT32 as primary partitions, with 4kb cluster (except the 128MB which can only be 1K max) Each drive was loaded with a simple text file labeled “Test.txt” containing a few words.

I also own the EasyMx Pro V7 ARM development board using the STM32F107 processor, and the EasyPIC Fusion V7 with PIC24EP512GU810VG processor.
With each development board I have loaded the mE USB host examples (along with FAT32 library) and performed the minor modifications needed to work with the available processor. The code examples compile and work correctly for each platform.

Here are my problems. Using the above 5 USB flash drives the ARM code will mount and display FAT information for the 128MB, 1GB, and 4GB drives. If I apply modified example code I can also open and append text to the test file on these 3 drives. The 512MB and 16GB fail to connect and always present the “error” screen.

Now using the same drives the PIC24 will only mount and display the 128MB device. The other drives never show the “connect” prompt nor display any of the FAT information and for the most part appear to be “locked” up until I remove them. Again applying modified example code I can fully open and append text to the test file on the 128MB drive, but the other 4 drives fail to respond in any way.

Since the mE libraries are essentially “black box” code segments I have no way to troubleshoot what is going on inside these function calls. Essentially I have extremely limited access to determine the problem of why some drives work and others do not.
So my questions to mE are thus. Outside of the physical differences of the peripheral hardware…
1. What is different between the dsPIC and the ARM USB host and FAT32 libraries that would cause such wide variability in performance over 5 drives?
2. Are there timing elements within the library codes that are peripheral dependent and not documented?
3. Are there specific limitations to each processor type within the library code that are not documented?

I currently have a paying customer who’s project development has been halted by the poor and inconsistent performance of the USB host and FAT32 libraries. Much to my repeated objection they insisted that mikroC be the compiler of choice for their project development. So now I am stuck with unfinished code and possibly facing the cost of porting it over to another compiler (m-chip XC16). My greatest frustration is not knowing what to fix since I can’t see what is potentially broken or needs adjustment. I always expected that some USB drives would not work due the very nature of variability between manufacturers, but an 80% failure rate so far with the PIC24 is unworkable.

To the mE staff what can be done to help troubleshoot this problem? Any recommendations for me to try? Any possibility of obtaining the library source codes under NDA for troubleshooting?

[darko.minic]

Hi,

Thank you for detailed explanation of problem you have.

I talked with our Development Team about your problem.
Can you please send me your project so I can forward it to Development Team, so they can examine it?
If project is confidential you can send me that project via e-mail.

Regards,
Darko

[Sparky1039]

Darko,

There is really nothing to send to you. I have been working the mE code examples that come with the FAT32 and USB host Libstock files as the basis for my testing. I have not implemented FAT32 or USB host yet into my clients' the primary application because of it's complexity and size. My objective was to first test the functionality of these libraries separate in order to get a feel on how well the USB Host and FAT32 work with the PIC24EP512GU810 using various flash drives before I merged it into the application code.

Since the test results with the PIC24 were not very good I decided to try the ARM library versions to make a comparison. The results were significantly different as outlined in my previous post.
The interesting thing was when studying the ARM and PIC .c & .h library source files side by side a difference between them was noticed (outside of the hardware dependent elements). As an experiment I took the better working ARM code and ported it over to the PIC24 thinking it may improve the performance. The results were exactly the same, only one drive was accessible for mounting, reading, and writing (the 128MB drive). This was my "clue" that perhaps there are elements within the libraries that may need "tuning" because of the unique USB peripheral dependencies internal to the processor selected.

That said if you really want to see my test code for both ARM and PIC24 I'll post them. BTW my ARM and PIC24 compilers the the most current versions.

[darko.minic]

Hi,

Thank you for your observation.

I talked with my colleague from Software Department which is assigned to this task:
He will certainly investigate this problem a little bit further, and try various USB flash drives.

If there is problem with libraries we will do our best to provide revision of our libraries as soon as possible.

Regards,
Darko

[Sparky1039]

Darko,
Please feel free to have your colleague contact me offline via private mail for further information or assistance.
thx.

[darko.minic]

Hi,

I will notice my colleague and send him your e-mail.

Regards,
Darko

[Sparky1039]

Darko,
Just inquiring if there are any results from mE's investigations into the USB thumb drive variability between processor platforms? No one has contacted me yet offline regarding this subject. thx

[AndyIvan]

Hi all,

I am attempting the Host_MSC example with a few modifications to print status text to the USART Terminal instead of a TFT display, as it is easier. I have testing the attached code on 8 different USB flash drives and 4 work just fine, but the other 4 keep getting stuck in the fhandle = FAT32_Open(FileName, FILE_APPEND); command.

I am developing a product that logs sensor data to an MMC card and then needs to write the data onto a USB drive into a .txt or .csv file. I would be happy if 80-90% of the USB drives worked ok, but I am really worried about 50% of the USB drives not working. The USB drives that didn’t work were a mix of very old and brand new USB drives. They were all formatted FAT32 ranging in sizes (512Mb, 1Gb, 4Gb, 8Gb). Any help with the attached code would be greatly appreciated.

MCU: STM32F407VG
Dev.Board: EasyMx_PRO_v7_for_STM32_ARM
Oscillator: 120 MHz
SetUp: Load scheme STM32F407ZG_PLL_25_to_120MHZ_USB.cfgsch
SW: mikroC PRO for ARM

Kind regards, Andrew

[marina.petrovic]

Hi,

Unfortunately, I believe that this problem is related with very flash memory and FAT32 Library.
My colleagues from Software Department are already familiar with this problem and they will try to investigate it little bit further and try to find source of the problem.

I can give you some suggestions, maybe it can be helpful:
- first make sure that you labeled your flash drive (give some name to the flash drive)
- make sure that flash drive is properly formatted
- you can test some other formatting (partition) tool like MiniTool Partitioning Wizard 8
- it is very important that when you create new partitions use partition align to: cylinder

Best regards,
Marina

[hooper]

Hi,

Any news with this topic?
I expect ME to publish the solutions in the forum for the usage of the whole community...

I face the same problem (but with PIC32)
Followed Marina's advice and aligned the partition and gave the drive a label...
The results when running on EasyPIC Fusion v7 are:
some times it shows ERROR string on the display and
on other times it succeeds to display the directory files on the USB stick.

ME, do you have any suggestions? I can not deliver a board with such ambiguity to my client!!

[uros.cvetinovic]

Hi,

I believe I have answered you on your ticket on this subject.

We can continue our correspondence there.

Best regards,

Uros