• Not Answered

About 6701 EMIF CE0-3 configuration

Hi

       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!

5 Replies

  • 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

  • In reply to 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?

  • In reply to liu george:

    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

  • In reply to 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

  • In reply to liu george:

    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