I need help configuring FatFS with Portenta to allow for exFAT. i found these settings in mbed_config.h however i'm not exactly sure if i am suppose to edit them here or elsewhere and not aexactly sure which settings to change to support exFAT. below are the settings, has anyone had luck with this. any help would be greatly appreciated, thanks!
Thanks Steve! i am going to try this now. if this doesn't work i am starting to convince myself that there is a bug in FatFs and it might be fixed in newer version but i believe that libmbed.a uses a version of fatfs that is v14b which is ~4 years old and v15a is out now and might actually fix my problem. I am trying to write many files say about 16MB in size to an SD card in the portenta breakout uSD slot which uses SDMMCBlockDevice lib and FatFs. i am using a 32GB uSD card formatted with the SDFormatter to FAT32. i am writing into a sub directory and not the root. when i get to qty=256 of size=16MB files it fails to write any more files and the filesystem is corrupted at that point. if i stop at 255 files all is good. and if i change to any combination of size and qty that adds up to 4GB of storage on a 32BG card i get the same failure. so the failure is some how caused by trying to go over 4GB. I know that FAT32 doesn't support any single file greater than 4GB but i am writing multiple small files so i don't know why this should be a problem. also i wrote a simple C program on my linux laptop that filled the same card with 16MB files and there was no issue at all. so at this point i really believe it is the FatFs library that is the problem and it could very well be fixed now. i wish i could just put the source code for the new version of fatfs in my sketch folder and give it a whirl. but let me try your suggestion above and see what happens. if you think it would be helpful to help me diagnose this i can supply my code but there are a ton of serial.print debug statements. let me know. and if you or anyone else could whip up your on test to see if you can go beyond qty=256 size=16MB files it would be greatly appreciated.
Thanks again!
Cheers,
Jeff
wondering if anyone has already recompiled for exFAT support and could post a .zip?
or even better if re-compiled for exFAT and with the latest greatest version from FF chan which i think is version 15a
Hi Jeff, I don't have a Portenta, I have the GIGA, but I do use ChaN FATFileSystem to write logs to a USB-A thumb drive via the GIGA's onboard USB host.
I ran a test overnight writing 16MB files to a sub-directory. I pulled the plus this morning after it had done 400 files.
All files written as expected and no failures or corruption. This was using FAT, not exFAT, so I therefore suspect your issue isn't within the file system.
thanks Steve. is there any way for you to tell which version of fat fs you are using and would you be able to share your ffconfig.h settings?
i feel like it could be what version and default config they compiled for default portenta setup
i doubt it matters but i am using SDMMCBlockDevice and FatFileSystem provided with Portenta and the card is plugged into portenta breakout board sd slot and it is a 32GB card formatted as FAT32.
i believe the chan fatfs they used was from like 4 years ago
thanks so much for getting back to me i have been pulling my hair out on this for like 3 weeks. writing to the card with no fs just as a blockdevice works perfectly
The only override of the default ffconfig that I'm using is "fat_chan.ff_fs_lock": 2,
Looking at the mbed_app for the Portenta, I don't see any storage related differences with the GIGA.
My guess would be that the problem is down to the initialisation of High Capacity cards. I would raise a git issue against ArduinoCore-mbed GitHub · Where software is built
Thanks again Steve! this is all very much appreciated. seems like you have the same version of fatfs that they are using for Portenta. i am wondering what size card you are using because you were able to get over 6GB on your card. is it perhaps an 8GB card? for my potential use case i need to get roughly 2MB/sec throughput to the card. you mentioned that you let your test run overnight. i wonder if the rate that i am pushing data on to the card is a factor? I've tried 8GB, 32GB, 256GB and 1TB cards and have seen the issue with all of them but i am pushing data pretty fast. it takes less than 2 hours to get to a failure in my case. but it is always at the 4GB mark and my standard test is with 16MB files off the root in a subdir.
also can you tell me. overriding some of the chan ff #defines at the top of my file does nothing when i compile? the only way to effect change is to re-compile the mbed libmbed.a file? is this correct? why did Arduino make this so hard to get down into things on this board. have you had success re-compiling for your board? i wish i could just get Arduino to make a new version of the lib with the new chan fs and try it out. now i have to trouble shoot another thing in re-compiling the lib on my laptop to get to the bottom of this.
it also seems like the forum is kinda quiet for the Portenta. maybe not as much buy in for this board as they hoped and i read a lot of complaints about the use of mbed. i looked into the portenta because my application has to be able to read 8 channels of 24 bit ADC data at 40khz continuously which is close to 1MB/sec in and i need to write it out at say 2MB/sec so that i have a little cushion. i need to be able to support many TB of data. perhaps 16TB over the course of a year of logging on the seafloor. i am using the M7 core to take in the data and the M4 core to write out the data. i am also using the 8MB of SDRAM as a shared ring buffer between the 2 cores. i have a flag system between the cores that tells the M4 when to offload one half or the other of the buffer. anyway... there are a few question about your setup above but in general i am really thankful for your input and help.
Cheers,
Jeff
oh and yes i will raise a git issue as you recommend and see where that goes. i guess i was still a little puzzled that you got 6GB on a card. wondering if the lock setting you changed is the key???
thanks again!
Not a card Jeff, a USB-A 64GB thumb drive on a GIGA R1 Wifi board. So a very different setup to yours but we had chaN FAT and mbed-os in common and I thought the results might shed some light.
The GIGA USB writes are painfully slow - plenty of posts about that! I get roughly 200KB/sec hence the overnight run. However, my logging demands are quite low so using the onboard port saved having one more external device.
Afraid so. They're pulled in at compile time for the libmbed.a.
mbed RTOS for the STM32 MCUs existed so quicker time to market I guess. Most people run with the defaults used in lib so long compile times for the Arduino layer is usually the only complaint. I do use a lot of the mbed functions directly and have considered removing the Arduino layer, but that's a big job. As mbed is EOL they're working on a switch to Zephyr.
Yes, but it took me days to get it to work for the GIGA as I hadn't done much with Linux before. Getting the python stuff installed and working with the build script was really painful. IMHO it's worth trying though as there's quite a few things I've tweaked.
The GIGA and OPTA are fairly quiet too. The boards share some common features so I tend to chip in when I think it may be relevant.
I'm doing something very similar to write my logging data to the USB drive. I'm using the SRAM3 shared memory area rather than SDRAM as I found it faster.
I made that lock change so that I could read from a file with one pointer while writing to it using another. Didn't work that reliably so I now pause writing when reading but haven't backed out the lock change.
Wow!, thanks so much Steve! i can't tell you how nice it is to talk to a human being about this stuff. i feel like i was starting to lose my mind talking to ChatGPT about this stuff.
I guess I'm off on another odyssey trying to re-compile the libmbed.a
joy!
side note, just writing to the card as a block device is kinda nice. no worries about the filesystem getting corrupted and losing a terabyte worth of data. it comes off the card at 50MB/sec on my laptop as i use dd to split it into 16 MB files. it's actually pretty cool. i'm not sure what the downside is? do you know of any nasty caveats?
I've used raw devices many times over the years with mainframes, minis, servers and currently embedded (using some of the QSPI raw). Often the cleanest (and fastest) approach if you don't need any of the features of an fs and you plan to code for that yourself.
steve, i believe the portenta comes out of the box with its clocks turned down to present a less power hungry system to most people. i use this file from another user with this line of code but it only brings my SDMMC clock up to 8Mhz from 6.67Mhz. i read somewhere that i should be able to go at 25Mhz
here is the line i use in conjunction with the attached file
do you know or understand how i might bring this clock frequency up to say 16Mhz or even 25Mhz?
no worries either way. i posted a message awhile ago but no takers.
with an oscope write on the clk pin just in front of the uSD slot on the portenta breakout board. it reads 8Mhz and the write speeds reflect this.
i will look at the BSP file too. Thanks!
Steve, another thing i need to do is see if i can log data at high rates to a USB drive or thumb drive. they seem to bring out USB full speed but i need USB high speed. i was thinking i could move console port off the USBC connector on the H7 and plug USB drive in there but it doesn't recognize it. i know you board is a little different but do you know where i need to start digging to be able to hang a USB drive off the high speed USB bus and is this also going to require a re-compile?
nice and unequivocal, good to see you're tooled-up.
Arduino seem fairly adamant that the USBC is for Serial monitor and programming only i.e. not as host - it may not provide sufficient power. I've not explored this assertion as the USBA port was sufficient for my needs. Very slow, but reliable for me (if using a compatible thumb drive).
To act as a USB Host, the arduino-libraries/Arduino_USBHostMbed5 is typically used. We're on mbed-os 6. Arm decided to not carry this code forward from 5 to 6. Arduino forked it and it works, sort off, some times on the GIGA, OPTA, Portenta etc.
I've spent quite some time looking at the code and, without starting from basics i.e. the usb standards, it's beyond me.
For USBA, most likely not, for USBC it may not be feasible. I'd stick with the SD card unless you have a lot of time to spare.
thanks Steve. i am laughing at myself writing 'write' where i meant to say 'right'. i guess i have writing on the brain from all the work I've been doing with the card writing
understood on the USBC connector but i am looking at the portena breakout and next to the USBA connector there are pads for USB0 and USB1 and on the schematic i see USB high speed and USB full speed.
i would like to try out USB high speed but i am not sure how to enable this. again, i feel like they did us a disservice hiding some of these options behind pre-compiled libs and what not if that is how this would get enabled. pg 2 of ABX00045 schematic in the upper right. see attached schematics/docs. do i need to change anything or can i change anything to be able to use the USB1 pads to a USBA jack with a thumbdrive at USB hig speed speds and not USB full speed speeds???
