C6474EVM Timer interrupt and DSP/Bios

My suspicion is that something is causing a stack overflow or stack corruption. Nothing jumps out at me, but there is a lot of other code that you need to examine and debug.

Curiously, what do you want to really do every 200us? This is obviously sanity-test code, which is certainly a smart thing to do.

Three things you might try are:

1. Remove the LOG_printf's or use a counter to only print them once every 50-100 iterations. That is a lot of data to be dumping out.

2. Try SEM_pend/SEM_post instead of the binary versions. This is not the likely problem, but it might lead to different results that could help you figure out what is wrong.

3. Turn on optimization to improve the performance of these two functions.

Please let us know what you find out.

Hi Randy,

Thanks for the suggestions :-)

I have tried Your suggestions below,

1. Removing LOG_printf --> no effect

2. Replacing Binary version of SEM with SEM_pend and SEM_post --> no effect

3. Turning on Optimization --> Improved the performance but not fully solved (crash occurs below 1ms).

But,

After Disabling the PRD module(i.e. Unchecked the PRD module from using the CLK Manager) IT IS WORKING good on even 5 Microseconds.

Can u please provide comments( Reason) on this.?  

Thanks,

Bala

We can see if anyone in the BIOS forum can help to answer this. The problem would seem to either be a performance issue or a resource conflict issue, at least from what I can picture. The mechanisms for the PRD module and the effect of turning it off will be better understood by the people supporting this BIOS forum.

If it is a performance issue, then I would have expected removing the 2 LOG_printf statements to have at least increased the number of interrupts before the crash occured, but there was no effect. Yet optimization did have an effect, which again points to a performance issue. So this is confusing for me.

Hi Karl,

I have checked each Task stacks through Kernel object view, it has enough free space.

can u please give any other suggestions?.

Thanks,

Bala  

Hi Randy,

I have checked, increasing the Stack size by 50%.

but, it gives the same Result.

here is my .cmd file sections, any suggestions on this?,

SECTIONS
{
.far:scratch1 align=256> L1D_RAM
.far:scratch2 align=256> L1D_RAM

.boot: > L2RAM
.text: > C0_DDR_PROG_RAM
.cio: > C0_DDR_DATA_RAM
.vectors: > C0_DDR_PROG_RAM
.fasttext: > C0_DDR_DATA_RAM
.cinit: > C0_DDR_DATA_RAM
.bss: > L2RAM
.const: > C0_DDR_DATA_RAM
.far: > C0_DDR_DATA_RAM
.switch: > C0_DDR_DATA_RAM
.pinit > C0_DDR_DATA_RAM
.printf > C0_DDR_DATA_RAM

}

Also, please find the attached .Tcf file(change the .txt extention to .tcf).

Thanks

Bala 

Did you try Karl's primary 3 suggestions? Mine was just a fourth to add to that list.

You seem to have conflicting uses of L1D SRAM. This memory is flexible in that it can be used as SRAM or as Cache, but these uses are in direct conflict with each other in terms of the use of portions of the physical L1D RAM memory range from 0x00f00000 to 0x00f07fff. When you configure any part as cache, that amount of L1D SRAM is reduced from the higher addresses down. L1D SRAM, if any is available, always starts at 0x00f00000.

If you configure BIOS to have 32K Cache in L1D, then no L1D SRAM space is available. If you manually define an "L1D_RAM" memory component in BIOS and assign variables to use that space, such as .far:scratch1, then you create a memory conflict that will have devastating results.

BIOS automatically creates an L1D_CACHE memory component for you when you set the cache size in BIOS. This is intended to force you to avoid that memory range in your application by not allowing you to create another memory component in the same address range. It is not a perfect implementation, since it does not follow every change such as changing to 0K Cache, but it is a good implementation.

Looks like you are using standard TI EVM board.  If so, we can reproduce here.

Can you please make a .zip file with all the files necessary to rebuild your sample app -- we need the .pjt and all the .c and .tci, .h, etc files.

Please be clear on what the failure mode is.  That is, if we put breakpoint on main(), it sounds like we will hit this b/p after 254 (or similar) interrupts meaning that the code has reset/restarted?

Thanks,
-Karl-

Sorry Karl & Randy, I am not able to get approval for sending the zipped file(Source file) from my Higher management.

I have checked your suggestions, and here is my observation below link,

http://e2e.ti.com/support/embedded/f/355/p/65645/240879.aspx#240879

Can u please give any other suggestions.?

Thanks,

Bala

In order to avoid having 2 threads going, I am going to mark that other post  "answered" and reference this post.

Please put additional information here so we can track it in one place.  Multiple posts on same issue make tracking and support all the more difficult.

I did not see specific answers to my 3 recommendations.

One other idea (based on the exception on that other post) is that  you are getting an exception.  The NMI return pointer (NRP) points to the instruction at/near the source of the exception.  Can you look at NRP and see if that's a clue?

We need a test case to reproduce here.  Can you make a test case w/o any proprietary code so we can reproduce?  Without a test case and/or additional information, we can't do much.

Thanks,
-Karl-

Hi Randy and Karl,

Here i am happy to inform you that the Issue got solved,

just by increasing the main Stack size and re-organizing the memory.

Thanks for your valuable responses and suggestions :-).

Thanks,

Bala