TMS570LS3137: boot with LPO

Hi Varban,

I think in software we can't do this, 

I remember that in one of the old threads they did short OSCIN pin with the GND and did the Power on Reset. Once we did this OSCFAIL will get trigger, and the code will get execute with LPO.

--
Thanks & regards,
Jagadish.

Hi Jagadish,

On the Launchpad kit, I do the following:
1) Start the MCU with the external oscillator - the program is running fine

2) I cause an oscillator fault by shorting OSCIN to GND (via the jumper) - the program continues to be running fine

3) I keep the short between OSCIN and GND with the jumper, then:

• Try RST - the program does not start
• Try PORRST - the program does not start
• Power cycle from the USB cable - the program does not start

4) I remove the short, without doing RST/PORRST, observe that the oscillator starts working, then short OSCIN to GND again, and repeat point 3 - the program still does not launch.

IMHO it seems like that if I keep the oscillator fault in this scenario (OSCIN to GND), the MCU somehow remains in reset state forever.

The only way to get it out of it is by starting with the external oscillator.

Am I missing or misunderstanding something?

Thanks,

Varban

Hi Varban,

How are you verifying the program behavior? Are you testing in debug mode?

Varban Metodiev said:

the program does not start

What do you mean by does not start? How you are able to know it is not starting?

--
Thanks & regards,
Jagadish.

Hi Jagadish,

Hi Varban,

First can you please try to test with without RTOS project.

Keep one simple LED blink in while(1), nothing else.

Because UART and other peripherals will not work after oscillator fail because,

As you can see UART is driving by VCLK1 right, and its baud rate is driven by VCLK1

And this VCLK1 again getting from HCLK or GCLK

So, if HCLK and GCLK are driven from PLL1 then they are around 180Mhz in above case, right?

And what if oscillator fail occurs and GCLK is driven by HF LPO which is 10Mhz:

See our clock rates fall down to 10Mhz GCLK and 5Mhz VCLK1

So, UART input clock is also fall down from 90Mhz to 5Mhz, that means 18 times less frequency. So, the corresponding baudrate will also get down by 18 times, that means if you configure some 9600 baudrate it will become 533 baud rates.

Similarly, if you are blinking LED with RTI interrupts that will also affect by this clock change.

So, my suggestion is that just remove the RTOS and just blink one LED in while(1) loop without interrupts and with just for loop delay, now create OSC fail then you could see that LED blinking rate will get change. For example, in this case it should slow down by 18 times compare with before oscillator working.

--
Thanks & regards,
Jagadish.

Hi Jagadish,

Regarding the frequencies: I utterly understand you and agree with the above mentioned, but my scenario is different. I have equalized both the ext. oscillator PLL and the LPO to 10MHz (I am feeding the GCM with 10MHz in both cases) - that way I am capable of preserving the peripherals clock (like the UART baud rate) and achieve transparent failover from the external oscillator to the LPO (and even in debug mode I still get the printf() messages on the CCS console without any interruptions or issues as well).

Regarding the RTOS: I have also tested without RTOS, bare metal only, using RTI to blink the LEDs (following the tutorial from www.ti.com/.../3871660449001) - I observe absolutely the same behaviour. The frequencies are the default ones:

• 160MHz after the PLL from the ext. oscillator
• 10MHz from the LPO

Thanks, 

Varban

Hi Jagadish,

jagadish gundavarapu said:

In that case it should not change the behavior, i think it should work for OSCFAIL as well.

Indeed, it works perfectly. I have configured the ESM interrupt and the nERROR pin reaction. Upon causing an osc. fault, I get the interrupt and toggle the nERROR pin, and the program continues to works transparently without any disruptions on the peripherals.   

However, I still cannot get the MCU started only with the LPO. Today I also tested with removing the crystal on the Launchpad kit - in order to simulate a real oscillator fault, without the need to short OSCIN to GND (which may never happen in reality if the crystal/oscillator fails, and I suspected that this could be preventing the MCU from starting properly). Unfortunately, nothing changed, the issue is still there.

jagadish gundavarapu said:

I never tested this at my end before, so i want to test it and update you my results.

Great, thank you in advance!

Best,

Varban

Hi Jagadish,

Sure, let's continue on the other thread.