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++
12608 Discussions

Compact flash perculiarities

Altera_Forum
Honored Contributor II
976 Views

Hello 

 

I am using bothe the EP1C20 Nios dev board and the EP2C35 dev board. On both of them I use the same cf core provided by Altera. I get strange results on both boards with sevsral compact flash cards and in one instance: a card works fine on the EP1C20 and does not work well on the EP2C35 board. 

The strange thing I get is that the initial IDE test fails (the test is a very simple one: writes a value to the sector register of the core and reads it to confirm the write). As far as I can see in hardware, there is actually a failure, but its source is not clear. 

Here is the code that fails: 

 

int IDE_initialize(void) {  IDE_setVerbosity(0);  IOWR_ALTERA_AVALON_CF_CTL_CONTROL(ctl_base, ALTERA_AVALON_CF_CTL_STATUS_POWER_MSK); # if 1  {    // Register test:    unsigned char ucWrite;    unsigned char ucRead;    int iGood = 1;    for (ucWrite = 0; ucWrite < 10; ++ucWrite)    {      IOWR_ALTERA_AVALON_CF_IDE_SECTOR_NUMBER(ide_base, ucWrite);      ucRead = IORD_ALTERA_AVALON_CF_IDE_SECTOR_NUMBER(ide_base);      if (ucWrite != ucRead)      {        iGood = 0;        printf("verify fail: wrote 0x%X, read 0x%X\n", ucWrite, ucRead);      }    }    if (iGood)    {      printf("wrote and verified %d values successfully.\n", ucWrite);    }    else    {      printf("failed to write and verify all the values.\n");      printf("Did you remember to insert or re-insert the card?\n");      return 0;    }  }# endif //  enable insert detect interrupt  alt_irq_register(ctl_irq, 0, CTLTrapHandler);  IOWR_ALTERA_AVALON_CF_CTL_CONTROL(ctl_base, ALTERA_AVALON_CF_CTL_STATUS_POWER_MSK                                         + ALTERA_AVALON_CF_CTL_STATUS_IRQ_EN_MSK); // enable IDE interrupts  alt_irq_register(ide_irq, 0, IDETrapHandler);  IOWR_ALTERA_AVALON_CF_IDE_CTL(ctl_base, ALTERA_AVALON_CF_IDE_CTL_IRQ_EN_MSK);  if (!IDE_identifyDevice(0))  {    return 0;  }  IDE_initializeDeviceParameters(0, getLogicalHeads(),    getLogicalCylinders(), getSectorsPerTrack());  return 1; }  

 

And here is the output to the console:[list]verify fail: wrote 0x0, read 0x1 

verify fail: wrote 0x2, read 0x1 

verify fail: wrote 0x3, read 0x1 

verify fail: wrote 0x4, read 0x1 

verify fail: wrote 0x5, read 0x1 

verify fail: wrote 0x6, read 0x1 

verify fail: wrote 0x7, read 0x1 

verify fail: wrote 0x8, read 0x1 

verify fail: wrote 0x9, read 0x1[/list] 

There are no timing problems in the design and as mentioned before, the same thing may fail with two or three cards and then work with the fourth one. 

 

Has anyone come accross this problem before ? 

 

Nir
0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
268 Views

Hi Nir, 

 

We have seen similar behavior, and it stems from the fact that to operate in True IDE mode, CF cards need their atasel_n pin driven low at power-up. Since atasel_n is an FPGA I/O, and the FPGA&#39;s I/O are tri-stated before FPGA configuration, we need to power-cycle the compact flash cards from Nios during the boot process to ensure that the CF card initializes correctly. However, compact flash cards from certain manufactuerers exhibit significant leakage current. This causes them not to be powered off completely when the CF power register bit in the CF peripheral is cycled by the Nios II CPU, and as such, the atasel_n input isn&#39;t sampled again as happens during the power on process. 

 

The following web page describes the problem in more detail and a couple of potential workarounds: 

http://www.altera.com/support/ip/processor...-er.html#boards (http://www.altera.com/support/ip/processors/nios2/ips-niosii-50-er.html#boards

 

In the future, we may modify dev boards to have the atasel_n pin as a stuff option to prevent this.
0 Kudos
Altera_Forum
Honored Contributor II
268 Views

Thanks for that, Jesse 

 

I forgot about that one. I&#39;ve done this on my EP1C20 board. I&#39;ll do it on this one as well. However, some cards still don&#39;t work on the EP1C20 board, even after tying atasel_n. Another funny thing is that the 32Mb card that comes with the EP2C35 board works on that board, without doind the change, but does not work on the EP1C20 board that does have the change. Strange stuff going on. 

 

Nir
0 Kudos
Altera_Forum
Honored Contributor II
268 Views

now, I meet the same problem. 

when I design the socket between up3 board and compactflash, because the compactflash works in TRUEIDE mode ,so I directly attached the atasel_n pin to GND. rfu and we_n pin to VCC,and I don&#39;t allocate pin to the reset,power pin . is it ok???????? 

 

and when I masked " 

for(ucWrite = 0; ucWrite < 10; ++ucWrite) 

IOWR_ALTERA_AVALON_CF_IDE_SECTOR_NUMBER(ide_base, ucWrite); 

ucRead = IORD_ALTERA_AVALON_CF_IDE_SECTOR_NUMBER(ide_base); 

 

if(ucWrite != ucRead) 

iGood = 0; 

printf("IDE_initialize(): error: verify fail: wrote 0x%X, read 0x%X\n",  

ucWrite, ucRead); 

 

if(iGood) 

if(IDE_getVerbosity()) 

printf("IDE_initialize(): wrote and verified %d values successfully.\n",  

ucWrite); 

else 

printf("IDE_initialize(): error: failed register write/readback test.\n"); 

return -1;" 

 

the programme executes until "IOWR_ALTERA_AVALON_CF_IDE_CTL(ctl_base, ALTERA_AVALON_CF_IDE_CTL_IRQ_EN_MSK);" ,then stop. 

 

but when i mask " alt_irq_register(ide_irq, 0, IDETrapHandler);" ,it can continuously execute. 

 

 

and I don&#39;t know how to set the power_ from the cf_0 pin in sopc
0 Kudos
Altera_Forum
Honored Contributor II
268 Views

??

0 Kudos
Reply