TMS320F28379D: SDFM Mode 2 (manchester) weired behavior

Stefan,

Manchester decoding scheme available in F28377D is based on SYSCLK. Manchester decoding works only when manchester bit stream satisfies the min / max limits mentioned in DS. Manchester mode can ONLY be used when GPIO is configured in ASYNC mode. So, you can't use SYNC mode (or) QUAL mode. This makes manchester mode more vulnerable to any EMI (or) ringing noise when compared to other modes. Noise can potentially disturb the decoding scheme and corrupt the filter results causing unexpected trip events. Mode 0 when used with GPIO_QUAL (3-sample mode) offers the best noise immunity. The jitter you see in channel 2 signal seems to suggest that the decoding scheme is indeed getting affected. You can try reducing the ringing noise with proper impedance matching.

OSR (either DOSR (or) COSR) configured in SDFM determines the frequency response of the filter and also determines the data rate and settling time of the filter.

Regards,

Manoj

Hi Manoj,

you answered one questions out of many.

I started with ASYNC settings on GPIO. Changing it to something else was just a try to get rid of the problem. But as I described it didn’t change much. But I will stay with ASYNC settings.

But now back to the fundamental problem:
Today I tried out a lot again. I used the pwm and trip zone to get a rough idea what’s going on:

I set up the pwm that it stayed switched on until a CBC trip event happens. Because you talked about EMI, I wanted to make sure the levels get detected well. For that I used a different gpio and configured it via inputXbar as a trip event. So every time the Manchester stream gets high, the pwm will get low and goes high again, when the stream gets low again. And then I inverted the gpio to check also falling edges. And all tests look good. So the problem I have should not be due to EMI or misdetected levels or edges.

To have a look at the Manchester stream when the error occurs, I configured the trip zone, so every time the output of the SDFM comparator trips, it will trip the pwm.

The result can be seen in the following figure. For testing I ran a Manchester stream with 16.6MHz (60ns) with a high period of 30ns and a low period of 30ns. The Manchester stream has the following bits: 100101101001 and starts from beginning again.

The TMS320 runs with 200MHz, based on a 20MHz clock and PLL settings of IMULT = 20 (*20), PLLSYSCLKDIV = 1; (/2).

It can be seen, that every 235µs the SDFM looses its synchronization and decodes wrong values.

To understand what’s the error, I increased 24.7MHz. And what can be seen, the time of loosing synchronizations stays exact the same. So the problem can not be due to errors in the Manchester coded signal or due to timing issues outside of the TMS.

But changing the PLL settings to slightly different values e.g. IMULT = 39 (*39), PLLSYSCLKDIV = 2; (/4) = 195MHz, will make the errors go away. Even changing it to 205Mhz will make them disappear.

To make 100% sure it is not due to the signal I even added a bus driver to make the Manchester coded signal look nicer, didn’t change the behavior.

I detected this behavior first on a self-made board. To make 100% sure, that it is not due to our board, I switched to the Launch-XL board. The Launch-XL board is based on a 10MHz crystal. So I decided to use the following clock settings: IMULT = 40 (*20), PLLSYSCLKDIV = 1; (/2) = 200MHz.

And here I get errors in sigma delta data decoding as well, but the time between is 138µs, so almost half of it (see attached figure).

To get a even better understanding, I started to cool down the crystal by a ice spray. And by cooling down the crystal I was able to increase the time between the failures. Cooling down the TMS didn’t change much. But also cooling down the FPGA boards crystal changed the time slightly. So there must be a aliasing some where in the TMS which results in wrong behavior of the SDFM.

So could you please tell me, how the SDFM is working.

Stefan,

Which modulator are you using? Does the modulator generates its own clock (or) you providing clock to SD-modulator using PWM?

I set up the pwm that it stayed switched on until a CBC trip event happens. Because you talked about EMI, I wanted to make sure the levels get detected well. For that I used a different gpio and configured it via inputXbar as a trip event. So every time the Manchester stream gets high, the pwm will get low and goes high again, when the stream gets low again. And then I inverted the gpio to check also falling edges. And all tests look good. So the problem I have should not be due to EMI or misdetected levels or edges.

Setting a GPIO as a trip event (through INPUT XBAR) is not a valid experiment (meaning it is not a apples to apples comparison). Manchester bit streams toggle at much higher speed making it more prone to ringing noise.

Your

To have a look at the Manchester stream when the error occurs, I configured the trip zone, so every time the output of the SDFM comparator trips, it will trip the pwm.

Your second experiment just observes 2 - 3 SD-bitstreams before the trip event happens. So, it may be masking the problem. You need to observe upto Order of Sinc filter x OSR SD-clock cycles to get a better picture. Last OSR SD-clock cycles are very important. Typically the % filter output error have cumulative effort before it eventually trips.

I'm however very surprised that your trip events are very periodic and how it is related to SYSCLK frequency. This is an interesting observation. I don't have proper explanation on this behavior. I haven't seen this before. In our lab setup, we were able to get Mode 2 working fine at 10 / 15 / 20 MHz without any problem and we a started seeing problems when noise was injected into the bitstream. Also, the trip events we observed were random in nature and not periodic.

Do you have something in your system which induces switching noise causing ground bouncing at those frequencies?

Also, do you want to know how manchester decoding is working? Filter module working is same across mode. What changes across modes is how the bit streams are read.

Regards,

Manoj

è  Which modulator are you using? Does the modulator generates its own clock (or) you providing clock to SD-modulator using PWM?

My SD-Modulators (ADS1203, ADS1202, AMC1303E) using internal clock as my FPGA does.

è Setting a GPIO as a trip event (through INPUT XBAR) is not a valid experiment (meaning it is not a apples to apples comparison). Manchester bit streams toggle at much higher speed making it more prone to ringing noise.

I understand what you mean. I just wanted to get a idea how accurate the edge detection may work. And because I used the same circuit the edges and rise time were the same. But of course there could be still an EMI issue. But I think it is quite unlikely.

è Your second experiment just observes 2 - 3 SD-bitstreams before the trip event happens. So, it may be masking the problem. You need to observe upto Order of Sinc filter x OSR SD-clock cycles to get a better picture. Last OSR SD-clock cycles are very important. Typically the % filter output error have cumulative effort before it eventually trips.

I checked also the “older” bits, but they all look ok. No changes in duty cycle or different edges or EMI coupling.

è Do you have something in your system which induces switching noise causing ground bouncing at those frequencies?

No, not at all. I also halted the CPU to make sure the code is not causing this issue. And even with halted CPU the error occurs. I also checked all supply voltages, but they look all good without a ripple.

è I'm however very surprised that your trip events are very periodic and how it is related to SYSCLK frequency. This is an interesting observation. I don't have proper explanation on this behavior. I haven't seen this before. In our lab setup, we were able to get Mode 2 working fine at 10 / 15 / 20 MHz without any problem and we a started seeing problems when noise was injected into the bitstream. Also, the trip events we observed were random in nature and not periodic.

I think the problem is a slight difference in clock speeds. My FPGA is running at 400MHz and generates out of it the bit stream. Assuming the TMS is running exactly at 200MHz and the FPGA at 400.01MHz, it would take 100µs until the clock shifted by one cycle (hope I did the calculation right). And if the Manchester decoder is not well implement this shift may led to loos of synchronization. That’s why I want to have a look at the implementation of the Manchester decoder. The filter is not too much of interest, because it seems to work well, but the Manchester decoding seems to make the troubles.

I checked the ground of all PCB and there is no bounce in the difference grounds.

Regards, Stefan

Please find attached word documents which talks about manchester decoding on this device.Manchester Decoding.docx

After another day of investigation, I got a little closer to the problem.

First let me summarize how I see the Manchester decoder works:

• Over 1024 samples it measures the low time between two high levels
• This time it writes into the SDCTLPARMx.MS bit field (11..1 times of T_sys)
• If there are two separated bit groups (00111011100 or 00010001000) it will take this as valid data and sets MAFx to low. If there is only one group (00001111100 or 01110000000) it will set MAFx to high, because there was an error in detection of the clock speed
• Now it resets SDCTLPARMx.MS and start from the beginning
• In the meantime the demodulator gets synced again with the new detected clock speed and reads out the data from the stream.

Now to the disadvantages with this method:

• Running the TMS with a clock speed of 200Mhz, low time detection can be done between 5ns-55ns. 55ns low time means a frequency of 18.1MHz because at -10-01- the low time will be 55ns at 18.1MHz. So every frequency, which is above 18.1MHz will set the MAFx bit. But in this case the SDCTLPARMx.MS will show something like this 00100000000, but with this the demodulator still works, but just outputs an error. I assume this is one reason, why you took out the description of the MAFx and MALx bits from your technical reference manual, right?
• Detecting the frequency of the Manchester code just by looking at the low level is risky. As I descripted before, I use fiber optic cables, which shift the rising edge a little. This can cause in wrong frequency detection. Now that I got a hint about your technic, it make sense that a shift by 10ns will corrupt the data, because this will shift the whole frequency by two cycles.
• If there is in one sync cycle one wrong detected low level, which will close the gap in the SDCTLPARMx.MS register (000111x11100), there will be wrong values for 5µs, just because there was one wrong low level. This is an unstable way of implementing it. This may be easy to implement but unstable.

But those points are not direct relevant to the problem I have.

To get the problem a little closer I wrote a small for(;;) loop, where I just read out the following registers:

• Sdfm1Regs.SDSTATUS.all
• Sdfm1Regs.SDCTLPARM1.bit.MS
• Sdfm1Regs.SDDATA1.bit.DATA32HI

Those register I wrote into an array with 2000 values and read them out by the debugger.

The for loop it took approximately 400ns to run through, so I have a full view of all values for 800µs with a resolution of 400ns.

Sdfm1Regs.SDCTLPARM1.bit.MS: (just bit 15 to 5)

[1807]   unsigned int       0000000010001000b (Binary)   0x0000D7CF@Data
[1808]   unsigned int       0000000010001000b (Binary)   0x0000D7D0@Data         
[1809]   unsigned int       0000000010001000b (Binary)   0x0000D7D1@Data        

[1810]   unsigned int       0000000010001000b (Binary)   0x0000D7D2@Data        

[1811]   unsigned int       0000000010001000b (Binary)   0x0000D7D3@Data        

[1812]   unsigned int       0000000010001000b (Binary)   0x0000D7D4@Data        

[1813]   unsigned int       0000000010001000b (Binary)   0x0000D7D5@Data        

[1814]   unsigned int       0000000010001000b (Binary)   0x0000D7D6@Data        

[1815]   unsigned int       0000000010001000b (Binary)   0x0000D7D7@Data        

[1816]   unsigned int       0000000010001000b (Binary)   0x0000D7D8@Data        

[1817]   unsigned int       0000000010001000b (Binary)   0x0000D7D9@Data        

[1818]   unsigned int       0000000010011100b (Binary)   0x0000D7DA@Data       
[1819]   unsigned int       0000000010011100b (Binary)   0x0000D7DB@Data        

[1820]   unsigned int       0000000010011100b (Binary)   0x0000D7DC@Data        

[1821]   unsigned int       0000000010011100b (Binary)   0x0000D7DD@Data       

[1822]   unsigned int       0000000010011100b (Binary)   0x0000D7DE@Data        

[1823]   unsigned int       0000000010011100b (Binary)   0x0000D7DF@Data        

[1824]   unsigned int       0000000010011100b (Binary)   0x0000D7E0@Data         

[1825]   unsigned int       0000000010011100b (Binary)   0x0000D7E1@Data         

[1826]   unsigned int       0000000010011100b (Binary)   0x0000D7E2@Data         

[1827]   unsigned int       0000000010011100b (Binary)   0x0000D7E3@Data         

[1828]   unsigned int       0000000010011100b (Binary)   0x0000D7E4@Data         

[1829]   unsigned int       0000000010011100b (Binary)   0x0000D7E5@Data         

[1830]   unsigned int       0000000010011100b (Binary)   0x0000D7E6@Data         

[1831]   unsigned int       0000000010011100b (Binary)   0x0000D7E7@Data         

[1832]   unsigned int       0000000010011100b (Binary)   0x0000D7E8@Data         

[1833]   unsigned int       0000000010011100b (Binary)   0x0000D7E9@Data         

[1834]   unsigned int       0000000010011100b (Binary)   0x0000D7EA@Data        

[1835]   unsigned int       0000000010011100b (Binary)   0x0000D7EB@Data        

[1836]   unsigned int       0000000010011100b (Binary)   0x0000D7EC@Data        

[1837]   unsigned int       0000000010011100b (Binary)   0x0000D7ED@Data        

[1838]   unsigned int       0000000010011100b (Binary)   0x0000D7EE@Data         

[1839]   unsigned int       0000000010011100b (Binary)   0x0000D7EF@Data         

[1840]   unsigned int       0000000010011100b (Binary)   0x0000D7F0@Data         

[1841]   unsigned int       0000000010011100b (Binary)   0x0000D7F1@Data         

[1842]   unsigned int       0000000010011100b (Binary)   0x0000D7F2@Data         

[1843]   unsigned int       0000000010011100b (Binary)   0x0000D7F3@Data         

[1844]   unsigned int       0000000010011100b (Binary)   0x0000D7F4@Data         

[1845]   unsigned int       0000000010011100b (Binary)   0x0000D7F5@Data         

[1846]   unsigned int       0000000010011100b (Binary)   0x0000D7F6@Data         

[1847]   unsigned int       0000000010011100b (Binary)   0x0000D7F7@Data         

[1848]   unsigned int       0000000010011100b (Binary)   0x0000D7F8@Data         

[1849]   unsigned int       0000000010011100b (Binary)   0x0000D7F9@Data         

[1850]   unsigned int       0000000010011100b (Binary)   0x0000D7FA@Data        

[1851]   unsigned int       0000000010011100b (Binary)   0x0000D7FB@Data        

[1852]   unsigned int       0000000010011100b (Binary)   0x0000D7FC@Data        

[1853]   unsigned int       0000000010011100b (Binary)   0x0000D7FD@Data        

[1854]   unsigned int       0000000010011100b (Binary)   0x0000D7FE@Data         

[1855]   unsigned int       0000000010011100b (Binary)   0x0000D7FF@Data         

[1856]   unsigned int       0000000010011100b (Binary)   0x0000D800@Data         

[1857]   unsigned int       0000000010011100b (Binary)   0x0000D801@Data         

[1858]   unsigned int       0000000010011100b (Binary)   0x0000D802@Data         

[1859]   unsigned int       0000000010011100b (Binary)   0x0000D803@Data         

[1860]   unsigned int       0000000010011100b (Binary)   0x0000D804@Data         

[1861]   unsigned int       0000000010011100b (Binary)   0x0000D805@Data         

[1862]   unsigned int       0000000010011100b (Binary)   0x0000D806@Data         

[1863]   unsigned int       0000000010011100b (Binary)   0x0000D807@Data         

[1864]   unsigned int       0000000010011100b (Binary)   0x0000D808@Data         

[1865]   unsigned int       0000000010011100b (Binary)   0x0000D809@Data         

[1866]   unsigned int       0000000010001000b (Binary)   0x0000D80A@Data        

[1867]   unsigned int       0000000010001000b (Binary)   0x0000D80B@Data        

[1868]   unsigned int       0000000010001000b (Binary)   0x0000D80C@Data        

[1869]   unsigned int       0000000010001000b (Binary)   0x0000D80D@Data        

[1870]   unsigned int       0000000010001000b (Binary)   0x0000D80E@Data         

[1871]   unsigned int       0000000010001000b (Binary)   0x0000D80F@Data         

[1872]   unsigned int       0000000010001000b (Binary)   0x0000D810@Data         

[1873]   unsigned int       0000000010001000b (Binary)   0x0000D811@Data         

[1874]   unsigned int       0000000010001000b (Binary)   0x0000D812@Data         

[1875]   unsigned int       0000000010001000b (Binary)   0x0000D813@Data         

[1876]   unsigned int       0000000010001000b (Binary)   0x0000D814@Data         

[1877]   unsigned int       0000000010001000b (Binary)   0x0000D815@Data         

[1878]   unsigned int       0000000010001000b (Binary)   0x0000D816@Data         

[1879]   unsigned int       0000000010001000b (Binary)   0x0000D817@Data         

[1880]   unsigned int       0000000010001000b (Binary)   0x0000D818@Data         

[1881]   unsigned int       0000000010001000b (Binary)   0x0000D819@Data         

[1882]   unsigned int       0000000010001000b (Binary)   0x0000D81A@Data        

[1883]   unsigned int       0000000010001000b (Binary)   0x0000D81B@Data        

[1884]   unsigned int       0000000010001000b (Binary)   0x0000D81C@Data        

[1885]   unsigned int       0000000010001000b (Binary)   0x0000D81D@Data        

[1886]   unsigned int       0000000010001000b (Binary)   0x0000D81E@Data         

[1887]   unsigned int       0000000010001000b (Binary)   0x0000D81F@Data         

Sdfm1Regs.SDDATA1.bit.DATA32HI:

[1807]   int          -5            0x0000C7CF@Data        

[1808]   int          -5            0x0000C7D0@Data        

[1809]   int          -5            0x0000C7D1@Data        

[1810]   int          -5            0x0000C7D2@Data        

[1811]   int          5              0x0000C7D3@Data        

[1812]   int          5              0x0000C7D4@Data        

[1813]   int          5              0x0000C7D5@Data        

[1814]   int          -5            0x0000C7D6@Data        

[1815]   int          -5            0x0000C7D7@Data        

[1816]   int          -5            0x0000C7D8@Data        

[1817]   int          5              0x0000C7D9@Data        

[1818]   int          5              0x0000C7DA@Data       

[1819]   int          5              0x0000C7DB@Data        

[1820]   int          -5            0x0000C7DC@Data        

[1821]   int          -5            0x0000C7DD@Data       

[1822]   int          -5            0x0000C7DE@Data        

[1823]   int          5              0x0000C7DF@Data        

[1824]   int          5              0x0000C7E0@Data         

[1825]   int          5              0x0000C7E1@Data         

[1826]   int          5              0x0000C7E2@Data         

[1827]   int          -5            0x0000C7E3@Data         

[1828]   int          -5            0x0000C7E4@Data         

[1829]   int          -5            0x0000C7E5@Data         

[1830]   int          5              0x0000C7E6@Data         

[1831]   int          5              0x0000C7E7@Data         

[1832]   int          5              0x0000C7E8@Data         

[1833]   int          -5            0x0000C7E9@Data         

[1834]   int          -5            0x0000C7EA@Data        

[1835]   int          -5            0x0000C7EB@Data        

[1836]   int          127         0x0000C7EC@Data        

[1837]   int          127         0x0000C7ED@Data        

[1838]   int          127         0x0000C7EE@Data         

[1839]   int          127         0x0000C7EF@Data         

[1840]   int          327         0x0000C7F0@Data         

[1841]   int          327         0x0000C7F1@Data         

[1842]   int          327         0x0000C7F2@Data         

[1843]   int          327         0x0000C7F3@Data         

[1844]   int          579         0x0000C7F4@Data         

[1845]   int          579         0x0000C7F5@Data         

[1846]   int          579         0x0000C7F6@Data         

[1847]   int          1169       0x0000C7F7@Data         

[1848]   int          1169       0x0000C7F8@Data         

[1849]   int          1169       0x0000C7F9@Data         

[1850]   int          1169       0x0000C7FA@Data        

[1851]   int          -2271     0x0000C7FB@Data        

[1852]   int          -2271     0x0000C7FC@Data        

[1853]   int          -2271     0x0000C7FD@Data        

[1854]   int          -2271     0x0000C7FE@Data         

[1855]   int          -3267     0x0000C7FF@Data         

[1856]   int          -3267     0x0000C800@Data         

[1857]   int          -3267     0x0000C801@Data         

[1858]   int          -3151     0x0000C802@Data         

[1859]   int          -3151     0x0000C803@Data         

[1860]   int          -3151     0x0000C804@Data         

[1861]   int          -3151     0x0000C805@Data         

[1862]   int          -43          0x0000C806@Data         

[1863]   int          -43          0x0000C807@Data         

[1864]   int          -43          0x0000C808@Data         

[1865]   int          -3            0x0000C809@Data         

[1866]   int          5              0x0000C80A@Data        

[1867]   int          -5            0x0000C80B@Data        

[1868]   int          -5            0x0000C80C@Data        

[1869]   int          -5            0x0000C80D@Data        

[1870]   int          5              0x0000C80E@Data         

[1871]   int          5              0x0000C80F@Data         

[1872]   int          5              0x0000C810@Data         

[1873]   int          -5            0x0000C811@Data         

[1874]   int          -5            0x0000C812@Data         

[1875]   int          -5            0x0000C813@Data         

[1876]   int          5              0x0000C814@Data         

[1877]   int          5              0x0000C815@Data         

[1878]   int          5              0x0000C816@Data         

[1879]   int          -5            0x0000C817@Data         

[1880]   int          -5            0x0000C818@Data         

[1881]   int          -5            0x0000C819@Data         

[1882]   int          5              0x0000C81A@Data        

[1883]   int          5              0x0000C81B@Data        

[1884]   int          5              0x0000C81C@Data        

[1885]   int          5              0x0000C81D@Data        

[1886]   int          -5            0x0000C81E@Data         

[1887]   int          -5            0x0000C81F@Data         

 

And during this time the Sdfm1Regs.SDCTLPARM1.bit.MS just stays at zero.

With the time I calculated (2.5MHz for loop, 200MHz Sys Clock, 1024 ticks for syncing) the Manchester demodulator should resync every 12 values in my array. And the values should get updated every 3 to 4 cycle (25MHz Manchester stream, Over Sampling rate 32). On the values you see almost every 4 cycle a new value. My assumption is now, that because the Manchester decoder just gets resynced every 5.12µs it can happen, that the clock of the of the Manchester stream just changes a little during this time, so that the decoder interprets the values wrong. And if you have a look at value 1865 in the array, you see, this is the point it gets true values again. And this is exactly the moment, when a resync happens (see Sdfm1Regs.SDSTATUS[1865]). And due to the small over sampling ration of 4 at 25MHz Manchester stream and the technic how you sample the bits after synchronization I don’t see a work around for that.

Can you confirm that I got the function of the decoder right? Can you give further information about the decoder? How does it sync, how often does it sync, is it possible to reduce the ticks needed for syncing (1024), do you have a program in hardware description language, that I can simulate the decoder? Have you ever tested your decoder with different frequencies? You should be able to reproduce the error just by taking a Sigma Delta Modulator and the TMS. If it does not happens from beginning, try out some ice spray to cool down one oscillator to put them out of tune.

Can we setup a call to talk about the further steps? You should have my contact data from Mr. Schmitt. 

Stefan,

I'm not able to understand what you are trying to get out of this exercise. As I have told before, manchester mode is not best suited in noisy (or) even jittery situations. In those cases you have to switch to mode0 which provides best noise immunity.

Regards,

Manoj

This issue is not due to noisy enviroment or jitter. It is just due to a slight difference in clock speed. And if this is not supported by the SDFM can't be used for any application. Because Mancherster code is just used if a clock line should be saved. And therefore two sperated clocks are needed. 

So can you please invite me to a webex to discuss the issue?

Stefan,

Please send me your email address.

Regards,

Manoj

I will contact you via Matthias Schmitt. 

This thread is handled over email conversation. Will update the thread with resolution.

Regards,

Manoj

Final resolution:-

Above reported customer issue is genuine and forced us to update Mode 2 datasheet table and added a new errata item as shown below