About 6701 EMIF CE0-3 configuration

Liu George,

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.

Regards,
RandyP

 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?

Liu George,

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.

Regards,
RandyP

Hi  RandyP

     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?

Regards

Liu George,

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.

RandyP

It 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".

RandyP

great 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.

RandyP

anytime 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.

Regards,
RandyP