• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 2276 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS Boot module TM4C/E advanced clocking with PLL enable & PSYSDIV fails

Genatco
Guru 54358 points
Other Parts Discussed in Thread: EK-TM4C1294XL

Daniel Vamos said:
I have code which based on clock functions (ADC related stuff) and I didn't find any Timer example in the RTOS package

Hi Daniel,

We have several ADC sequencer samples @2MSPS rate that required PLL divisor be properly configured for SYSCLK 120Mhz.  That said and with great regret the latest TI-RTOS Boot module failed to achieve any such goal. Fact is the TivaC/E advanced clocking in Boot module was disabled for proper ADC clock speeds to occur using Tivaware SysCtlClkFreqSet(). Oddly ROV Boot shows output PLL=false yet the ADC and EMAC PHY run at the correct clocking speed. We could not get RTOS TM4C Advanced Clocking by itself to execute the application without quickly faulting after POR. The application seems to execute in slow motion prior to faulting. 

Something is not working well in Boot modules TM4C Advanced clock transition from PIOSC into MOSC, no matter if PSYSDIV (SYSDIV) is made 2 or 2.5 as typical setting.

Best of luck to you.

  • 0
    TI__Mastermind 26780 points

    BP101,

    Can you please provide more details about the problem you saw?  Including Tiva device type, the software versions you are using, and exactly what you removed from the Boot module?  

    Thanks,
    Scott

  • 0 in reply to ScottG
    Guru 54358 points

    Hi ScottG,

    This comment was actually more relative to NDK timing issue in another thread that also mentions ADC0 configuration. Point is some peripherals such as ADC may not correctly configure from PIOSC when the ADC has 2MSPS derived 32Mhz sample clocking or 480PLL/15, so it seems the likely suspect for Boot clock faulting EK-TM4C1294XL MCU. All present testing 2.16.0.14 seems improved though 2.16.0.08 failed to either set PLL=true or PSYSDIV bit was not be set value of 2, can't recall now. We use Tivaware SysCtlClkFreqSet() in main.c as WA to using RTOS TivaC/E advanced clocking. 

    Using TivaC/E advanced clocking for configuring SYSDIV/PLL divisor faults the application well before BIOS_start directive is ever being issued. The kernels clocking needs to be configured prior to executing (main.c) or well before RST sets the JMP to main and never after BIOS_start.

    This issue is relative a large migrated Tivaware project now using TI-RTOS System Analyzer for debugging as no other XDC tools seem possible to use without the RTOS kernel present.

  • 0 in reply to Genatco
    TI__Mastermind 26780 points

    BP101,

    We’re still not clear on the specific problem you saw, exactly what you were attempting to do, and if you are still seeing the problem.  Can you please clarify:

    “All present testing 2.16.0.14 seems improved”…  does this mean the problem you had is now resolved after upgrading to the latest release?

    “Using TivaC/E advanced clocking for configuring SYSDIV/PLL divisor faults the application”.  Specifically what fault are you seeing?  And are you seeing this when you call SysCtlClkFreqSet() in main()?

    You said in the earlier post “Fact is the TivaC/E advanced clocking in Boot module had to be removed”.  Can you please clarify what code you removed from the Boot module?

    Can you list the Boot module configuration settings you are using?  And also the parameters you specify when calling SysCtlClkFreqSet()?

    Thanks,
    Scott

  • 0 in reply to ScottG
    Guru 54358 points

    Hi ScottG,

    ScottG said:
    “All present testing 2.16.0.14 seems improved”…  does this mean the problem you had is now resolved after upgrading to the latest release?

    Same problem as earlier version RTOS clocking.

    ScottG said:
    Specifically what fault are you seeing?  And are you seeing this when you call SysCtlClkFreqSet() in main()?

    Bus fault Precise seems to ring a bell and SyCtlClkFreqSet() fixes what ever goes wrong after BIOS_start, have to assume the TivaC/E clocking occurs after BIOS_start?

    ScottG said:
    Can you please clarify what code you removed from the Boot module?

    Seemingly TivaC/E advanced clocking will not properly configure the ADC peripheral for 2MBPS sample rate if it executes after the configuration of said peripheral e.g. (BIOS_start), abruptly ends faulting CPU.

    ScottG said:
    Can you list the Boot module configuration settings you are using? 

    ScottG said:
    Can you list the Boot module configuration settings you are using?  And also the parameters you specify when calling SysCtlClkFreqSet()? 

    g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                          SYSCTL_OSC_MAIN |
                                           SYSCTL_USE_PLL |
                                            SYSCTL_CFG_VCO_480), 120000000);

  • 0 in reply to Genatco
    Guru 54358 points

    BTW: TivaC/E clocking SYSCLK/2 (PSYSDIV) also faults the MCU and SyCtlClockFreqSet() is not configured in (main.c). Seemingly we can't get the TivaC/E clocking to run the ADC0 2MBPS clocking (32Mhz ) configuration during PISOC, is issue in my mind. Could be wrong about that since many GPTM/PWM peripherals also get configured at Boot time in (main.c) calls.

  • 0 in reply to Genatco
    TI__Mastermind 26780 points

    BP101,

    OK, thank you for the additional information.

    The clock setup by the Boot module is done very early, before main(), and there is no additional setup of clock sources during or after BIOS_start().  So whatever is happening to cause the exception, it is not occurring within the Boot module code itself.

    I don’t know about the different clocking constraints of the ADC or other peripherals on these devices, and will have to loop in someone else to help with that...

    In the meantime, can you please try finding out where the exactly exception is occurring?  Can you try the steps in the FAQ, listed here: http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs#Exception_Dump_Decoding_Using_the_CCS_Register_View 

    I think if we can determine exactly where the exception is being generated it will be a big step towards finding where the problem is…

    Thanks,
    Scott

  • 0 in reply to ScottG
    Guru 54358 points

    ScottG said:
    The clock setup by the Boot module is done very early, before main(),

    If that is true Boot module TivaC/E clocking should not cause any problem.

    Past reported to forum Boot module PLL was not being set true and recall PSYSDIV bit was not being set. Both are corrected by Tivaware calls of SysCtlClkFreqset() in main.c. ROV now shows output PLL=true.

  • 0 in reply to Genatco
    Guru 54358 points

    PLL being enabled and PSYSDIV registers still not fixed in TI-RTOS-2.16.1.14 for TM4C/E Boot clock module with Advanced configuration selected or not.

  • 0 in reply to ScottG
    Guru 54358 points

    ScottG said:
    I think if we can determine exactly where the exception is being generated it will be a big step towards finding where the problem is…

    Oddly ROV with RTOS 2.16.1.14 shows PLL enabled = true. Yet the SYSCTL register PLL/PSYSDIV bit values tell the entire story. Tested the advanced clocking with and without auto clock configuration, produced same results. Perhaps a good thing Tivaware SysCtlClkFreqSet() works concurrently with TM4C/E advanced clocking enabled. 

    The point of this thread is to reveal there are issues with RTOS boot module clocking source that can effect TM4C peripherals clocking such as EMAC0, ADC0, PWM0 etc... 

  • 0 in reply to Genatco
    TI__Guru**** 164375 points

    Hi BP101,

      Sorry, I'm not really clear about what is the underlying problem you are facing. 

    BP101 said:
    Seemingly we can't get the TivaC/E clocking to run the ADC0 2MBPS clocking (32Mhz ) configuration during PISOC, is issue in my mind.

    Is 2MSPS what you are trying to achieve using PIOSC. I don't think this is possible. You can only achieve 1MSPS using PIOSC. 

    The PIOSC can be used directly to provide a conversion rate near 1 Ms/s. To use the PIOSC,
    the CS field in the ADCCC register needs to be set to 0x1 and the ALTCLK field should be
    programmed to 0x0 in the Alternate Clock Configuration (ALTCLKCFG) register.

  • 0 in reply to Charles Tsai
    Guru 54358 points

    The RTOS TM4C/E advanced clocking code is not setting the SYSCTRL_RSCLKCFG register PSYSDIV bits or USEPLL bit when Boot module is configured specifically to do so.

    That is why the ADC is not working, not that PIOSC is being used during module configuration. According to ScottG post above the Boot module TM4C/E advanced clocking starts even before main.c is executed. The WA is to disable useless Boot clock and use Tivaware SysCtlClkFreqSet() in main.c

  • 0 in reply to Genatco
    TI__Mastermind 30830 points

    I did some digging and it appears that the "Enable PLL Output" setting is the culprit. If you disable that setting, I believe you'll have better luck.

    I'm not even sure what the "Enable PLL Output" setting is meant to be used for. The 'Bypass PLL' setting is used to determine if the PLL is used or not. If 'Bypass PLL' is unchecked, it means that the PLL will be used.

    Alan

  • 0 in reply to Alan DeMars
    Guru 54358 points
    The MOSC requires PLL output enable bit set order to generate 480Mhz VCO. ROV does show PLL output enabled when TM4C/E advanced clocking is checked and enable PLL output is also checked.

    So you think the flag is working backwards from what you are saying? PLL output in main clock tree is required for 25Mhz MOSC even with Tivaware calls it is set enabled.
  • 0 in reply to Alan DeMars
    Guru 54358 points
    That PLL output enable was disabling the PLL block but ROV showing PLL was enabled as it should be enabled for 480Mhz. That is so contradicting with datasheet context and other Tivaware clock set function calls.