standalone compact flash example errors

Hi Andrew,

Can you tell me what kinds of compact flash cards these are?

Prior to my posting the software files I ran through some tests using 10-20 types of cards in sizes from 16mb to 1gig on a regression farm. This did reveal a power-up problem, whcih was evident on certain combinations of dev boards & CF cards... ths issue is described in the Nios II errata.

To summarize the problem: In "True IDE" mode (as we support), compact flash cards require that the atasel_n input be driven low at power-up. This I/O comes from the FPGA on our dev boards. When the board is powered up, the FPGA can't drive the I/O (FPGA isn't yet configured) and as such the CF card needs to be power-cycled to wake up properly. The CF controller IP & HAL driver do indeed power-cycle the card, however, certain types of CF cards will not power-off when told to do so because of leakage current issues. As a result, to work around the situation, we are reccomending that users tie the atasel_n CF input to ground on their board (or use a strong pull-down resistor). This procedure is detailed in the Nios II 5.0 errata.

After performing this modification on my own dev board, the problematic CF cards have worked without any problems, with either the software I posted to Nios forum or the 3rd-party software (eCos, Micrium uC/FS, etc.). However, I am keenly interested in whether there are other CF issues out there.

Since this issue is sounding like the same power-up problem, I would reccomend giving this change a try.

I have passed the reccomendation for our CF sockets on to our PCB engineers, but unfortunately we cannot modify boards in the field to address this.

Thanks For your response Jesse,

Ive tried 6 different types of cards now up to 512K. All are now working on my unmodified board successfully (as far as Ive been able to test them, all run the auto test and diagnostics etc. read and write blocks) The problem was two fold. Initially only the original 16Mb card was being recognized, and did so flawlessly. no other card would be recognized, however I reloaded the FPGA configuration and all the others started working as well. ( Wouldnt stop all of them working oh no...had to leave the 16Mb card still working...)

Second I found that leaving a short delay before the card initialization routine allows all the cards to initialize in run mode. I dont know exactly why this extra delay is needed, but I discovered when I ran in debug mode, all would initialize if I single stepped through the code. But, when I ran in RUN mode, they failed to initialize (even the 16Mb card). Adding this short delay resolved the problem. (read alleviated the symptom) I suspect it has to do with the power up problems you mentioned. or possibly how the NIOS IDE starts up, but, if anyone else is having trouble recognizing their card i suggest adding a short delay at the start of main() before the call to IDE_initialize. Like this:

int main(void)

{

long i;

for(i= 0;i<1000000;i++); //bit of a delay

if (IDE_initialize())

{

printf("Cannot initialize IDE device.\r");

return -1;

}

else.....

Id be interested in any thoughts on this,

Embarking on a FAT file system if anyone is interested

Andrew

Hi,

I followed your advise, but still have problem.(Add delay and pull-down resistor)

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

IDE_initialize(): error: verify fail: wrote 0x1, read 0x0

IDE_initialize(): error: verify fail: wrote 0x2, read 0x0

IDE_initialize(): error: verify fail: wrote 0x3, read 0x0

IDE_initialize(): error: verify fail: wrote 0x4, read 0x0

IDE_initialize(): error: verify fail: wrote 0x5, read 0x0

IDE_initialize(): error: verify fail: wrote 0x6, read 0x0

IDE_initialize(): error: verify fail: wrote 0x7, read 0x0

IDE_initialize(): error: verify fail: wrote 0x8, read 0x0

IDE_initialize(): error: verify fail: wrote 0x9, read 0x0

IDE_initialize(): error: failed register write/readback test.

Cannot initialize IDE device.[/b]

--- Quote End ---

Can you help me?

Thank you,

LiangYi