This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28069: Setting for Flash/OTP Access Timing

Part Number: TMS320F28069
Other Parts Discussed in Thread: CC2520

Hi there,

I am using the micro controller TMS320F28069. In the datasheet, Table 5-15 Flash/OTP Access Timing, it says the minimum paged/random flash access time is 36 ns. But in my application, I have to set the access time to be higher than 160 ns. Could you give me some suggestion on what may affect/increase the access time for the flash?

Thanks,

Dan  

  • Dan,

    How are you measuring the flash access time?

    It may have something to do with the number of waitstates you have configured in the flash registers. How many waitstates have you configured the flash wrapper for?

    sal
  • Dan,

    By default, both paged read and random read are set to 15.

    So, when the device is operating at 90MHz, this accounts to access time of 177.8ns
    So, when the device is operating at 80MHz, this accounts to access time of 200ns

    Regards,
    Manoj
  • Dan,

    Flash reads are guaranteed to work ONLY when flash access times are met. Having access time greater than 36ns just means that you reading the flash slower.

    Regards,
    Manoj
  • Hi Manoj,

    Thanks for your reply. Do you mean that not all microcontroller can read at the minimum time 36 ns? What factors may slow the speed? I want to optimize the performance of the microcontroller so I set a value less than the default 15.

    Thanks,
    Dan
  • Hi Sal,

    I didn't measure the access time. I set the number in the register to determine the access time. When I set less time, the controller does not work. I set both waitstates as 13 at 80 Mhz.

    Thanks,
    Dan

  • Dan,

    No, on all F28069 devices, if you configure your waitstate to meet the minimum flash access time of 36ns, it is guaranteed that flash reads / accesses are good.

    The tables in DS just suggests that user need to configure the waitstates depending on their SYSCLK frequency to make sure minimum flash access time is met.

    For SYSCLK = 90Mhz, minimum flash wait state required = 3. I suggested default state because you said wanted a minimum access time of 160ns.


    Regards,

    Manoj
  • Dan,

    If your code works fine when your flash access > 160ns, check your SYSCLK freq as flash wait state is tied to SYSCLK freq as mentioned in DS.

    Regards,
    Manoj
  • Hi Manoj,

    I want to set the access time as short as possible. The SYSCLK is set as 80 MHz and I followed the DS to set the waitstates as 2 to achieve a 37.5 (=12.5*3) ns access time. But the microcontroller did not work. It made other components such as radio (CC2520) fail to work. Only if I set the minimum access time above 160 ns, the whole system works fine.

    Do you know what may cause the problem?

    Thanks,

    Dan

  • Dan,

    My initial suspect would be SYSCLK freq. Did you try bringing out SYSCLK onto XCLKOUT and check it on oscilloscope?

    When you say your system doesn't work. What exactly happens? Are you able to see the problem only in standalone mode (or) you also see the problem with JTAG connected.

    I would also suggest you to try reading the flash contents with minimum waitstates and check the data integrity of flash.

    Regards,
    Manoj
  • Dan,

    I haven't heard back from you for a while. Is your issue resolved? If so, can you please close this thread.

    Regards,
    Manoj
  • Hi Manoj,

    Sorry for the delayed reply. I didn't notice this before.

    I checked the SYSCLK, and it is 80MHz. When I set a small number of waitstates, the radio attached to the microcontroller does not work. Values in some registers of the radio are set to a wrong number.

    With JTAG connected, it also does not work.

    Thanks,

    Dan

  • Dan,

    If I were you, I would check at the following items:-

    First step in this debug process is to know whether flash reads are good at 80 MHz with 2 wait states. Did you already check whether all the flash reads are good across the flash sectors?

    Does your application code have any code / data in OTP? If so, you have to use 4 waitstates as OTP is slower than flash.

    It looks like your code is working fine with higher wait states. High wait state ensures the slower flash reads and hence slower execution. Do you have any communication port (or) any other piece of code which is timing critical? Can any timing (or) communication mishap cause change in application code execution?

    When you application code fails, does it go illegal instruction trap fetch? Does it unexpectedly find itself in BOOTROM.

    Is this a custom board (or) TI EVM board? I'm wondering whether the device is poweredup correctly.

    Do you see this problem on every single F28069 device (or) you see this problem on an isolated device?

    Regards,
    Manoj
  • Hi Manoj,

    Thanks very much for your kind suggestion. 

    1. How to "check whether all the flash reads are good across the flash sectors"? Now the only feedback that the device gives me is that values in some registers of radio chip are wrong. Is there other things that reflect the flash reads are bad across the flash sectors?

    2. I used a 4 waitstates for OTP but it does not work.

    3. The micro-controller has SPI communication with radio chip. I think this is some of my old questions - whether there are some issues may slow the flash read. So do you mean that if there are some communication with other device, the flash reads will be affected?

    4. I don't understand this question very well.

    5. It is a custom board. And I think the voltage that we provide is correct and powerup should not have any problem. What may be a wrong powerup?

    6. I see this problem on every board that we have.

    Thanks,

    Dan

  • Dan,

    TI guarantees that flash read / instruction fetches would work perfectly fine when recommended operating conditions and minimum waitstate requirement are met. I get a feeling that this is something to do with your application code which needs systematically debug.

    1) You have to set the flash wait states of 2 and read the contents on flash and store in RAM buffer. You can then compare the flash contents and RAM buffer contents to know flash reads work fine. If you seeing this problem on every device, i wouldn't worry about this.

    2) So, you do use OTP in your application. How exactly are you using OTP?

    3) I don't mean that communicating to other device would affect flash reads. I don't know much your application (radio chip), so it is difficult to comment what is going on. But, can the communication error / misalignment cause the application code to start executing different sections of code. Did you try single stepping your code to debug the issue.

    4) Generally when flash reads are incorrect. In all likelihood, CPU would receive an illegal instruction which would trigger Illegal ISR routine.

    5) If you power supplies are stable and are in recommended operating conditions. Then everything should be fine.

    Regards,
    Manoj