Thanks for the quick reply
>(1) Could you please try the write test without an "fs" between fo 10...
>und fw?:
Same result:

1

FatFs module test terminal

2

>fi 0

3

rc=0 FR_OK

4

>fo 10 test

5

rc=0 FR_OK

6

>fw 2048 1

7

rc=1 FR_NOT_READY

8

0 bytes written with 0 kB/sec.

9

>fc

10

rc=1 FR_NOT_READY

11

>fl

12

----A 2000/01/01 11:55         0  test  

13

   1 File(s),          0 bytes total

14

   0 Dir(s),    27836416 bytes free

>(2) try with a lower the SPI-bitrate (increase prescaler)

I changed

1

#define BOARD_PRESCALER         AT91C_PMC_PRES_CLK_2

in board_lowlevel.c to

1

#define BOARD_PRESCALER         AT91C_PMC_PRES_CLK_4

and

1

#define BOARD_MCK               48000000

in board.h to

1

#define BOARD_MCK               24000000

(I'm not sure if there are other changes to be made)
The result was exactly the same as before.

>(3) format the disk using the PC+Card-Reader or fm in the test-terminal
>which calls ChaN's "makefs". Then retry with a "clean" system

Reformatted with both Ubuntu's gparted and Panasonic's SD Formatter (on 
XP) with the same result as before.

fm doesn't seem to work:

1

FatFs module test terminal

2

>di 0

3

rc=0

4

>fi 0

5

rc=0 FR_OK

6

>fl

7

   0 File(s),          0 bytes total

8

   0 Dir(s),    31080448 bytes free

9

>fm 0 16384

10

The drive 0 will be formatted. Are you sure? (Y/n)=Y

11

rc=1 FR_NOT_READY

12

>fs

13

rc=13 FR_MKFS_ABORTED

14

>

15

16

powercycle

17

18

AT91SAM7S Demo Application by Martin Thomas

19

V1.0.3 5/2009

20

-- Compiled: May 12 2009 14:55:13 --

21

-- for Board SAM7-Pxxx

22

23

FatFs module test terminal

24

>di 0

25

rc=0

26

>fi 0

27

rc=0 FR_OK

28

>fs

29

rc=13 FR_MKFS_ABORTED

30

>

I then had to reformat the card to get it to work.

Travis Wiens wrote:
>...
> rc=1 FR_NOT_READY

Could you please re-check that your modification for the 
"Write-Protect-Detection" works as expected? There is still some 
test-code in sd_spi_at91 -> disk_init() for this, just replace #if 0 
with #if 1. With this enabled the state of the socket-switches (CD and 
WP) will be shown on the terminal-interface with "di 0".

>>(2) try with a lower the SPI-bitrate (increase prescaler)
>
> I changed
> ...

Just increase the value defined for SPI_SCBR_MIN in sd_spi_at91.c, keep 
board.h as is.

>>(3) format the disk using the PC+Card-Reader or fm in the test-terminal
>>which calls ChaN's "makefs". Then retry with a "clean" system
>
> Reformatted with both Ubuntu's gparted and Panasonic's SD Formatter (on
> XP) with the same result as before.
>
> fm doesn't seem to work:
> [pre]
> FatFs module test terminal
>>di 0
> rc=0
>>fi 0
> rc=0 FR_OK
>>fl
>    0 File(s),          0 bytes total
>    0 Dir(s),    31080448 bytes free
>>fm 0 16384
> The drive 0 will be formatted. Are you sure? (Y/n)=Y
> rc=1 FR_NOT_READY
>...

I expect this and the "fw" problem have the same reason.

Do you have a scope? Could you try to monitor the supply voltage of the 
card during the different tests?

Martin Thomas wrote:
> Travis Wiens wrote:
>>...
>> rc=1 FR_NOT_READY
>
> Could you please re-check that your modification for the
> "Write-Protect-Detection" works as expected? There is still some
> test-code in sd_spi_at91 -> disk_init() for this, just replace #if 0
> with #if 1. With this enabled the state of the socket-switches (CD and
> WP) will be shown on the terminal-interface with "di 0".

It works as expected, identifying if a card is present or not, and also 
if the card is write protected or not.

>>>(2) try with a lower the SPI-bitrate (increase prescaler)
>>
>> I changed
>> ...
>
> Just increase the value defined for SPI_SCBR_MIN in sd_spi_at91.c, keep
> board.h as is.

Same result for SPI_SCBR_MIN ranging from 2 (default) to 8. (Doesn't 
work at all for SPI_SCBR_MIN = 1.)


> Do you have a scope? Could you try to monitor the supply voltage of the
> card during the different tests?

I don't have a scope, but I've got a 225 KHz daq system. If I can, I'll 
take some measurements this afternoon.

>
>> Do you have a scope? Could you try to monitor the supply voltage of the
>> card during the different tests?
>
> I don't have a scope, but I've got a 225 KHz daq system. If I can, I'll
> take some measurements this afternoon.

I've uploaded plots of Vcc during "fo" and "fw" commands to
http://picasaweb.google.com/tkw954/SAM7#
I've uploaded the raw data in Matlab format to
http://homepage.usask.ca/~tkw954/save_data3.mat
which includes 225 KHz data for Vcc DI DO and CLK for 'fl', 'fo', 'fw', 
and 'di' commands.

The supply voltage does go below 2.5 V momentarily and seems to 
oscillate between 2.7 and 3.8 V, especially at the end of the 'fo' 
command.

If it would help, I can probably borrow a 'scope next week.

Travis Wiens wrote:
>>
>>> Do you have a scope? Could you try to monitor the supply voltage of the
>>> card during the different tests?
>>
>> I don't have a scope, but I've got a 225 KHz daq system. If I can, I'll
>> take some measurements this afternoon.
>
> I've uploaded plots of Vcc during "fo" and "fw" commands to
> http://picasaweb.google.com/tkw954/SAM7#
> I've uploaded the raw data in Matlab format to
> http://homepage.usask.ca/~tkw954/save_data3.mat
> which includes 225 KHz data for Vcc DI DO and CLK for 'fl', 'fo', 'fw',
> and 'di' commands.
>
> The supply voltage does go below 2.5 V momentarily and seems to
> oscillate between 2.7 and 3.8 V, especially at the end of the 'fo'
> command.

Hmm, this reather wide span does not look "healthy" to me. What kind of 
power-supply to you use? Maybe it's a little weak. Can you try with 
another one?

> If it would help, I can probably borrow a 'scope next week.
I guess addtional measurements will not help that much. Test with a 
"stronger" power-supply first.

There might be a software-issue but the few tests I made did not show a 
problem (some outputs shown in the readme-file of the package). I will 
do some more testing when I'm back at my "workbench" and will also scope 
the card's vcc line.

>Hmm, this reather wide span does not look "healthy" to me. What kind of
>power-supply to you use? Maybe it's a little weak. Can you try with
>another one?

I was using the USB powersupply, but get the same errors using a "wall 
wart" rated for 2.1 A.

A new package of the AT91SAM7/ChaN FatFS demo-application is available 
from my page: 
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#chanfat_at91sam7
This - hopefully - includes a fix for the mentioned write problems. At 
least all tests I have run with a SanDisk ultra II SDHC 4GB and 
extrememory performance SD-Card 1GB worked as expected. If there are 
still problems please disable DMA/PDC by a define in the 
low-level-driver and try again. Feedback welcome.
Martin Thomas

>A new package of the AT91SAM7/ChaN FatFS demo-application is available
>from my page:
>http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...
>This - hopefully - includes a fix for the mentioned write problems.

Yes, this solves my problems. Seems to work perfectly.

Thanks a lot,
Travis