Oddness setting up MOSC on Tiva 129X with external 25MHz osc.

I'm triggering a reset via the NVIC.      The full cycle is:

1 Bootloader uses, but doesn't initialize  PIOSC ( It switches to  PLL for network updates, but I'm not doing that)

2 Main App explicitly selects PIOSC (SysCtlClockFreqSet(SYSCTL_OSC_INT, SYSFREQ_PIOSC))  and generates startup messages via UART - Its possible that the PLL is running, so I choose a known state.

3 Main App starts PLL and starts up the network stack.

4 Regression script requests a reset via a UART command, and the resultant system call triggers reset via the NVIC.   Return to step one.

I typically get a fail within a thousand cycles.  I added code to re-try a failed PLL lock, but I've never seen it trigger.

On thing I can't figure out from the data sheet or the libraries is what MOSC config I should use with my 25MHz single-ended input clock.

This little register write is common in all of the ethernet startup examples:

HWREG(SYSCTL_MOSCCTL) = SYSCTL_MOSC_HIGHFREQ;

But I don't know if it's specific to crystal operation or not.    sysctl.c suggests that it is for use with crystals.

I captured one last night.   The system went into hardfault someplace in between the bootloader and the main app.    

The addresses don't make sense.   I'm showing code addresses in the boot loader, but a stack pointer that applies to the main application.

Registers - after the boot loader executes, but prior to PLL startup - 

PLL Regs:

CPU0 > md 0x400fe160 0x10

400fe160:  00800014 00000000  00000001 00000000   ................

Memtim0:

CPU0 > md 0x400fe0c0 0x10

400fe0c0:  00300030 00000000  00000000 00000000   0.0.............

RSCLKCONFIG:

CPU0 > md 0x400fe0b0 0x10

400fe0b0:  30000013 00000000  00000000 00000000   ...0............

The guilty code was SysCtlClockFreqSet().    I called it this way:

return(SysCtlClockFreqSet(SYSCTL_OSC_INT, 16000000));

I've since purged that code as part of simplifying all of this.     I don't touch the clocks at all until I switch from PIOSC to PLL.    I'm still seeing the hangs after a few hundred to few thousand cycles.  They happen somewhere during boot loader operation, prior to the initial UART banner.   The part is in hard fault and the register dumps don't really make sense.  

Here's the register results from the updates in sysctl.c code, after I call SysCtlClockFreqSet();

PLLREGS=800060,4,1 MEMTIM0=1950195 RSCLKCONFIG=33300003

0451.sysctl.cHere's my local copy of sysctl.c

Got it.   I'm running tests now.   Updated file attached.

4010.sysctl.c

No luck. I've gone from failures (hangs at PLL lock) after 1k-5k worth of cycles to fails after 10k cycles.

sysctl.c is leaving RSCLKCFG in the wrong state after PLL config: RSCLKCONFIG=33300003

I'm working around this with HWREG(SYSCTL_RSCLKCFG) &= ~SYSCTL_RSCLKCFG_OSCSRC_M; Right after SysCtlClockFreqSet().

I think I'm there.   I have two 129x-based based designs that have made it past 20k cycles with the latest sysctl.c from Amit.   Thats a record.  

I'm running with the minor change listed earlier in the thread so that MOSC is never enabled, not even temporarily.

I ran two different designs over the holiday weekend, and they made it to 50k and 100k successful cycles respectively.    I've got another design running now that will run for a few days.

I am making arrangements to run the updated code on boards in our application environment - things are a little different there.   When it works there I'll consider this closed.

Thanks for all the help.

Aha.   The the PLL changes that fix this startup issue involve running the PLL at 240MHz instead of 480.

The existing USB code uses a 8:1 divider to get the required 60MHz USB Phy clock.    I changed the divisor on USBCC and its working again.     The raw PLL also goes to the ADC and the Ethernet MAC.     I'll have to adjust the ADC divisor as well.