• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 180 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.

MSPM0G3107: Taking a data-stream as input for PLL for data sync?

Keito Katafuchi
Intellectual 295 points
Part Number: MSPM0G3107

Tool/software:

I'm interested in the MSPM0+ for a project.

The concept is to use the MCU for a serial-based communication scheme.

Tx: DMA to transfer a constant data stream through a GPIO with ISR triggers for the MCU to update the next data packet

Rx: DMA to transfer a constant data stream from GPIO to memory

The point is, I want to synchronize to the Rx data stream. So do something similar to clock recovery.

It looks like the MSPM0+ can input an external clock (4~48MHz) for the internal PLL.

I was wondering if there was a way to use the input data stream, with the PLL to synchronize to the received signal.

The Rx signal would look something like this (bunch of 1010, good for clock recovery):

10101010101[data]10101010101010101010101[data]10101010101010101

I also have flexibility to avoid receiving data packets until the MCU is locked to the 10101010 stream.

Can the PLL circuitry be used for something like this, that is a mostly stable HFCLK input to the PLL, with occasional times where there are up to 4bits of HIGH or LOW?

  • 0
    TI__Mastermind 18377 points

    Hi, 

    Keito Katafuchi said:
    Can the PLL circuitry be used for something like this, that is a mostly stable HFCLK input to the PLL, with occasional times where there are up to 4bits of HIGH or LOW?

    I am not the PLL expert.

    But from my point of view, a unstable clock input to PLL will cause PLL jitter and offset, or unlock.

    Also a 4 bits of High or Low, with no signal edge has possibility to cause PLL unstable or lose lock status.

    These answer need further test.

    Since a external clock must passthrough the SYSPLL to source the CPU, so need to test how will happen if SYSPLL input keep 4 bit high.

    Taking a data-stream as input for PLL for data sync?

    As title said, how this data sync works? Can you explain it?

    Why not choose to use SPI that serial interface with clock.

    Want to use this data stream to halt CPU or only need to receiving data synchronously.

    Regards,

    Helic

  • 0 in reply to Helic Chi
    Intellectual 295 points

    Data can be encoded using "line coding" techniques.

    https://en.wikipedia.org/wiki/Line_code

    This way, unlike SPI, you can send both CLOCK and DATA on one wire (one signal)

    A receiver needs to perform clock recovery, which synchronizes itself (in phase) with the signal edges.

    This way, the receiver knows when to sample the input signal.

    Also, by using such a clock recovery scheme, we can avoid oversampling like with UART, allowing higher bit rates.

    The clock recovery uses a PLL, with the signal (combined CLOCK and DATA on one wire) as the input.

    The output of the PLL is a clock which is in-phase with the DATA.

    The MCU then uses the PLL-generated CLOCK to decide when to sample the incomming data stream.

    I was just wondering if the MSPM0+ input PLL could still maintain phase lock and SYSPLL output clock, even if the input clock/data signal might have periods of up to 350[ns] where there is no edge?

  • +1 in reply to Keito Katafuchi
    TI__Mastermind 18377 points

    Hi, 

    Thanks for your explanation.

    Keito Katafuchi said:
    I was just wondering if the MSPM0+ input PLL could still maintain phase lock and SYSPLL output clock, even if the input clock/data signal might have periods of up to 350[ns] where there is no edge?

    MSPM0's PLL is not designed for this kink of application.

    From my point of view, PLL will lose lock status in data filed, because a up to 350ns no edge clock signal will cause at least PLL unstable, or dead in worst case.

    Keito Katafuchi said:
    Also, by using such a clock recovery scheme, we can avoid oversampling like with UART, allowing higher bit rates.

    MSPM0's UART has hardware oversampling function, which will not take CPU time.

    Regards,

    Helic