5515 EZDSP CSL MMC/SD library random problems

Hm the links are working fine if you copy and paste them. But I attached the code.

I think that this misfunction is depending on a initialization and or memory error... GPIO did quit working too today. Then I installed CCS and CSL on another computer and voilá - GPIO worked just fine. I deleted the comment around my SD card part and tried it again. Nothing, it quit working after the point Memory Access will use Byte Addressing - as usual.

I don't kow, it feels a bit like a misfunction during initialization and/or memory ...

Greetings

1526.CC_Workspace.rar

After another day of work I'm pretty sure the reason for all this trouble is some initalization and or memory problem.

Proof:

a) The behaviour is very random from the time point of view.

b) Sometimes GPIO, sometimes the filesystem doesnt work

c) I had a CIO error today which brings me to the clue that the heap isn't big enough (I flush every printf with \n

d) I had the following error 3 times:

Error connecting to the target:
Error 0x80000242/-1140
Fatal Error during: Memory, Initialization, OCS,
JTAG protocol reset.

So ... I guess there is something totally wrong but not with my code.

Cheers

Hi Marc,

It sounds like the stack overflow. I looked through your code and did not find anything wrong. Try to increase the stack size for the program. You will need to right click on the project --> Build Options --> Linker --> change the Stack Size and System Stack. 

If you are still using the project file from the CSL SD example 4, then it is DSP/BIOS based. You will also need to change the stack size for each task.

1. Open the TCF file (VC5505_CSL_BIOS_cfg.tcf) under DSP/BIOS Config folder within your project

2. Go to Scheduling --> TSK - Task Manager --> for each task under TSK do:

-- right click on the task --> Properties --> change the Stack Size and SyStack Size.

If you still have problem after the stack size changes, we will need you full project to be able to further debugging.

BTW, looks like you are using the C5515 eZdsp USB Key. Is that right?

Best regards,

Ming 

Yes, I am using the eZdsp USB key. But I'm not using the SD Example Project File. I have my own project and made a .c/.h combo to use the filesystem. So I think it doesn't need the BIOS. Especially because it is working - usually. I expanded the code with some code from the ata_fs_func file - this is working too.

My stacksize is - according to the forum - 0x1000. Is it too less? Also, since today I cannot do anything. Everytime I lauch my program I get a CIO error, GPIO isnt working anymore and the filesystem is failing sometimes. So, I have to fix this before going on (too bad that those things always happen if you don't have any time ...).

Should I change the heap size? If so, which one is the right one?

Cheers

Edit: I increased the heap size to 0x14000 but that didn't help. I attached my .map file to this post, maybe this is helpful to see if there's something wrong with my memory1586.bats_project.rar

Hi Marc,

Did you change the system stack size also? In general, you will need the half of the stack size for system stack.

The sizes of the stack and system stack are depending on how do you allocate the local varibles inside the function and how many levels of the embbeded function calls you are going to use. If you allocate large local array inside the function, then you will need large stack and system stack.

The other thing that may cause problems is the set up for interrupt service routines.

If you still have problem, I will need your whole project to do the further debugging. If you do not feeel comfortable to post you code on this forum, you can leave your email or phone number. I will contact you to work out a way to review your code.

Best regards,

Ming

There is nothing that special that I cant post it here. Thanks for your help! It's a pitty ... I know what the problem might be but I can't locate it :/

4370.bats_project_proj.rar

I hope you can help me soon... time is running unfortunatly. I ignored the problem so far because I thought it's just a emulator issue but now I know it isnt...

Cheers

Hi Marc,

I got your project and reproduced the problem on C5515 EVM. The root cause is that the printf() inside the GPT ISR. The printf() is done by the C runtime support library. It is very intrusive. It will disable all the interrupts and halt the CPU. It also takes long time to complete. You have set the GPT timer 0 at 300Khz, so the printf() will be called 300K/sec. It cause the CIO error. If you change the code as following. The program will run well:

Uint32 gpt0Count = 0;
interrupt void gptISR0(void){
 hit_ISR=1;
 
 //printf("\nISR0 geht\n");
 gpt0Count++;

 IRQ_clear(TINT_EVENT);
    /* Clear Timer Interrupt Aggregation Flag Register (TIAFR) */
    CSL_SYSCTRL_REGS->TIAFR = 0x01;
}

Best regards,

Ming

Okay that's a point. I didn't see that, maybe because of the other issues.

I deleted this printf and everythings fine with CIO. But: I still have the printf that GPIO doesnt work. I don't have a oscilloscope here right now so I can't tell if it is working or not but I guess it doesnt (it didn't in the past days).

So, I guess the issue with GPIO or filesystem doesn't work temporarly is still there ...

Hi Marc,

The GPIO is the one which may lock the system up. It is also caused by the printf() in the SetPin(). Please change your code as follows:

Uint32 gpioCount = 0;
void setPin(CSL_GpioPinNum pin, Uint16 wrBuf){
  status = GPIO_write(hGpio,pin, wrBuf);
  if(CSL_SOK != status)
  {
   //printf("Fehler beim schreiben in gpio_write\n");
   gpioCount++;
  }
  status = CSL_SOK;
}

Your program works fine after the change, since the gpioCount increases OK.

One thing which puzzles me is that the gpioCount is only half of the gpt0Count. According to your program, they should have about the same value. After I reduced the gpt0 frequency by 16 times (change 0x53 into 0x0530) the problem went away. It tells me that the 300Khz is too fast for the CPU frequency (I used 100Mhz).

One more thing, in your main(), you open and write data to File1.txt, but you did not close it. This will cause your file corruption. Please add ATA_close() after the last write operation. This way, your file can be read later either in ATAFS or by Windows.

Best regards,

Ming 

Hi Marc,

There is another thing in your program. It may cause some issue later.

The create_file() creates file blindly. It does not check for the existing files for same file name. It may create several file with same file name. You may want to use the open_file() instead in main():

 //err = create_file(newFile);
 open_file(newFile);
...

 //open_file(newFile);
 ...

close_file(newFile);

By the same token, mmcConfigFs(test) in main() also may create test.txt many times, if you run the same program mutiple times, so the

 /* Created by Marc
  * Delete the file */
 ATA_delete(pAtaFile);

is necessary.

Best regards,

Ming 

Hey

Thank you so far. I try to check the GPIO thing tomorrow, maybe on monday.

I cannot imagine that this processor cannot run a timer interrupt with 300khz. This should be nothing for a DSP. Also, the timer is programmable by a 32bit register, and I am using 8. I run the interrupt with 134khz perfectly - with a printf and gpio. So, 300 should run too.

Cheers.

Hi Marc,

The problem is not the timer 0 interrupt. Once the printf() is removed, the timer0 ISR works as expected (at 300khz). What may take too long is the SetPin(). Even without the printf(), gpioCount cannot reach the same frequency as the gpt0Count (the timer0 interrupt). It can only get about 150Khz. When I reduce the timer0 interrupt frequency to 19khz (300/16), then the gpioCount maches the gpt0Count. 

Best regards,

Ming

Allright ... Is there any chace to get the GPIO running at 300khz? I don't need it (i'm doing it due to debug reasons), I'm just curious. I am using setpin because of the GPIO handler which is in init.c. It didn't work with a new handler (of course it didnt).

Cheers

Hi Marc,

I did further investigation on your code. Here are what I found.

1. First of all, the ATA_fopen() has a bug which did cover one corner case -- when the SD card has no file in it. You will need to add the following code section to ATA_fopen()

 // find the first file in this drive
    ata_error = ATA_findFirst(pAtaFile);
 if (ata_error==ATA_ERROR_EOF)
 {
  ata_error =  ATA_fileInit(gpstrAtaDrive, pAtaFile);

  /* Set the temp write buffer */
     (pAtaFile->pDrive->_AtaWriteBuffer) = AtaWrBuf;

  // set the file name and extension name
  ata_error |= ATA_setFileName(pAtaFile, name, ext);

  /* Create a file, returns 0 for successful creation*/
  ata_error |= ATA_create(pAtaFile);

  return ata_error;
 }

Of course, you can also add a dummy file into the SD card instead of change the code.

2. Your newFile did not initialized properly. It has a hanging pointer newFile->pAtaFile which in turn causes the memory error. Please add the following code in main():

 newFile->pAtaFile = &(newFile->strAtaFile);
 open_file(newFile);

3. The  IRQ_clear(TINT_EVENT); in gptISR0() is not necessary. It will be cleared when CSL_SYSCTRL_REGS->TIAFR = 0x01; is executed. It actually cause the unmatching value between gpt0Count and gpioCount. After I comment out IRQ_clear(TINT_EVENT);, the count values are matching.

4. For some reason the SPI is not working properly. I have to disable the SPI_init, SPI_open and SPI_config to make the timer0 interrupt and gpio polling work.

5. The GPIO interrupt is not happening on my EVM.

Best regards,

Ming

1) I will add this part. It makes sense that this is important. But if so, why isn't it included in the ata_ext_func.c?

2) Mh I thought (file->pAtaFile) = &(file->strAtaFile); inside create_file is working?

3) I thought that it is not necessary but I was unable to find further information and it was included in the gpio interrupt example.

4) Mh is there any reason why?

5) It cant' because in my original code IRQ_Plug for GPIO events is disabled (I commended it out).

And another question: Is there any chance to produce a clock with 134khz at a pin which is accesable?

1) It is a bug, we will add it into the next CSL release.

2) It should be in open_file also, because open_file can be called before or without create_file().

4) I do not know. You can post another forum question on this issue.

C5515 is a 100Mhz or 120Mhz part, 134Mhz is out of spec range. In general you can program system clock (PLL) to the specific frequncy , then output it to the CLOCKOUT pin by set CLOCKOUT Clock Source Select Register [0x1C24] bit [3:0]to 1011.

Best regards,

Ming 

1) Okay

2) Oh, maybe I forgot to add it there ... Mh then I have to change something there thanks ;)

3) Okay

4) 134kHz - kilo - not Mega ;) And I don't want to program the PLL down to 134kHz instead of 100Mhz because this would mean that I slow down the entire system

Allright, thank you so much.

Hi Marc,

4) If you are not using I2S and you do not care the power consumption, then you can configure the I2S CLK to be 134Khz, and use the I2S CLK for your usage, because only I2S has the continuious clock which may meet your requirement.

Best regards,

Ming 

That's a idea. But isn't the audio codec connected via I2S? If so, can't it be that I run in trouble? Anyway, I could also toggle a GPIO pin.

As long as I don't have SPI in my code it is working fine. But As soon as I have SPI in my code, GPIO stops working (the ISR is working fine...). Also SPI is not intializing properly (see other thread).

Thanks for your help! I really appreciate this form of support.

Hi Marc,

Yes, on the eZdsp kit, the I2S0 has been used for the audio codec and I2S1 has been used for micro SD card. The I2S2 is available.

Here is a thought about the SPI and GPIO conflict:

In SPI_init(), it sets the PP mode to MODE 5 (which enables the SPI, UART and LCD). In your case, you may want set it into MODE 6 (which enables the SPI, GPIO12-17, I2S2 & 3).

Best regards,

Ming

I found this issue a few seconds before I got your email. Mode 1 should also work. But both are not working. Also SPI is still not initializing properly. Sometimes it initializes, sometimes not (then I stop debugging and try it again and it works...).

Cheers