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.
I have some related questions about the SDFM:
I had in the past weird behavior of the SDFM. I'm using the module to monitor current sensors to fast switch off my device if a short circuit happens. For that I use the comparator unit inside with a low over sampling ratio and for normal measurement the SDFM.Data with a higher over sampling ratio.
For the measurement I use separated PCBs with a Sigma Delta Modulator. Due to revisions I have different Sigma Delta Modulators in use (ADS1203, ADS1202, AMC1303E). During first setup I realized, that 10MHz Modulators will not work with TMS230, because it only supports 8...20*t_sysclk in its SDMF. So, I decided to lower the frequency of the TMS to 180MHz so it will also support the 10MHz Modulators.
By playing around with the boards, I noticed that the SDFM Comparator sometimes trips without any reason. This must be due to wrong synchronization of the SDFM.
To have a closer look to the problem, I programmed a FPGA to output a Manchester coded Sigma Delta stream and play with the parameters. To see if the SDFM lose synchronization I setup an interrupt every time it has new data available.
What I figured out is somehow strange. Running the TMS at exact 200Mhz it only supports data streams from 9.2 to 15.4Mhz. Everything beyond that will trigger the trip. But changing the frequency to 190 or even 210Mhz will make the SDFM support even higher frequencies. Changing the QSEL of the pin from async to sync will sometimes improve the behavior, but not always. It depends on the exact frequency of the data stream.
On the picture you see the sigma delta data stream on channel 1 and the toggle output of the TMS every time it has new data available.
I assume every time it takes longer to get a new value (blue lines on the DPX picture) it will get a wrong value.
Because I use a fiber optic cable to transmit the data stream in my application, I also had a look on the difference times of high and low state, because usually the fiber optic cable will delay the rising edge a little.
What I realized, that if the delay of the edge is in the range of 10ns, doesn't matter what frequency the stream is running, it will corrupt the data.
So, do you have a detailed description, how the SDFM is working and what constrains must be met? Why it is limitted to the frequency of 8...20*t_sysclk? Are you just oversampling the signal and what is the algorithm after the oversampling? Because the really short constrains of the technical reference manual are by fare not sufficient.
I'm talking specially about rise times, hold times, even a description of the implementation would be really useful. Because like this, I'm not able to use the TMS at all. And it would make more sense to me to use a FPGA.
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:
Now to the disadvantages with this method:
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:
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?
This thread is handled over email conversation. Will update the thread with resolution.
Regards,
Manoj