Problem with BIOS usage in DM6467

Unfortunately I am not very familiar with the HDVICP, as in general this accelerator is supported directly through local TI support so my thoughts on this may be only part of the story.

Siva said:

In fact after enabling optimization & excluding symbolic debug, the decoder worked fine with BIOS also. But when I enabled EDMA related functions (#if) the problem started again. Please note, I am not using EDMA for memory transfers. Only EDMA initialization is done.

Since it started working when enabling optimization and removing debug information that makes it sound like to me that there is some real time deadline that is not being met with the C64x+ servicing the HDVICP, as the only functional difference should be the execution time lessening with adding optimization and excluding symbolic debug. If this is the case perhaps you could resolve it out by lowering the load on the HDVICP (lessening the real time deadline) or by further increasing the response time of your C64x+ side code (better meeting the real time deadline), for a test with the optimized code that works it would be interesting if you could break it by putting in delay loops in the code, that could help to narrow down the issue to some code timing problem.

Assuming that you are getting the same failure with the EDMA initialization in the code than it is possible that just the act of initializing the EDMA is changing the execution timing of your code and breaking the same real time deadline, however it is also possible that the EDMA configuration is having some other adverse effect on the HDVICP.

Dear Bernie,

Thanks for your kind and informative reply.

The decoder I mentioned does not run in real time. All the co-processors are triggered in serial fashion (one after the other). In fact the triggering of next co-processor takes place only if the previous one has finished its job. No matter how much time it takes, C64x has to wait until its job is over.

I commented the EDMA intialization API call also. The problem occurs even if I include the EDMA related .c files into the project (please note, no functions from these files are called anywhere in the decoder).

Do you think, the space occupied by the EDMA related object code in the final binary can create some problem. The size of object could be more, since EDMA relies completely on BIOS routines.

Few more hints & suggestions please.

Thanks in advance.

Siva

Siva said:

Do you think, the space occupied by the EDMA related object code in the final binary can create some problem. The size of object could be more, since EDMA relies completely on BIOS routines.

That is another good theory, and is another tangible difference between optimized code and unoptimized code, if the memory map is not being managed safely than that could also cause failures depending on how code was built and what is included. Since the HDVICP appear to be actual processors, this could be a real problem if they were using any of the memory space that the C64x+ is using for code/data storage, though since I am not very familiar with how the HDVICP cores operate I am not sure if this is really a potential problem or not. In any case it may be worth going over your memory map carefully to ensure everything is fitting properly and how you expect, CCS cannot warn you if your build has memory mapping problems outside the scope of the DSP itself (i.e. if the co processors are inadvertently using the same memory spaces).

Siva said:

Do you think, the space occupied by the EDMA related object code in the final binary can create some problem. The size of object could be more, since EDMA relies completely on BIOS routines.

That could well be one of the reason. From your posting I understand that:

1) Initially when you ran the program with Debug turned on and without optimization the resulting code size would have been considerably larger and hence you encountered the problem.

2) When you turned on the optimization and disabled Debug, the code worked as desired as the optimization may/would have reduced code size.

3) But when you inserted another source file, the code size might have just increased enough to cause the problem again.

The best way to verify the above would be to compare the map files generated in (2) and (3).

-Vallabha