• State
  • Replies 4 replies
  • Subscribers 83 subscribers
  • Views 117 views
  • Users 0 members are here
Support feedback
Options
Options
Related

C2000WARE: Impact of code change between sysctl.c versions (driverlib C2000Ware 5.05 vs 4.03)

david Baltaro
Prodigy 10 points
Part Number: C2000WARE
Other Parts Discussed in Thread: TMS320F280049C, TMS320F280049-Q1

Tool/software:

Hello Support, 

We have developed an airborne application based on the 280049 microcontroler whose drivers are mainly derived from C2000ware version 4.3 for CLOCK/PLL setting and control (sysctl.c)

Today, while reviewing our code and comparing it to the latest version of C2000ware (5.05) and the latest release of TRM, we noticed that certain timings and retries have been modified

1) when waiting for X1 clock to saturate

added a timeout option to exit the loop :

2) when turning off the PLL 

added a Delay of at least 60 OSCCLK cycles required between  powerdown to powerup of PLL

3) when writing the divider in SYSCTL_O_SYSCLKDIVSEL / SYSCTL_O_XTALCR / SYSCTL_O_CLKSRCCTL1 registers

added a delay

SYSCTL_REGWRITE_DELAY i.e.  asm(" RPT #39 || NOP")

4) When checking missing clock failure

added a counter option to exit the loop , and stop the program execution

Can we live without these changes or they really must be implemented in our code ? 

We are at a stage where modifying our code will require us to rerun all our high-level tests and replay some low level tests. 

Thank you by advance.

David

  • 0
    Prodigy 10 points

    No reply ? If no one has an opinion on this, could you at least tell me the reason for the changes to the delays after the PLL shutdown (3-->11) and the introduction of SYSCTL_REGWRITE_DELAY?

    We have been using code from C2000ware version 4.03 for two years without any issues so far. But could this cause problems with certain masks or microcontroller families (280049/280045) or certain variants (TMS320F280049-Q1/TMS320F280049C) or certain packages?

    Thanks

    David

  • 0 in reply to david Baltaro
    TI__Expert 8011 points

    Hi David,

    As per the datasheet, there should be a 60 cycle wait after PLL is power down. Please have a look at the E2E - (+) TMS320F280049C: C2000Ware v4 uses 24 cycles instead of 60 cycles for PLL turn off - C2000 microcontrollers forum - C2000Tm︎ microcontrollers - TI E2E support forums

    Regarding the SYSCTL_REGWRITE_DELAY, please have a look at the "System control register configuration restriction" section in the TRM where it mentions regarding the delay between subsequent writes between certain sysctl registers. We have added the delay based on the TRM descriptions. 

    Thanks

    Aswin

  • 0 in reply to Aswin P
    Prodigy 10 points

    Ok, thanks for you reply. 

    1) Regarding the SYSCTL_REGWRITE_DELAY, "System control register configuration restriction" seems appear in revision G of sprui33 but not in revision history of this document. It's a problem for us, because we can't track differences between each 3000 pages document revisions as they are published.

    Is there another place where the exhaustive document revisions are traced to prevent this case to happen again ? in Jira for example ? 

    And if I understand well the §3.14 of  System Control Register Configuration Restrictions, Each time we write on registers listed in table 3-19, we must add a delay (SYSCTL_REGWRITE_DELAY) depending of SYSCLK frequency.

    It worths for 2 writes on the same register (like SYSCTL_O_SYSCLKDIVSEL displayed above) or 2 writes on any registers listed in table 3.19 ?

    2) for the evolutions of C2000ware code, I have seen that there is a git where versions are managed

    GitHub - TexasInstruments/c2000ware-core-sdk: Repository for C2000Ware

    but very few issues tracking

    Are issues tracked in jira ? could you please provide a request to retrieve them ?

    Our goal is to address changes/modifications (from TRM or C2000ware) as they arise, in order to avoid having to deal with these changes at the end of the project.

  • 0 in reply to david Baltaro
    TI__Expert 8011 points

    Hi David,

    Let me check with the TRM experts if we can track the changes across TRM revision history. 

    david Baltaro said:
    It worths for 2 writes on the same register (like SYSCTL_O_SYSCLKDIVSEL displayed above) or 2 writes on any registers listed in table 3.19 ?

    The delay is added between subsequent writes of the registers in the table, otherwise the second write can be lost.

    As per the TRM, you need to add the delay so that proper write is happening to the registers without any failed case.

    david Baltaro said:
    Are issues tracked in jira ? could you please provide a request to retrieve them ?

    Yes, we have internally created JIRAs for tracking the issues. We publish few high priority items for the external visibility.

    You should be able to find the new issues that has been fixed in the release in the release notes.

    Thanks

    Aswin