McBSP2/3 and McSPI3 Clock Issue

Danilo

MCBSP2, MCBSP3, MCBSP4, and all the MCPSI modules can be driven by DPLL4 so it should be possible to drive the module's output clock at the same frequency but the edges will not be aligned due to internal delays.

 Can you explain a little more what you mean by "they start completely differently"?  What is your startup sequence?

  Paul

Hi Paul,

Thanks for your time.

I configured McBSP2/3 and McSPI3 to use the clock driven by DPLL4. They are now running at same clock frequency without no problem.

I actualy noticed that the edges are not aligned. But I expect a fixed interval delay between them.

I mean that every time I run my code, the clock have a diferent delay between them. Causing sometimes even a phase invertion.

I was expecting a fixed delay.

My startup sequence is something like that:

Put all ports in reset;

Program then with desired wave form;

Enable Clock.

------------------------------------ McBSP ---------------------------------------

      // Initialize McBSP1 Registers
      *(BASE + McBSP_SPCR2) = 0x00000000;
      *(BASE + McBSP_SPCR1) = 0x00000000;

      // Set Run Free Mode For TX And RX And Set Generation Of Interrupts
      *(BASE + McBSP_SPCR2) = 0x00000230;
      *(BASE + McBSP_SPCR1) = 0x00000020;

      // Set Receive Word Length To 16 Bits And 1 Bit Data Delay
      *(BASE + McBSP_RCR1) = 0x00000040;
      *(BASE + McBSP_RCR2) = 0x00000001;

      // Set Transmitter Word Length To 16 Bits And 1 Bit Data Delay
      *(BASE + McBSP_XCR1) = 0x00000040;
      *(BASE + McBSP_XCR2) = 0x00000001;

      // Set Frame Sync Mode For TX And RX And Clock Polarity
      *(BASE + McBSP_PCR) = 0x00000B00;
     
      // Set Frame Sync Width And Divide Clock By 2
      *(BASE + McBSP_SRGR1) = 0x00000001;

      // Setup Clock Settings And Frame Period (Time Between Frame Syncs)
      *(BASE + McBSP_SRGR2) = 0x00001040;

      // All Channels Enable But Masked
      *(BASE + McBSP_MCR2) = 0x00000002;
      *(BASE + McBSP_MCR1) = 0x00000001;

      // Enable Channel 0 To Transmit
      *(BASE + McBSP_XCERA) = 0x00000001;

      // Enable Channel 0 To Receive
      *(BASE + McBSP_RCERA) = 0x00000001;

      // Set Threshold To 0
      *(BASE + McBSP_THRSH2) = 0x00000000;

      // Clear All Interrupts
      *(BASE + McBSP_IRQSTATUS) = 0x00007FBF;

      // Enable Receive
      *(BASE + McBSP_SPCR1) |= 0x00000001;

      // Enables Sample Rate Generator
      *(BASE + McBSP_SPCR2) |= 0x00000040;

------------------------------------------ McSPI -----------------------------------------

      // Configure Clock Free Running
      *(BASE + McSPI_SYSCONFIG) = 0x00000308;

      // Set Signals Direction (simo somi csx clk)
      *(BASE + McSPI_SYST) = 0x0000010F;

      // Set Master Mode
      *(BASE + McSPI_MODULCTRL) = 0x00000000;

      // Configures CS0 Line , Set 7 Bits Word Length , Clock Delay And Divider
      *(BASE + McSPI_CONF_CH0) = 0x0001234C;

      // Enable Channels
      *(BASE + McSPI_CTRL_CH0) = 0x00000001;

It's not clear if you are enabling the PER_L4_FCLK first and then configuring the modules or the reverse.

If you are not already doing so, I would try configuring/enabling  the modules first and then enabling the PER_L4_FCLK. This approach should provide the best chance for a predictable startup.

  Paul

Hi Paul,

What did you mean by PER_L4_FCLK? PER_96M_FCLK? CM_96M_FCLK?

I'm probably enabling PER_L4_FCLK first, because I use other peripherals before even configure McBSPs.

But even if i try to enable it after McBSPs are configured, McSPI will continue to be an issue, because its clock are only enabled when there is data to send.

It's "normal" to have diferent delays every time I startup the system?

Thanks again,

Danilo

Danilo

By PER_L4_FCLK I meant the Functional clock for the L4 peripherals, sorry for any confusion.

I think the effect you are seeing is probably due to the clock dividers of each module starting at different times.

Is it just MCBSP -v- MCSPI clock relationship that is unpredictable or also MCBSP -v- MCBSP?

  Paul

Paul,

No problem, I figured it out, but needed to ask just to confirm.

I'm a bit confused, I can't see where a clock divider can disalign the edges. In my concept they are supossed to be just counter. Correct me, if I'm wrong.

I really don't know why the clocks are not edge aligned or as we discuss at least with a fixed edge to edge delay.

I remade some test and: McBSP x McBSP and McSPI x McBSP and McSPI x McSPI are unpredictable.

Any ideas? Tests? Sugestions?

Thanks again,

Danilo

Danilo

MCBSP-v-MCBSP

Each MCBSP module is independent with independent clock gating. The control of the gating and reset bits is from the ICLK domain which is asynchronous to the FCLK domain. Since the SRGs in each MCBSP can not be turned on simultaneously then the dividers can start on different clock edges and therefore the phase relationship between the divided clocks can change.

There are three possibilities to work around this.

1) Use a divide by 1 clock - 96MHz, probably too fast.
2) Use the divider of one MCBSP and connect the CLKX output to the MCBSP_CLKS input. All other MCBSPs would then use this clock as there source (divide by one).
3) Supply an external clock at the frequency required to all MCBSPs via the MCBSP_CLKS pin.

Options 2 & 3 should (but not tested) maintain the phase relationship but the CLKX output of each MCBSP will be skewed. Inverting the CLKX clock or the SRG source clock(s) could be used to correct very bad (~180deg) skew.

 The clocks between modules are not balanced and therefore the skew may get better or worse as voltage and temperature vary. This will be exaggerated more in option 2 between the "master" CLKX clock and the "slave" CLKX clocks

MCBSP-v-MCSPI-v-MCSPI

The MCSPI module uses the 48MHZ (undivided) clock to control transactions. This minimizes the latency from writing data to the DXR register and the data transaction starting on the interface. Even of the divided output SPI clock is at the same frequency as the MCBSP clock the phase relationship will change from word to word (just as you are seeing).

This can be seen by setting both the MCSPI clock and MCBSP clock to 48MHz and sending a multi word spi transaction. If you trigger on the first spi word you'll see that the second word 'jitters' by one clock cycle.

If you were to lower just the spi clock frequency then the jitter still appears as 1 48MHz clock cycle.

Unfortunately there is no way to control this or truly sync clocks between MCSPI modules running frequencies lower than 48MHz.

  Paul