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.

TMS320F28388D: Who is setting RWAIT (waitstates) to 3?

Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

Hello everyone,

according the manual the default value of  RWAIT is 15 and our application does not modify it.

As long as we flash our application (compiled with TI toolchain C2000 V21.6 or V22.6) and run it right away (i.e. without resetting neither the board nor the software) the RWAIT remains to 3.

Nevertheless, we experience that by triggering a Target Reset or a CPU reset ( through CCS Studio or Lauterbach) at next startup the RWAIT is set to 3. This is a bit annoying as it leads to inconsistent scenarios, depending on how the application has been started.

Thank you for your input.

Regards,

Ivan

  • Ivan,

    May I know why your application is not initializing the flash wait-states as per the operating frequency?  

    In both scenarios that you explained, RWAIT is set to 3 - Which scenario is inconsistent?  Please clarify.

    Flash programming tools modify the RWAIT to 3.

    Also, BootROM might be leaving it at 3 (I can check if needed).

    Thanks and regards,

    Vamsi

  • Sorry my fault, I want to say.. "As long as we flash our application (compiled with TI toolchain C2000 V21.6 or V22.6) and run it right away (i.e. without resetting neither the board nor the software) the RWAIT remains to 15".

    There's thus an incongruence between target reset and flashing and run it the software without reset. 

    There's no any particular reason why we don't modify the default value of 15,it's just a scenario we don't deal with yet. 

    Yes please check whether the BootROM affects the RWAIT.

    Thank you, 

    Ivan 

  • Hi Ivan,

    For performance reasons, it is required to change the RWAIT as shown in all of the C2000Ware examples.  

    Sure, I can check BootROM code and get back to you early next week.

    Thanks and regards,
    Vamsi

  •  Hi Vamsi,

    thank you for your reply.

    Nevertheless, the only constraint I can see is that for frequencies between 150 and 200 MHz RWAIT should be set to a value equal or greater than 3. So 15, even though we get a penalty in term of performance, should be fine. Furthermore, what I want to point out is that after a reset in any case RWAIT is initially set to 3, which is not the expected one after a clean reset as stated by the datasheet.

    Is there any requirement based on which RWAIT must be set exactly to 3 for frequency between 150 and 200 mMhz ? 

  • Hi Ivan,

    The documentation says 0xF as the HW default value.  However, BootROM might be leaving it at the desired value of 3.

    Yes, it is suggested to use at 3-wait.

    Does 3-wait cause any problem to your application?

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    thank you for your feedback.

    3-wait per se does not cause any particular problem.

    However, the crucial (and more important) point here is that our application runs with a waitstate value which differs from the expected default one and thus it goes out of our control. Furthermore, when we flash the application and let it run right away we have a 15-wait, whereas after a target reset 3-wait. Could you please explain this divergent behaviour? 

    Additionally, Is it possible to know exactly how the configuration of clock, waitstates, etc is affected by rts2800*.lib during the initialization phase?

  • Hi Ivan,

    I need some more info to analyze this further:  Is your application configuring the flash wait-states (as shown in all of our devices' examples) using the flash initialization routine provided in the C2000Ware?  Or is your application not configuring anything as needed by the application?  

    Irrespective of the whether BootROM is configuring the waitstates or not, user application is supposed to configure the device as needed by the application.  

    If not the BootROM, the flash programming utilities also configure the device as needed for the flashing procedure (TI flash utility is restoring to default value of 0xF) - Hence, all applications configure the device as needed by the application.  Please check the application once and let me know.

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    here are my answers to your question:

    "Is your application configuring the flash wait-states" -> We don´t configure the flash wait-states.

    "If not the BootROM, the flash programming utilities also configure the device as needed for the flashing procedure" -> I tried flashing our application with both CCS and Lauterbach. In both cases without reset I observe a 15-wait. After performing a Reset (POR, XRS, CPU Reset) I observe a 3-wait. 

  • Hi Ivan,

    Our BootROM team is not available up to 11th.

    As showed in the examples, please update your application to include flash initialization.  

    Thanks and regards,

    Vamsi

  • Hi Vamsi,

    ok I look forward to getting a feedback from your BootROM team once they´re back.

    Thank you!

    Regards,

    Ivan

  • Hi Ivan,

    Ok, I will keep this thread in pause for now.

    Thanks and regards,

    Vamsi

  • Hi Ivan,

    Our BootROM team confirmed that they restore the RWAIT value to the default at the end of the boot.

    Thanks and regards,

    Vamsi

  • Does it mean that the Bootrom changes the RWAIT to 3 and then restore it to 15? Could there be any reason why restoring the default value fails?

  • Hi Ivan,

    Yes, BootROM changes and then restores to 15.  

    It should not fail.

    Since this post has been closed for a month: If you would like to discuss further on this, please open a new post.  

    Thanks and regards,
    Vamsi