Team,
The McBSP is setup as slave (CLK and FS coming from an ASIC). Looking at the TX side the master (ASIC) does slightly change the clock period (CLKX running at 7.2Mhz) from time to time. The behavior is described below, it is deterministic and periodic. See as well the enclosed picture.
This behaviour occurs after we transmit the last McBSP word from the memory buffer. The clock runs continuously at 50-50 duty cycle, then SW sets a transmit DMA buffer, resets the McBSP and transmission starts. After all the words from the memory buffer (typically 32 words x 32bit long), we have a runout of 3 clock cycles, then we stop the clock for half a cycle and then the clock continues at 50-50 duty cycle. Later on, SW sets another DMA transmit buffer, resets the McBSP, and transmits the new buffer. Again, after the last word from the DMA buffer has been shifted out, we have a runout of 3 clock cycles, then we stop the clock for half a cycle and re-enable the clock at 50-50 duty cycle.
There are no glitches; the only effect is after the last transmission + the 3 runout cycles, we have an extra half a cycle of clock=0V.
It seems to violate slightly the CLK specs that we give at page 160 (see note 4 about duty cycle) and 167 of the OMAP-L138 datasheet - SPRS586D. Considering the duty cycle of the given clk period it is close to 30/70 (apart from the fact that the period is appr. 30% 50% longer than the other CLK periods). So it can be considered as out of specs.
Still it does not seem that critical and customer does not see issues when doing HW test.
Q: Do you think that the behavior is critical? can they live with it? Are there specific risk associated?
Thanks and best regards,
Anthony
