Oh, that's weird. I've attached the test code. If that code works too I also attached what I've been working on.
I've gone a bit farther now and implemented EEPROM booting and Disk formating.
The disk formating works, I haven't really tested it on alot of stuff however. It worked on a FAT16 drive. The format code simply wipes the partition clean and does not resize it or anything.
The disk booting allows you to type the name of an eeprom file on the sdcard and boot from it. I really don't know however if the code completely works because I can't load BIN files and when I tried to run the TURBULENCE demo it did nothing. I would need a file that uses up all the memory with non zero data to make sure everything works. I could design a piece of code that I could use to test with.
The command should be used as follows <boot fileName>.
Now, I just need to get pathing working and optimize the code a bit and I will be done.
I think the turbulence demo needs to be run off the eeprom. If I remember correctly it uses data from the eeprom to save hub space. Something like propdos or or the graphics demo will be a better test.
With the latest Testcode I get always 2 after mount 0, for all SD cards.
But if I try the new Beta code, I get a "BPB corrupt" Error for the 2 SD cards, which I have formated with FAT16 and 32k clusters.
So I have re-formated one of the cards with XP and a card reader. Still get the same error (fresh formated with no files on the card), no matter if I format it with FAT16 or FAT32.
Then I tried to format it with your FATEngine, but got "FileSystem not mounted". Hmmm should format not work exactly in this case?
Ariba those are all good warings. The value of 2 you get from mount 0 means that my driver managed to mount your card.
When you get the BPB corrupt error this literally means that the signature byte value is incorrect on the 1st sector of the partition. If you get that error, or MRB corrupt, or FSI corrupt this means that signature byte values are incorrect on those partitions. This means the value there cannot be trusted so I abort.
The only other reason you should get the BPB corrupt error is if my SD card driver thinks the cards are high capacity cards when they are not, or the other way arround. This would cause the block driver to acess the wrong sector.
Either way its a good thing my code aborted if that happened because it would be accessing the partition VERY incorrectly and would destroy it.
The filesystem not mounted error for formating means the filesystem has not been mounted. So you have to mount the file system you want first to format it. I guess I could make the format code do that for you first.
The reason you have to mount the file system first before formating is because the mounting function loads all the filesystem variables that make it possible to format the partition.
I just tested your latest FATengine demo program, and it works. I did the 'test' command, and that worked out fine. Now what does not work is when I tried to attach my ET-mini DS1307 card. As soon as I started the FATengine demo program, the program just froze, I waited the five seconds, and more, nothing. On this setup I am using the proto board, IIRC the proto board is using only one pullup on either the p29, or p28, cannot remember which. Is this what is causing the problem?
It would not do that. The RTC driver I have does not care if it got a valid date back or just garbage. It just goes throught the motions and hopes that everything was right.
Having only one pull up resistor could cause problems. But again the RTC driver shouldn't care. You would just get invalid data.
... I can't say what would cause the program to freeze. It would only not report back info if the serial line were damaged. Which would make it unprogramable...so I'm clueless.
Kye said...
...
The only other reason you should get the BPB corrupt error is if my SD card driver thinks the cards are high capacity cards when they are not, or the other way arround. This would cause the block driver to acess the wrong sector.
If I comment out the BPB Test and abort lines in the mount-code, then I get just the next error: "File System Unsupported".
So I really think it accesses the wrong sector.
I've been overhauling the SD card block driver currently. I should have a small working test mount version up soon... (like in a few days). I'm going through all the code again to make sure everything is compatible as I changed how one of the lowest level functions worked.
I'm also going to work on getting a 4X speed boost by using counter modules and implementing CRC on all transfers. (If I do not implement CRCs I'll be able to get a 8X speed boost).
What's very weird is that for my block driver to acess the wrong sector your SD card had to return the High Capacity status bit set... Which it should not...
I got the ET mini-ds1307 board to work, it was a matter of resetting some jumpers, so the ET board would use the pull-ups provided by the prop board. Everything is working, as expected, will you be adding some commands to reset the ds1307 clock? I used the 'date' command to find out that the clock year is showing 2065. Good work Kye, now, if we had an editor ...
OK, I used the <time> command, and everything thing worked. For those of you who will be using this command, a reminder, 1 = Sunday for the day of the week selection. So far everything is working as advertised, what's next?
I believe that is the problem he is seeing! The only other way the file system would be acessing the wrong blocks is if it the card tells the the driver it is a high capacity card which I doubt it would.
I remember seeing that in your code but I was confused at what it was for.
Thanks Rokicki!
...What's weird however is that this is a problem. Why are there cards arround without Master Boot Records?
MBRs were added so a disk could be partitioned. But for simple removable media, partitioning is just a waste of space.
And if you don't need to boot, no need for a "boot record".
I should be able to get a finalized test platform up soon to see if I can get everyone's SD cards working with my driver. I'll start a seperate tread for it since this one has gotten a bit long for anyone who hasn't been following to read it anymore.
I think I have a way to differentiate between SD cards with and without master boot records that should work pretty well. However, I want to test that theory out. (@Rokicki - I use the BS_jmpBoot Field. I'm not sure however if every card without a MBR has it set to $EB or $E9... that being the first byte of the partition).
The next thing I need to do is figure out how much error checking code I need to put in the mount card function to catch invalid partitions... There's ALOT of stuff I could check but for the most part that type of code is worthless unless you are trying to make the driver fail by using bad SD cards.
Sorry for the delay on my part, I had a pile of stuff on my desk Monday morning -- the latest test posted Friday gives 2 and the demo lists the directory of the card. Now catching up on what's gone on since...
Not too much, I've gotten alot of work done underneath the hood optimizing stuff and making the ASM more friendly to all SD cards.
The codes looking pretty good now in some areas. I noticed I had ALOT of redundant code lying arround that I could put into functions which described its operation better.
I also put retry hooks into my block driver now so that if an operation fails it will try again a few times so that it can avoid giving the user an error if an operation does not work the first time. This should make my code more robust.
If anything else works I would reconmend not running it. I've commented everything else out.
So, just modify the pins in the FAT enigne to get it working and then type "mount 0" into the terminal to mount a partition. Try ls after that and maybe try to boot·a file.
>>· Note that the boot prompt wants "Y" or·"N" not·"y" or "n".
I tested this on four cards. All cards successfully mounted, displayed their volume label, listed screens full of file info from the ls command, and unmounted.
I did have quite a lot of trouble with the terminal communication. About every third or fourth attempt, the Parallax serial terminal would fail to connect to the propeller demo program, making it seem like one of the cards would fail to mount, when in fact the problem was that communication failed to establish. On those times When communication did successfully sync, the program worked perfectly.
So what I did was once communication managed to successfully sync, I left the hardware running and swapped cards, mounting, ls'ing and unmounting each card in turn.
I've been trying to ramp up the speed of my block driver over here but I cannot get it to go any faster even though I put the bits out 4 clock cycles after the clock edge and input bits 4 cycles after a clock edge.
I've been trying to get up to a 4X speed boost. Its going to be difficult however... I'll need to study Lonesock's and Rokicki's code more to figure out how to do fast SPI.
I should get everything working sooner or later. (It all works right now really, just I haven't gotten rid of all the easy to find bugs which allow you to mess up the file system driver's internal state.)
I have the clock going at 2.5Mhz now. This should improve Read and write preformance from about 70KB a second to somewhere near 110-120kB hopefully.
I'm working on getting mulitblock reading·mode working which should get speeds up to 150KB or more.
Please just try what you have done before. This release should work the same. You won't be able to see the speed boost until I re-enable the test code.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I don't see the latest testcode. Have you forgotten to attach it?
Andy
I've gone a bit farther now and implemented EEPROM booting and Disk formating.
The disk formating works, I haven't really tested it on alot of stuff however. It worked on a FAT16 drive. The format code simply wipes the partition clean and does not resize it or anything.
The disk booting allows you to type the name of an eeprom file on the sdcard and boot from it. I really don't know however if the code completely works because I can't load BIN files and when I tried to run the TURBULENCE demo it did nothing. I would need a file that uses up all the memory with non zero data to make sure everything works. I could design a piece of code that I could use to test with.
The command should be used as follows <boot fileName>.
Now, I just need to get pathing working and optimize the code a bit and I will be done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 1/17/2010 4:43:02 AM GMT
Edit: Oh, and P0-P7/8 not driven by external h/w, i.e. unmodified demo board setup.
Post Edited (kuroneko) : 1/17/2010 7:38:09 AM GMT
Maybe that's why it wouldn't boot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
With the latest Testcode I get always 2 after mount 0, for all SD cards.
But if I try the new Beta code, I get a "BPB corrupt" Error for the 2 SD cards, which I have formated with FAT16 and 32k clusters.
So I have re-formated one of the cards with XP and a card reader. Still get the same error (fresh formated with no files on the card), no matter if I format it with FAT16 or FAT32.
Then I tried to format it with your FATEngine, but got "FileSystem not mounted". Hmmm should format not work exactly in this case?
Andy
When you get the BPB corrupt error this literally means that the signature byte value is incorrect on the 1st sector of the partition. If you get that error, or MRB corrupt, or FSI corrupt this means that signature byte values are incorrect on those partitions. This means the value there cannot be trusted so I abort.
The only other reason you should get the BPB corrupt error is if my SD card driver thinks the cards are high capacity cards when they are not, or the other way arround. This would cause the block driver to acess the wrong sector.
Either way its a good thing my code aborted if that happened because it would be accessing the partition VERY incorrectly and would destroy it.
The filesystem not mounted error for formating means the filesystem has not been mounted. So you have to mount the file system you want first to format it. I guess I could make the format code do that for you first.
The reason you have to mount the file system first before formating is because the mounting function loads all the filesystem variables that make it possible to format the partition.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Ray
Having only one pull up resistor could cause problems. But again the RTC driver shouldn't care. You would just get invalid data.
... I can't say what would cause the program to freeze. It would only not report back info if the serial line were damaged. Which would make it unprogramable...so I'm clueless.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 1/18/2010 6:35:46 AM GMT
If I comment out the BPB Test and abort lines in the mount-code, then I get just the next error: "File System Unsupported".
So I really think it accesses the wrong sector.
Andy
I'm also going to work on getting a 4X speed boost by using counter modules and implementing CRC on all transfers. (If I do not implement CRCs I'll be able to get a 8X speed boost).
What's very weird is that for my block driver to acess the wrong sector your SD card had to return the High Capacity status bit set... Which it should not...
Thanks for the Info.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Ray
It will step you through setting the date up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Ray
These cards are not uncommon, and that might cause the problem that Ariba is seeing.
I remember seeing that in your code but I was confused at what it was for.
Thanks Rokicki!
...What's weird however is that this is a problem. Why are there cards arround without Master Boot Records?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
And if you don't need to boot, no need for a "boot record".
I think I have a way to differentiate between SD cards with and without master boot records that should work pretty well. However, I want to test that theory out. (@Rokicki - I use the BS_jmpBoot Field. I'm not sure however if every card without a MBR has it set to $EB or $E9... that being the first byte of the partition).
The next thing I need to do is figure out how much error checking code I need to put in the mount card function to catch invalid partitions... There's ALOT of stuff I could check but for the most part that type of code is worthless unless you are trying to make the driver fail by using bad SD cards.
Anyway, thanks everyone for the input so far.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
The codes looking pretty good now in some areas. I noticed I had ALOT of redundant code lying arround that I could put into functions which described its operation better.
I also put retry hooks into my block driver now so that if an operation fails it will try again a few times so that it can avoid giving the user an error if an operation does not work the first time. This should make my code more robust.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
There is still alot more code to finish but the attached piece will give me an idea of how well the code currently works.
Anyway, most commands are commented out. Including "CD".
The only working commands are:
"boot <fileName>"
"mount <partitionNumber> <checkdiskFlag>"
"unmount"
"ls"
If anything else works I would reconmend not running it. I've commented everything else out.
So, just modify the pins in the FAT enigne to get it working and then type "mount 0" into the terminal to mount a partition. Try ls after that and maybe try to boot·a file.
>>· Note that the boot prompt wants "Y" or·"N" not·"y" or "n".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I'm looking for more input with Ariba and everyone else who was having problems to see if I've fixed those problems.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I have tried it on two Propeller systems with 2 different SD cards, and all works well.
I can mount, list the files, and also boot works.
Andy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I did have quite a lot of trouble with the terminal communication. About every third or fourth attempt, the Parallax serial terminal would fail to connect to the propeller demo program, making it seem like one of the cards would fail to mount, when in fact the problem was that communication failed to establish. On those times When communication did successfully sync, the program worked perfectly.
So what I did was once communication managed to successfully sync, I left the hardware running and swapped cards, mounting, ls'ing and unmounting each card in turn.
Legacy 64MB SD
Lexar 1GB SD
PNY 2GB SD
Lexar 64MB MMC
I also have a bad MMC card that I use for testing; the program successfully detected the bad card, responding with "Disk IO Error".
I've been trying to ramp up the speed of my block driver over here but I cannot get it to go any faster even though I put the bits out 4 clock cycles after the clock edge and input bits 4 cycles after a clock edge.
I've been trying to get up to a 4X speed boost. Its going to be difficult however... I'll need to study Lonesock's and Rokicki's code more to figure out how to do fast SPI.
I should get everything working sooner or later. (It all works right now really, just I haven't gotten rid of all the easy to find bugs which allow you to mess up the file system driver's internal state.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
The latest version worked fine on my PPDB as did your very first version. The ones in between would mount
then when trying to list files would say drive not mounted. Keep up the good work!
Ken
I have the clock going at 2.5Mhz now. This should improve Read and write preformance from about 70KB a second to somewhere near 110-120kB hopefully.
I'm working on getting mulitblock reading·mode working which should get speeds up to 150KB or more.
Please just try what you have done before. This release should work the same. You won't be able to see the speed boost until I re-enable the test code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,