Jump to content
IGNORED

SDrive Troubles - advice wanted


a8isa1

Recommended Posts

I recently assembled an SDrive unit. Everything seems to work well until I try to do any form of intensive copying, such as sector copying or using flashjazzcat's FC.

 

Somewhere during the process, sometimes early, sometimes late, but generally after 1500 sectors worth of data and up to 55,000 sectors, SDrive stops recognizing all mounted logical drives. I get error 138 on the Atari and buttons Boot, Left, and Right on SDrive cease to function. Usually only drive LED 1 remains lit but sometimes the red LED also remains lit.

 

The worst of the problem is not that the copy fails and that SDrive appears to have lost its mapping. No, the worst is that the FAT16 file system on my SD cards now is corrupt.

 

Below are the errors I see when I try to mount to use the corrupted SD card on my PC.

 

Copying files

a84now@athlon:~/sdrive_temp$ sudo mount -t vfat /dev/sda1 /media/sd
  a84now@athlon:~/sdrive_temp$ cp /media/sd/* ./
  cp: reading `/media/sd/sdrive_a_l.atr': Input/output error
  cp: reading `/media/sd/sdrive_mydos.atr': Input/output error

 

dmesg

a84now@athlon:~/sdrive_temp$ dmesg
  [189044.812000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189044.812000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189044.812000] end_request: I/O error, dev sda, sector 102168
  [189045.844000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189045.844000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189045.844000] end_request: I/O error, dev sda, sector 102408
  [189046.880000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189046.880000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189046.880000] end_request: I/O error, dev sda, sector 102424
  [189048.320000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189048.320000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189048.320000] end_request: I/O error, dev sda, sector 102400
  [189063.704000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189063.704000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189063.704000] end_request: I/O error, dev sda, sector 135000
  [189065.516000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189065.516000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189065.516000] end_request: I/O error, dev sda, sector 135256
  [189066.700000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189066.700000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189066.700000] end_request: I/O error, dev sda, sector 135168

 

dosfsck

a84now@athlon:~/sdrive_temp$ dosfsck -t -r /dev/sda1
  dosfsck 2.11, 12 Mar 2005, FAT32, LFN
  /sdrive_a_l.atr
	Cluster 451 (1593) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1594) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1595) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1596) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1597) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1598) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1599) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1600) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1601) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1602) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1603) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1604) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1605) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1606) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1607) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1608) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 454 (1612) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 454 (1613) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 454 (1614) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 454 (1615) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 454 (1616) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 454 (1617) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 445 (2104) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 445 (2105) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2108) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2109) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2110) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2111) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2112) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2113) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2114) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2115) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2116) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2117) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2118) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2119) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2120) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2121) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2122) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2123) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2124) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 448 (2126) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 451 (2130) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 451 (2131) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 452 (2133) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 452 (2134) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 460 (2143) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 460 (2144) is unreadable. Skipping it.
  /sdrive_a_l.atr
	File size is 16776592 bytes, cluster chain length is 16056320 bytes.
	Truncating file to 16056320 bytes.
  /sdrive_mydos.atr
	File size is 16776592 bytes, cluster chain length is 15925248 bytes.
	Truncating file to 15925248 bytes.
  Cluster 1655 is unreadable.
  Cluster 1656 is unreadable.
  Cluster 4159 is unreadable.
  Cluster 4160 is unreadable.
  Cluster 4163 is unreadable.
  Cluster 4164 is unreadable.
  Cluster 4167 is unreadable.
  Cluster 4220 is unreadable.
  Cluster 4221 is unreadable.
  Cluster 4223 is unreadable.
  Cluster 4224 is unreadable.
  Cluster 4226 is unreadable.
  Cluster 4227 is unreadable.
  Cluster 4228 is unreadable.
  Cluster 4229 is unreadable.
  Cluster 4232 is unreadable.
  Cluster 4233 is unreadable.
  Cluster 4236 is unreadable.
  Cluster 4241 is unreadable.
  Cluster 4244 is unreadable.
  Cluster 4281 is unreadable.
  Cluster 4287 is unreadable.
  Cluster 4288 is unreadable.
  Cluster 4289 is unreadable.

...

Cluster 60232 is unreadable.
Cluster 60233 is unreadable.
Cluster 60234 is unreadable.
Cluster 60235 is unreadable.
Perform changes ? (y/n)

 

I don't bother completing the repair as I can just overwrite the affected region of the SD card and start over.

 

I have no trouble using these SD cards on my PC and testing after blanking the SD cards

prove them 100% good.

 

I never have trouble reading data from the Atari. I use a very intensive reading program, raw SIO Reads at up to 99 Kbits/sec (using Hias Reichl's beta high speed SIO driver).

 

From start to finish of all ATRs this reading test never hangs or even has problems.

 

However, intensive writing, at any speed (19.2Kbit/sec to 89Kbits/sec), fails every time and nearly 100% of the time the failure results in a corrupted file system on the SD card.

Only once did this not happen though the copy process still failed in the same manor.

 

This happens with two separate SD cards but they are identical (SanDisk 2GB).

 

Most of the time I can do casual writing (e.g. save a file, write DOS to a disk, etc) but even this fails some of the time resulting in the same corruption.

 

Is this problem indicative of these SD cards being incompatible with SDrive?

 

Should I try another SD card?

 

I've already reprogrammed the Atmega8 several times.

 

Any advice or ideas would be appreciated.

 

Thanks.

 

- Steve Sheppard

 

p.s. Sorry for the very long post.

Edited by a8isa1
Link to comment
Share on other sites

Hi.

 

a84now@athlon:~/sdrive_temp$ dosfsck -t -r /dev/sda1
  dosfsck 2.11, 12 Mar 2005, FAT32, LFN
  /sdrive_a_l.atr Cluster 451 (1593) is unreadable. Skipping it.

FAT32 ?!?! WTF(AT32)? ;-)

SDrive supports FAT16 only!

 

However, intensive writing, at any speed (19.2Kbit/sec to 89Kbits/sec), fails every time and nearly 100% of the time the failure results in a corrupted file system on the SD card.

It's strange. SDrive doesn't write anything to any section of file system on the SD card never. It writes only to data sectors with contents of files (atr,xfd).

 

This happens with two separate SD cards but they are identical (SanDisk 2GB).

As you can see in documentation, we tested some SanDisk cards and they were working well:

SanDisk 512MB SD, SanDisk 1GB SD, (China), SanDisk Ultra II (SD/USB) 1GB (China)

 

Is this problem indicative of these SD cards being incompatible with SDrive?

I think problem will be elsewhere, but I don't know where.

 

Should I try another SD card?

IMHO you should to check your SDrive hardware (main voltage 5V, stabilized voltage 3.3V, voltage divider system by resistors R1,R2,R3,RN2).

Also it would be good to test this SD card on another SDrive device which works well without any troubles.

Greetings, raster/c.p.u.

Edited by raster/c.p.u.
Link to comment
Share on other sites

I think SD cards work like most flash memory in that they buffer writes when you send data and write all at once when they can access memory undisturbed. This means that you can read as much as you want, but you have to allow some offline time slices to complete writes. I have no idea how your hardware accounts for this...

 

You can try writing a block of sectors (maybe 256) and then pausing for a couple of seconds before you write the next block. This should give the SD controller enough time to actually write the data to flash. If that writes to end of volume, try reducing the delay. If you cannot write 256 sector blocks, try a smaller block size.

 

Are you sure that reads work OK? Do you verify?

 

Bob

 

 

 

I recently assembled an SDrive unit. Everything seems to work well until I try to do any form of intensive copying, such as sector copying or using flashjazzcat's FC.

 

Somewhere during the process, sometimes early, sometimes late, but generally after 1500 sectors worth of data and up to 55,000 sectors, SDrive stops recognizing all mounted logical drives. I get error 138 on the Atari and buttons Boot, Left, and Right on SDrive cease to function. Usually only drive LED 1 remains lit but sometimes the red LED also remains lit.

 

The worst of the problem is not that the copy fails and that SDrive appears to have lost its mapping. No, the worst is that the FAT16 file system on my SD cards now is corrupt.

 

Below are the errors I see when I try to mount to use the corrupted SD card on my PC.

 

Copying files

a84now@athlon:~/sdrive_temp$ sudo mount -t vfat /dev/sda1 /media/sd
  a84now@athlon:~/sdrive_temp$ cp /media/sd/* ./
  cp: reading `/media/sd/sdrive_a_l.atr': Input/output error
  cp: reading `/media/sd/sdrive_mydos.atr': Input/output error

 

dmesg

a84now@athlon:~/sdrive_temp$ dmesg
  [189044.812000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189044.812000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189044.812000] end_request: I/O error, dev sda, sector 102168
  [189045.844000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189045.844000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189045.844000] end_request: I/O error, dev sda, sector 102408
  [189046.880000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189046.880000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189046.880000] end_request: I/O error, dev sda, sector 102424
  [189048.320000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189048.320000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189048.320000] end_request: I/O error, dev sda, sector 102400
  [189063.704000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189063.704000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189063.704000] end_request: I/O error, dev sda, sector 135000
  [189065.516000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189065.516000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189065.516000] end_request: I/O error, dev sda, sector 135256
  [189066.700000] sd 2:0:0:0: [sda] Device not ready: <6>: Sense Key : Not Ready [current]
  [189066.700000] : <<vendor>> ASC=0xff ASCQ=0xffASC=0xff <<vendor>> ASCQ=0xff
  [189066.700000] end_request: I/O error, dev sda, sector 135168

 

dosfsck

a84now@athlon:~/sdrive_temp$ dosfsck -t -r /dev/sda1
  dosfsck 2.11, 12 Mar 2005, FAT32, LFN
  /sdrive_a_l.atr
	Cluster 451 (1593) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1594) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1595) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1596) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1597) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1598) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1599) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1600) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1601) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1602) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1603) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1604) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1605) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1606) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1607) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 451 (1608) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 454 (1612) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 454 (1613) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 454 (1614) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 454 (1615) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 454 (1616) is unreadable. Skipping it.
  /sdrive_a_l.atr
	Cluster 454 (1617) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 445 (2104) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 445 (2105) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2108) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2109) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2110) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2111) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2112) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2113) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2114) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2115) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2116) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2117) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2118) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2119) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2120) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2121) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2122) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2123) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 447 (2124) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 448 (2126) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 451 (2130) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 451 (2131) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 452 (2133) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 452 (2134) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 460 (2143) is unreadable. Skipping it.
  /sdrive_mydos.atr
	Cluster 460 (2144) is unreadable. Skipping it.
  /sdrive_a_l.atr
	File size is 16776592 bytes, cluster chain length is 16056320 bytes.
	Truncating file to 16056320 bytes.
  /sdrive_mydos.atr
	File size is 16776592 bytes, cluster chain length is 15925248 bytes.
	Truncating file to 15925248 bytes.
  Cluster 1655 is unreadable.
  Cluster 1656 is unreadable.
  Cluster 4159 is unreadable.
  Cluster 4160 is unreadable.
  Cluster 4163 is unreadable.
  Cluster 4164 is unreadable.
  Cluster 4167 is unreadable.
  Cluster 4220 is unreadable.
  Cluster 4221 is unreadable.
  Cluster 4223 is unreadable.
  Cluster 4224 is unreadable.
  Cluster 4226 is unreadable.
  Cluster 4227 is unreadable.
  Cluster 4228 is unreadable.
  Cluster 4229 is unreadable.
  Cluster 4232 is unreadable.
  Cluster 4233 is unreadable.
  Cluster 4236 is unreadable.
  Cluster 4241 is unreadable.
  Cluster 4244 is unreadable.
  Cluster 4281 is unreadable.
  Cluster 4287 is unreadable.
  Cluster 4288 is unreadable.
  Cluster 4289 is unreadable.

...

Cluster 60232 is unreadable.
Cluster 60233 is unreadable.
Cluster 60234 is unreadable.
Cluster 60235 is unreadable.
Perform changes ? (y/n)

 

I don't bother completing the repair as I can just overwrite the affected region of the SD card and start over.

 

I have no trouble using these SD cards on my PC and testing after blanking the SD cards

prove them 100% good.

 

I never have trouble reading data from the Atari. I use a very intensive reading program, raw SIO Reads at up to 99 Kbits/sec (using Hias Reichl's beta high speed SIO driver).

 

From start to finish of all ATRs this reading test never hangs or even has problems.

 

However, intensive writing, at any speed (19.2Kbit/sec to 89Kbits/sec), fails every time and nearly 100% of the time the failure results in a corrupted file system on the SD card.

Only once did this not happen though the copy process still failed in the same manor.

 

This happens with two separate SD cards but they are identical (SanDisk 2GB).

 

Most of the time I can do casual writing (e.g. save a file, write DOS to a disk, etc) but even this fails some of the time resulting in the same corruption.

 

Is this problem indicative of these SD cards being incompatible with SDrive?

 

Should I try another SD card?

 

I've already reprogrammed the Atmega8 several times.

 

Any advice or ideas would be appreciated.

 

Thanks.

 

- Steve Sheppard

 

p.s. Sorry for the very long post.

Link to comment
Share on other sites

IMHO you should to check your SDrive hardware (main voltage 5V, stabilized voltage 3.3V, voltage divider system by resistors R1,R2,R3,RN2).

Also it would be good to test this SD card on another SDrive device which works well without any troubles.

Greetings, raster/c.p.u.

Hi!

 

It is puzzling that clusters are becoming corrupted. I didn't even think this would be possible with flash media.

 

Both 5V and 3.3V are solid. I'll check the voltage divider.

 

Thanks for the tip.

 

- Steve

Link to comment
Share on other sites

I think SD cards work like most flash memory in that they buffer writes when you send data and write all at once when they can access memory undisturbed. This means that you can read as much as you want, but you have to allow some offline time slices to complete writes. I have no idea how your hardware accounts for this...

 

You can try writing a block of sectors (maybe 256) and then pausing for a couple of seconds before you write the next block. This should give the SD controller enough time to actually write the data to flash. If that writes to end of volume, try reducing the delay. If you cannot write 256 sector blocks, try a smaller block size.

 

Are you sure that reads work OK? Do you verify?

 

Bob

Hi Bob!

 

My sector copier buffers only 64 sectors but I've also tried drac030's HDSC (even larger buffer). At SIO speeds either program allows several seconds between writes.

 

Yes I have verified reads. I can use my sector copier to transfer 65,535 sectors from SDrive volumes to MyIDE without any trouble. (I cannot transfer the other way though).

 

I don't believe a pause between activity should be necessary with flash media, otherwise I should think devices like SIO2SD, MyIDE (with CF) or SIO2IDE (with CF) would have similar problems. However, I'll try this as well.

 

Please be aware, though it rarely happens I've run into the problem by simply copying a single Atari file.

 

Thanks for the ideas.

 

- Steve Sheppard

Link to comment
Share on other sites

My sector copier buffers only 64 sectors but I've also tried drac030's HDSC (even larger buffer). At SIO speeds either program allows several seconds between writes.

 

Yes I have verified reads. I can use my sector copier to transfer 65,535 sectors from SDrive volumes to MyIDE without any trouble. (I cannot transfer the other way though).

 

I don't believe a pause between activity should be necessary with flash media, otherwise I should think devices like SIO2SD, MyIDE (with CF) or SIO2IDE (with CF) would have similar problems. However, I'll try this as well.

 

Please be aware, though it rarely happens I've run into the problem by simply copying a single Atari file.

 

Thanks for the ideas.

 

- Steve Sheppard

 

Just had a thought on this... There is the RW/RO switch on the SDrive. Is the connection there bad? If that was toggling during operations perhaps some writes aren't happening?

 

--Kurt

Link to comment
Share on other sites

My sector copier buffers only 64 sectors but I've also tried drac030's HDSC (even larger buffer). At SIO speeds either program allows several seconds between writes.

 

Yes I have verified reads. I can use my sector copier to transfer 65,535 sectors from SDrive volumes to MyIDE without any trouble. (I cannot transfer the other way though).

 

I don't believe a pause between activity should be necessary with flash media, otherwise I should think devices like SIO2SD, MyIDE (with CF) or SIO2IDE (with CF) would have similar problems. However, I'll try this as well.

 

Please be aware, though it rarely happens I've run into the problem by simply copying a single Atari file.

 

Thanks for the ideas.

 

- Steve Sheppard

 

Just had a thought on this... There is the RW/RO switch on the SDrive. Is the connection there bad? If that was toggling during operations perhaps some writes aren't happening?

 

--Kurt

Seems to be OK but I'm not sure how I would test for an intermittent disconnect.

 

- Steve Sheppard

Link to comment
Share on other sites

... You can try writing a block of sectors (maybe 256) and then pausing for a couple of seconds before you write the next block. This should give the SD controller enough time to actually write the data to flash. If that writes to end of volume, try reducing the delay. If you cannot write 256 sector blocks, try a smaller block size.

Hi.

I was copying some real 5.25" diskettes from real diskdrive to images mounted in SDrive by Q-meg4. It did fast (69kbps) sequential writing of 1024 sectors (from extended Atari RAM to SDrive) and it was working well, therefore I think there is not problem with missing delays.

 

I don't believe a pause between activity should be necessary with flash media...

Me too.

Link to comment
Share on other sites

Just had a thought on this... There is the RW/RO switch on the SDrive. Is the connection there bad? If that was toggling during operations perhaps some writes aren't happening?

 

--Kurt

Seems to be OK but I'm not sure how I would test for an intermittent disconnect.

 

- Steve Sheppard

 

I think you'd need a scope to see it. However, my SDrive NUXX prototype doesn't have the switch it just has a jumper keeping it in the RW position. You could try the same temporarily to rule out that being the cause.

Link to comment
Share on other sites

The only devices that don't need internal write cycles are FRAMs, as far as I know. I've seen low-level format wipe out a CF card that works just fine otherwise.

 

As I said, I don't know the internal workings of these controllers but I would assume that the SIO buss cannot affect the cluster map or the FAT directly. So, it is probably an internal problem. Since the code is working in other devices and the SD cards are OK, how much can be wrong? The SD interface works on reads - what is the basic difference between reads and writes? Data direction, internal cyces...

 

Yes, your SDrive works fine. His is broken. What control interface may be the problem? I doubt that any delays are set into the device, but something has to alert the outside world that the SD card is 'busy'. Is that hardware?

 

I know I can select a CF card any time I want without checking 'busy' and it will (almost) work just fine - unless I'm writing.

 

Bob

 

 

... You can try writing a block of sectors (maybe 256) and then pausing for a couple of seconds before you write the next block. This should give the SD controller enough time to actually write the data to flash. If that writes to end of volume, try reducing the delay. If you cannot write 256 sector blocks, try a smaller block size.

Hi.

I was copying some real 5.25" diskettes from real diskdrive to images mounted in SDrive by Q-meg4. It did fast (69kbps) sequential writing of 1024 sectors (from extended Atari RAM to SDrive) and it was working well, therefore I think there is not problem with missing delays.

 

I don't believe a pause between activity should be necessary with flash media...

Me too.

Link to comment
Share on other sites

This happens with two separate SD cards but they are identical (SanDisk 2GB).

As you can see in documentation, we tested some SanDisk cards and they were working well:

SanDisk 512MB SD, SanDisk 1GB SD, (China), SanDisk Ultra II (SD/USB) 1GB (China)

 

2GB SD cards (except SDHC ones) are not-standard. Not sure if that is your problem, probably not, but I would test cards with smaller capacity (1 GB or less) just in case.

 

The only devices that don't need internal write cycles are FRAMs, as far as I know. I've seen low-level format wipe out a CF card that works just fine otherwise.

 

SD cards have no cache. They write physically to the media immediately. Of course that they need internal cycles to do that, but those cycles are part of the write transaction. You send a "write sector" command, you send the data, you wait for response indicating card is ready and all went well. While you wait for a response, the card actually writes to the media. Note that "wait" is a bit misleading, you keep constantly asking the card if it is done (and then generating clock cycles to the card).

Link to comment
Share on other sites

2GB SD cards (except SDHC ones) are not-standard. Not sure if that is your problem, probably not, but I would test cards with smaller capacity (1 GB or less) just in case.

Note: Currently I have a lot of SD cards at home - I bought them for testing SDrive. :) Most of them are 2GB and all works well (Elite Pro High Speed SD 2GB (China), EMTEC SD 2GB (China), Kingston SD 2GB(Taiwan), Kingston SD 2GB (Japan)). Also my last purchased 2GB Noname microSD + SDadapter works fine, so I think there won't be a problem with 2GB capacity.

Link to comment
Share on other sites

2GB SD cards (except SDHC ones) are not-standard. Not sure if that is your problem, probably not, but I would test cards with smaller capacity (1 GB or less) just in case.

This is not quite correct, I think you mixed this up with 4GB SD cards (which are non-standard). The SD card standard defines sizes up to 2GB, SDHC is 4GB to 32GB and the upcoming SDXC standard should be up to 2TB. See http://www.sdcard.org/consumers/cards.

 

While you wait for a response, the card actually writes to the media. Note that "wait" is a bit misleading, you keep constantly asking the card if it is done (and then generating clock cycles to the card).

This is right, and sending clock cycles is also important. Without the clock cycles the SD card usually won't do anything. Some (slower) cards require quite some time to write the data and this time might increase when the card ages due to slightly worn out flash cells (BTW: this also happens with other flash devices).

 

so long,

 

Hias

Link to comment
Share on other sites

Note: Currently I have a lot of SD cards at home - I bought them for testing SDrive. :) Most of them are 2GB and all works well (Elite Pro High Speed SD 2GB (China), EMTEC SD 2GB (China), Kingston SD 2GB(Taiwan), Kingston SD 2GB (Japan)). Also my last purchased 2GB Noname microSD + SDadapter works fine, so I think there won't be a problem with 2GB capacity.

 

For what it's worth, it's these same 2GB Kingston cards from Japan which are being used (and provided with) the SDrive NUXXs. They seem to work just fine. No problems at all...

Link to comment
Share on other sites

Could you post some high-res photos of your build? Perhaps one of us can spot something a bit out of place which you happened to overlook?
Sorry, I don't own a digital camera or even a scanner. This is not a homebrew anyway. I just assembled one of A8Maestro's SDrive kits.

 

Three other such builds are known not to exhibit my problem.

 

- Steve

Link to comment
Share on other sites

Sorry, I don't own a digital camera or even a scanner. This is not a homebrew anyway. I just assembled one of A8Maestro's SDrive kits.

 

Three other such builds are known not to exhibit my problem.

 

Well, because you built it yourself, it is kinda home made... Thus I was hoping that we all might be able to see something wrong which you might have overlooked.

 

One other idea: did you clean the flux from the board? Many fluxes which are designed to be cleaned off are a little conductive and will cause all sorts of weirdness if left in place after assembly.

Edited by c0nsumer
Link to comment
Share on other sites

2GB SD cards (except SDHC ones) are not-standard. Not sure if that is your problem, probably not, but I would test cards with smaller capacity (1 GB or less) just in case.

This is not quite correct, I think you mixed this up with 4GB SD cards (which are non-standard). The SD card standard defines sizes up to 2GB,

 

Hi Hias,

 

No, I probably didn't use the most accurate wording, but I didn't mix up.

 

What I should have said is that some non-SDHC 2 GB might be non-standard, and that many older readers might not work with those cards.

 

The current version of the standard does define specifications for SD cards upto 4 GB. But this wasn't in the original SD specifications. The original specifications were up to 1 GB only. SD cards with bigger capacity, mainly 2 GB cards appeared then in the market, and this was before the specifications were updated. The specifications were later updated according to what most (but not all) top-brand cards and readers used. So not every 2 GB card is/was exactly the same, and not every reader was able to read some, all, or none of those cards.

 

Anyway, now that the SDrive compatibility with 2 GB was confirmed, it is mostly an academic issue unless you are using a rather old card.

Edited by ijor
Link to comment
Share on other sites

I solved the problem or rather it sort of solved itself.

 

Turns out I had a dodgy LE33. I never would have it, as it measured at +3.30 volts, that is until it failed completely.

 

I didn't have a spare so I instead used two diodes in series which is supplying just under 3.6 volts to the SD card.

 

My SDrive is working perfectly now.

 

Thanks everyone for your help.

 

- Steve Sheppard

Link to comment
Share on other sites

I solved the problem or rather it sort of solved itself.

 

Turns out I had a dodgy LE33. I never would have it, as it measured at +3.30 volts, that is until it failed completely.

 

I didn't have a spare so I instead used two diodes in series which is supplying just under 3.6 volts to the SD card.

 

Glad to hear it. :D

 

It's a really, really nifty device, eh?

Link to comment
Share on other sites

I solved the problem or rather it sort of solved itself.

 

Turns out I had a dodgy LE33. I never would have it, as it measured at +3.30 volts, that is until it failed completely.

 

I didn't have a spare so I instead used two diodes in series which is supplying just under 3.6 volts to the SD card.

 

Glad to hear it. :D

 

It's a really, really nifty device, eh?

It is if/when it works.

 

Actually, now that's it's fixed I'm finding it's stable with a Pokey divisor of 2.

 

I will tentatively say I'm very happy :)

 

- Steve Sheppard

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...