• Please review our updated Terms and Rules here

partition tools

I never had any luck with Gparted, Certainly not with flash drive's / CF or the SD cards i have, Can't remember if i tried it on spinning rust, I always used Partition Magic.
 
The ONLY time I've ever had a problem with Gparted, is when I had a blown USB Flash Drive. Gparted would not work.
Neither would Partition Magic, or the HP USB Format Utility. I sent the defective CENTON USB drive back for replacement.

I'd try Gparted & Clonezilla, same as Chuck(G) stated.

Larry
 
Chuck(G) said:
Isn't the BluePill STM32F103?

I've seen similar effects on the 407 using my own SDCard I/O. But you're probably using SPI mode, where I'm using the builtin SDIO controller. Most of my issues were timing (I was using DMA for I/O) on multi sector writes.

If you don't mind reading C, I can pass you a copy of my SD SPI I/O for the 103.
Click to expand...

I don't think it is my SPI ( which I've removed several issues with hanging from, related to the initialization of the SPI ). From the F103, I've not even done a single write. I find it quite improbable that I could have made what looks like a directory entry in exactly a directory 32 bytes when all I've done is read sectors so far. It has to be something that windows, with some intent, wrote to those entries.
As for the SPI, the biggest problem is that it likes to hang on initialization. I have analyzed it enough to understand it and work around it. When it first initialized, there is a race that the controller hasn't yet figured out what mode it is in. It causes it to give an error ( I forget which ) that will lock the SPI up until cleared. I've got the init working 100% running at 125KHz before I switch to 10Mhz ( SD cards are class ten ) although, for this part of the experiment I've been at 125Khz the entire time.
It is quite unlikely that my end could somehow figure out what bytes to write to the directory and put what looks like fragments of my data in those locations, without damaging the other parts of the directory. It has to be something that is reading the directory block out, modifying the entries and then writing them back in. Since I'm not even loading that part of the code yet, it would be almost impossible for the F103 to be clever enough to do it on its own. It is possible that it is a bug in windows. If I can't find a modified boot sector and I've already examined my files ( .LST, .TXT and .HEX names ), I'll assume it is just a feature in windows7.
I'd still be interested in seeing your code. I'll be gone for the next 2 weeks ( leaving thurs ) and will only be occasionally reading mail. I don't mind the 32K cluster sizes I'm working with as the disk images will be 39420 bytes ( no wasted space. )
Thanks for the thoughts
When I get back I'll attack the partitioning of the 16G card to get a 4G piece I can more easily work with. I want at least 2 cards working initially. All the shops around here are out of anything smaller than 8G. I'm not that excited to buy from ebay or amazon. I understand there are a lot of rebadged ones out there, although I expect that to be mainly for the 128G+ sized cards.
Dwight
 
Well, I spent some time looking at what was in the directory entries. When you have a longer name than the 8.3 on the windows side, it puts the missing pieces in a spread out form in the adjacent directory entries. I suspect this allows attributes to each character. So the extra entries issue is solved. The last file I copied over had a file name that was too big to fit in the normal 8.3 so it put the rest in the adjacent spaces in a hidden form to a normal dir function.
Dwight
 
That was a feature with Win95 = "long file names" described here.

I can remember struggling with this with the first release of Win95 when working on disk forensics tools. It struck me as a kludge back then and still strikes me that way.
 
I second the recommendation of FatFS - I've used it on a number of projects. Is your goal to use it to host files that are used as block storage? For example, old system reads or writes a block -> microcontroller -> reads or writes block into a file running in a FAT filesystem on sdcard.
 
alank2 said:
I second the recommendation of FatFS - I've used it on a number of projects. Is your goal to use it to host files that are used as block storage? For example, old system reads or writes a block -> microcontroller -> reads or writes block into a file running in a FAT filesystem on sdcard.
Click to expand...

Yes, each FAT based file is a single 8 inch disk. My disk are 32 hard sectored. The processor is a 20 bit. I'm not going to do FM encoding, the controller's bus interface is quite simple ( other than being 20 data bits wide plus control strobes ). Any way, a disk track is broken into 2 logical sectors of 1Kx20. So each sector is 2560 bytes, or 5120 bytes per track ( notice that is 10 decimal SD card sectors per track ). 5 SD sectors is one machine sector. The entire disk has 77 tracks for 394,240 bytes. Since I will emulate both the drive and the controller, I don't have to worry about the check word or the reverse order of the sector header on the real disk. These are all issues that the controller handles.
I thought about the Gotek first but Jeff at HxC is just now starting to deal with hard sectored. Talking with him, he didn't really fully understand how much more complicated hard sectored could be than soft sectored to emulate from the floppy side. He has gotten Heathkit H8/89 working OK but NorthStar is giving him timing issues. When I spoke to him at first, he was thinking he could treat it like soft sectored. You know, only sending sector marks and data to the floppy when you got it from the USB drive. Hard sectored is a little more complicated than that. He hadn't even considered my case where the data is continuous across 15 sector marks from the disk. This would mean generating sector marks completely different than the data ( possibly from timers ).
The uC I'm using is the SMT32F103 as the BluePill. It is small and cheap but if I was to use its USB to develop through, most of its tiny memory would be dealing with the more complex USB code. I was looking at compact flash or SD cards. It looks like compact flash have gone the way of the dodo birds. Besides, SD cards through SPI is relatively simple. The F103 does most of the SPI for me. The SD cards are getting hard to find in 4GB and less though. That is why I was asking about partitioning. I'd dealt with FAT12, years ago, so FAT16 is actually a little simpler.
Each floppy is then a file on the SD card. I can make more floppies then I'll ever need on the one SD card and I can still process data on the PC if I want to. Being 20 bit data, I'd have had to do more processing of the data anyway, at the PC.
Dwight
 
Last edited:
You must log in or register to reply here.
Back
Top