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.

Recovering clock stability between random number generation (SLA0338)

Other Parts Discussed in Thread: MSP430F5515

Hi,

I want to print the random numbers I'm generating by way of app note SLA0338 (ported to the MSP430F5515) to a terminal via the UART. Unfortunately, when I come back from the function call to get the random number, there is a DCO Fault that I can't get to clear. I'm running my UART from ACLK, which is sourced by a 32khz crystal. Also the subroutine messes with the ACLK prescalar arbitrarily. What procedure should I use to get the clock system stable enough to output to reliably output to the UART between iterations of this chaotic clock system created by the appnote logic. It seems like stuff I've tried so far makes the processor lock up irrecoverably (but this could be flaky debugger behavior)... Any advice / guidance would be much appreciated.

Regards,

Vic

  • The original code in SLAA338 had the BCS+ found in F2xx chips in mind. The F5515 does not have BCS+ and has UCS instead.

    In order to be able to generate random numbers, you need to modify the code to turn off the FLL+, use VLO clock to source ACLK, manually change the DCO clock, various dividers, etc. While doing that do not have a predictable clock. But after you are finished with generating random numbers, you can re-enable the FLL+ etc. to generate a stable and clock. After that, you can use the UART.

  • Yes, I realize that the original code had the BCS+ and that the F5515 has UCS instead. I ported the code and you can look at it here on PasteBin. Seems to work pretty well based on fips_test.c results as viewed in the debugger. To configure the UCS at startup I run this function. I'm having a heck of a time getting printf to output to the UART, and have been trying to get something far more primitive to work without much luck. It sort of works but there is trash output to the terminal. What exactly do I have to do after calling the RNG function to restore stability to the clock system so that I can output the random value to the UART? Have I set the UART up correctly? Should I disable the UART before calling the RNG function and re-enable it afterwards (how do I do that?). Is there something fundamentally wrong with my_putchar function? I'd rather use printf, but can't figure out how to connect it to my_putchar... many thanks for any suggestions people have.

    Regards,

    Vic

     

  • After a BOR, the USC will automatically enable the FLL using the REFO as reference to generate a stable clock SMCLK at ~1.05MHz. You can also change the FLL settings and the source of its reference to generate other frequencies.

    The Random Number generator program needs to disable the FLL and mess up with lots of other settings in the USC. Thus after you got your random number, you need to put USC back to FLL mode and set other USC registers to generate the desired stable clock for the UART baudrate generator. That is all there is to it.

  • However, all the example code has these loops that wait for the DCO to stabilize, and when I come out of the RNG code, there is a DCO fault that I can't get to clear, so the stabilization loop is effectively infinite... Can you suggest a function that sets the USC back to FLL mode and sets the other USC registers to provide ACLK from the 32kHz crystal XT1? I feel like there should be a universal_clock_system.h library file provided by TI (among many others) that simplifies the manipulation of the UCS...

  • The DCO fault does not indicate that the DCO failed. It cannot - or rather if it really fails, it's time to replace the device :)

    A DCO fault indicates that the DCO tap is at the lowest or highest setting. This means that the FLL has failed to adjust the DCO to the desired frequency and has reached the upper or lower limits of the DCO capabilities.
    To clear the DCO fault, you just need to set the DCO to a different tap than 0 or maximum. Or enable the FLL again and wait. If you (or the FLL) does nothing, it will never clear.

    I'd suggest saving the DCO register contents before entering the RNG function and restorign them afterwards. This will not only clear the DCO fault instantly, it will also reduce the settling time for the FLL, so the desired frequency is restored and stabilized as fast as possible.

**Attention** This is a public forum