• State
  • Locked Locked
  • Replies 62 replies
  • Subscribers 39 subscribers
  • Views 21219 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Tiva reset problem

Hiroyasu Tazawa1
Guru 12350 points
Other Parts Discussed in Thread: TM4C1294NCPDT, TM4C129DNCPDT

Hi

I need your help.
We use EK-TM4C1294X EVM with CCSv6.0.1 and Tivaware v2.1.
and my EVM has TM4C1294x rev3.

I made sure LEDs and GPIO sometimes are not able to control after Hard or Soft reset.
I do test this blinky2 Program.

This program is turn on LED2 and Soft reset after initialization.
If you run in stand-alone, this problem appear after half hour I guess.
The probability of occurrence of this problem is the very low.

This program's LED light will be difficult to see.
Brcause wait cycle is short after LED is flashed.

and If you run without SysCtlClockFreqSet(), this problem will not appear now.
I do not know why this situation appear.
Do you know about SysCtlClockFreqSet() has some bug or some other bug?
I confirm Software reset, but actually I wanna confirm Hard reset.

Best Regards
Hiroyasu

  • 0 in reply to Daniel Haslimann
    TI__Guru**** 244400 points
    Hello Daniel,

    That was the original workaround proposed for the issue. If you are building the software out of the source file, I would like to confirm the values of RSCLKCFG, MEMTIM0, PLLFREQ0 and PLLFREQ1 registers after SysCtlClockFreqSet is executed. Also to be able to check the values I would need to know what crystal frequency are you using and what is the system clock being set as.
  • 0 in reply to Amit Ashara
    Intellectual 810 points
    Hi Amit

    Our call to SysCtlClockFreqSet is as follows:
    g_ui32SysClock = SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL |
    SYSCTL_CFG_VCO_480), 120000000);

    The external oscillator is clocked with 25MHz.
    State after the call is:

    RSCLKCFG: 0x33300003
    MEMTIM0: 0x01950195
    PLLFREQ0: 0x00800060
    PLLFREQ1: 0x00000004

    Best regards,
    Daniel
  • 0 in reply to Daniel Haslimann
    TI__Guru**** 244400 points
    Hello Daniel

    Just as I suspected. If the new function from sysctl.c had been tkane then RSCLKCFG value should have 0x33000001 and not 0x33300003

    I am sure that either the older driverlib.lib is being taken or that the new sysctl.c has not been correctly compiled and linked to your project.
  • 0 in reply to Amit Ashara
    Intellectual 810 points
    Hello Amit

    Thank you for your answer.

    Sorry, I was unclear on that.
    The values I have given you are with the old sysctl.c

    When I use the new sysctl.c:

    RSCLKCFG: 0x13000001
    MEMTIM0: 0x01950195
    PLLFREQ0: 0x00800060
    PLLFREQ1: 0x00000104

    So are the "old" values wrong?
    The reason why I rolled back to the old version was, that the new version didn't fix the problem. The system still crashed.

    Now when I disabled the flash prefetch, the problem is gone.

    Best regards,
    Daniel
  • 0 in reply to Daniel Haslimann
    TI__Guru**** 244400 points
    Hello Daniel

    That explains why we were seeing the old values. Interestingly I was not able to reproduce the issue with the new version. The flash prefetch disable shall also help.
  • 0 in reply to Amit Ashara
    Intellectual 540 points

    Hi Amit:

    Sorry, I know this thread is old post, but we encounter the same issue recently.

    I am wondering if this issue is able to link to TM4C129x errata SYSCTL#23.

    ==============================================================================

    SYSCTL#23 MOSC as the Source to OSCCLK may Cause a bus Fault on Reset
    Revision(s) Affected: 1, 2, and 3.
    Description: MOSC as the source to the OSCCLK may cause a bus fault on reset. This may happen
    even when using the PLL as SYSCLK and configuring the MOSC as the source for
    OSCCLK. Please see the following image on the affected clock path.

    Workaround(s): Do not use MOSC as the OSCCLK source. There are two workarounds for application
    using SysCtlClockFreqSet API.
    • Update the SysCtlClockFreqSet API as shown in Appendix 3
    • Use the SysCtlClockFreqSet API in flash from TivaWare 2.1.3 release onwards.

    ==============================================================================

    We do observe there is bus fault when issue happened.

    However, my question is about the workaround.

    Can I keep the driverlib in Tivaware 2.1.0 (our shipping version) and apply following simple change which you fixed in this thread?

    ===============================================

    replace
    ui32OscSelect = SYSCTL_RSCLKCFG_OSCSRC_MOSC;
    with
    ui32OscSelect = SYSCTL_RSCLKCFG_OSCSRC_PIOSC;

    ===============================================

    Now we are doing stress test with this simple change and it works pretty fine without bus fault.

    Could you let us know why TI suggests Appendix 3 or Tivaware 2.1.3 for this issue?

    Thank you.

  • 0 in reply to Jiayang Wu
    Intellectual 300 points

    Other errata also required changes to that function and they elected to just provide a new version instead of a diff and and an explanation of which changes go with which errata. Even if your change is sufficient to avoid SYSCTL#23, if you don't take the other changes to the function you may run into SYSCTL#22 (occasionally a divisor of 2 will be used instead of PSYSDIV).

  • 0 in reply to BB_
    Intellectual 540 points

    Thank you!

    Since we only encounter bus fault during our field test, we have no idea about the happened rate of errata SYSCTL#22.

    We will try to reproduce SYSCTL#22 (PLL setting issue) in the following days.

    BTW, workaround TivaWare 2.1.3 is not a small change for our application (shipping products) since it limits SYSCLK to 60M or 120MHz if there is USB function.

    Hope there will be other workarounds which will not impact system clock setting.

  • 0 in reply to Jiayang Wu
    Genius 4455 points
    Is this issue fixed in latest TivaWare?
  • 0 in reply to twelve12pm
    TI__Guru**** 244400 points
    Hello Jiayang

    TivaWare 2.1.3 fix is the only robust fix for the issue
  • 0 in reply to Amit Ashara
    Genius 4455 points
    We are using TivaWare 2.1.4.178 so I will assume it incorporates the fix from 2.1.3. Thanks
  • 0 in reply to twelve12pm
    Intellectual 540 points

    Hi Amit:

    Got it. We must use TivaWare 2.1.3 or later for robust fix.

    I have one more question. We've done stress test on Tiva Connected LaunchPad with TM4C1294NCPDT on it, but issue SYSCTL#22 could not be reproduced over 24-hr test. On our customized board with TM4C129DNCPDT, issue can be reproduced within 5 hrs.

    I am wondering if SYSCTL#22 is related to board hardware design (such as power circuit or crystal selection). Or TI has fixed this issue on TM4C1294x series.

    Could you help to clarify it? Is it board-level issue or chip-level issue?

    Thank you.