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.

Linux/MSP432E401Y: PPS output binary/digital mode questions

Part Number: MSP432E401Y


Tool/software: Linux

I am able to get a 1Hz PPS output from the PTP/1588 hardware. I am using digital-rollover mode and a 50ns time step.

However, when I try to get a 16.384 kHz output, I actually get 15.26 kHz. This appears to be a bug in the emac driver or the hardware, because it is suspiciously equal to: (1/(2*32.768e-6)) = 15.259 kHz. The documentation in emac.c occasionally gets "digital" and "binary" rollover modes mixed up, so I was wondering if this is a similar bug. It says the following:

//*****************************************************************************
//
//! Configures the Ethernet MAC PPS output in simple mode.
//!
//! \param ui32Base is the base address of the controller.
//! \param ui32FreqConfig determines the frequency of the output generated on
//! the PPS pin.
//!
//! This function configures the Ethernet MAC PPS (Pulse Per Second) engine to
//! operate in its simple mode which allows the generation of a few, fixed
//! frequencies and pulse widths on the PPS pin.  If more complex pulse
//! train generation is required, the MAC also provides a command-based
//! PPS control mode that can be selected by calling
//! EMACTimestampPPSCommandModeSet().
//!
//! The \e ui32FreqConfig parameter may take one of the following values:
//!
//! - \b EMAC_PPS_SINGLE_PULSE generates a single high pulse on the PPS
//! output once per second.  The pulse width is the same as the system clock
//! period.
//! - \b EMAC_PPS_1HZ generates a 1Hz signal on the PPS output.  This option
//! is not available if the system time subsecond counter is currently
//! configured to operate in binary rollover mode.
//! - \b EMAC_PPS_2HZ, \b EMAC_PPS_4HZ, \b EMAC_PPS_8HZ,
//!   \b EMAC_PPS_16HZ, \b EMAC_PPS_32HZ, \b EMAC_PPS_64HZ,
//!   \b EMAC_PPS_128HZ, \b EMAC_PPS_256HZ, \b EMAC_PPS_512HZ,
//!   \b EMAC_PPS_1024HZ, \b EMAC_PPS_2048HZ, \b EMAC_PPS_4096HZ,
//!   \b EMAC_PPS_8192HZ, \b EMAC_PPS_16384HZ generate the requested
//! frequency on the PPS output in both binary and digital rollover modes.
//! - \b EMAC_PPS_32768HZ generates a 32KHz signal on the PPS output.  This
//! option is not available if the system time subsecond counter is currently
//! configured to operate in digital rollover mode.
//!
//! Except when \b EMAC_PPS_SINGLE_PULSE is specified, the signal generated
//! on PPS has a duty cycle of 50% when binary rollover mode is used for the
//! system time subsecond count.  In digital mode, the output frequency
//! averages the value requested and is resynchronized each second.  For
//! example, if \b EMAC_PPS_4HZ is selected in digital rollover mode, the
//! output generates three clocks with 50 percent duty cycle and 268 ms
//! period followed by a fourth clock of 195 ms period, 134 ms low and 61 ms high.
//!
//! \return None.
//
//*****************************************************************************
void
EMACTimestampPPSSimpleModeSet(uint32_t ui32Base, uint32_t ui32FreqConfig) {...}
  • I also see very high variation. When I hook this up to a frequency counter (Agilent 53230A), I see:

    Mean= 15.259152 kHz, jumping to 15.262 kHz every few seconds, with Allan Deviation = 660e-3 Hz
    As a result of this jumping, the frequency counter reports high variation: that's almost 1 Hz which is huge! I think that PPS "simple" mode may have some implementation bugs and does not work as intended.

    By comparison, a stable clock source from my NIC has the following output when configured to output 16.384 kHz:
    Mean = 16.384001 kHz, Allan Deviation = 1.04e-6 Hz
  • Hello Paul,

    Thanks for looking into this and reporting the issue you are facing.

    I will have to try the scenario that you described to understand the issue. I will get back to you by the end of this week.

    Thanks,
    Sai
  • Thanks. I actually don't know why frequencies like 16384 Hz would be supported, since they don't divide evenly into the standard time steps of 10ns or 25ns. I'm going to try to work around it by generating the PPS output using the more complicated "command" mode.
  • I am able to work around it by using the "command" mode, as opposed to the "simple" mode, and now I get good results from the microcontroller: 8.7 uHz allan deviation @ 10 kHz output. Importantly, you can only output frequencies whose period is an integer multiple of the system time. So in my case I have the PTP system time as 50ns, so I am using a period of 2000 = (1/10000) / (50e-9). This seems like the "simple mode" has silicon bugs because I don't see any issue with the register writes in the EMAC driver (emac.c).

**Attention** This is a public forum