Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12603 Discussions

standalone compact flash example errors

Altera_Forum
Honored Contributor II
917 Views

Hello, 

Im working with the standalone compact flash IP and Im having some serious trouble getting it to work on any Flashcard other than the 16Mb card that came with my NIOS Cyclone 1C20 dev kit. 

 

I found that when I tried to run the demo, it would time out. Though when I ran it in debug, it ran fine. I put a delay in main before  

the IDE initialization and that let me at least run the example with the 16Mb card as supplied. Up till then I was happy and life was generally good but! 

 

I went out and got two larger cards, one 128Mb and one 256MB and both turn their noses up at it! 

 

the 128Mb card comes up with the following: 

 

Error? status: 0x51; error: 0x4  

 

Even though the IDE initialzed line comes up and the user menu runs. Try an option and it generally hangs. 

 

The 256Mb card times out on INTIRQ = 1 and never gets past this point. 

 

 

Id very much like to solve this since putting an OS just to get compact flash isnt an option for me. 

 

any help greatly appreciated http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif  

 

Andrew
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
230 Views

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&#39;t drive the I/O (FPGA isn&#39;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.
0 Kudos
Altera_Forum
Honored Contributor II
230 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
230 Views

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
0 Kudos
Reply