TI E2E Community
Digital Signal Processors (DSP)
C6000 Single Core DSP
C67x Single Core DSP Forum
About 6701 EMIF CE0-3 configuration
My program runs in extern SRAM by EMI . I reconfigure EMIF CE0-3 in code when 6701 chip fetchs instrcuts in extern SRAM.
Does the risk lead to error of fetching instructs. But it seems threre is no problem when running code .Why?
Thank for your any help!
The normal process is to configure the EMIF registers before loading the program code and any data into the external SRAM. In your case, how are you loading the code into the external SRAM? What is your bootmode, or are you using CCS?
The C6701 is a very old device, but it does its job well. I am curious, why are you using this device instead of a newer one?
Most likely, the EMIF timing registers default to values after reset that allow you to access the external SRAM, or you are using CCS and it is initializing the EMIF registers automatically without you being aware of that.
Search for answers, Ask a question, click Verify when complete, Help others, Learn more.
Some bootloader program load my program code and any data into the external SRAM .But I want to improve SRAM access speed .So configure the EMIF registers and
it works well. I worry the activity could affect fetching instructs in the external SRAM when configuring the EMIF registers .Could you give me some suggestion?
To confirm that doing this is 100% safe, you would have to do extensive testing. And neither you or I am qualified to do that extensive testing. You would want to hire an experienced TI Third Party to consult on this and make the recommendation depending on exactly what you want to do.
The preferred method is to copy the EMIF configuration code to internal program memory and make the changes in that relocated code, then branch or return back to the SRAM on the EMIF to resume your application.
It could be safe to do what you want to do, but anytime you make changes from within the area where the changes have an effect, great care and caution must be taken. It is predictably safe to do it the way I described above, from within the internal program memory.
First thank for your good suggestion.The program has run for three years without any problem.I suddenly think it and post the title ,just wish to understand the reason.
In addition, i can not clear the meaning of sentence "It could be safe to do what you want to do, but anytime you make changes from within the area where the changes have an effect, great care and caution must be taken. " Does it refer to my program? and what meaning is " but anytime you make changes from within the area where the changes have an effect,".Could you give me some instructions?
Your best source of understanding why it has worked for three years would be to look at the documentation from the original designer. Without doing that engineering work, it would be difficult for anyone to give you assurance that it is a good design. The fact that it has worked for three years is good evidence that it is a good design, if that is adequate for you.
RandyPIt could be safe to do what you want to do
If you do proper analysis of the exact configuration changes made, you could determine whether any fetches could be corrupted or would always be valid. The way you are doing it now is obviously working for you, but I cannot tell you it is a good design. I can only say that it could be an acceptable design. "safe" == "good design" == "acceptable design".
RandyPgreat care and caution must be taken
Analysis must be done or must have been done to determine whether this is a good design. That would be applying "great care and caution", meaning to do a good engineering analysis.
RandyPanytime you make changes from within the area where the changes have an effect
This is exactly what you were concerned with from the very beginning. You are fetching instructions from SRAM and those instructions are changing the way the SRAM is accessed. This is a potential problem, which is what you were worried about originally. The "changes have an effect" on the EMIF configuration, and if those changes cause a permanent or temporary disruption to the process of instruction fetches, then corruption could occur. The "area where the changes have an effect" is the SRAM where the fetches are getting instructions. "changes from within the area" means that you are executing instructions that will change how upcoming instructions will be fetched, and you are doing that at the same time as continuing to execute instructions that are being fetched through the interface that is changing. If a register gets a value that causes the EMIF to make a short pulse or disrupts the timing of a fetch while that fetch is in progress, that fetch could be corrupted and your program could fail.
But it is possible that no problem exists, and the fact that it works is evidence if not proof.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.