AMC1303E2520: Random false measurements

Hi Marsouin,

I'm sorry to hear you are having trouble with the Manchester operation of the AMC1303E2520 and the SDFM of the TMS320F28379S. Let me take some time to chat with the C2000 team and see if we can come up with a solution for you. In the meantime, can you provide any screen captures of the Manchester bit stream as it comes into the SDFM module (i.e. - at the TMS320F28379S side of the track)?

Marc,

Questions based on your query:-

1. What GPIO input qualification are you using on SDFM pins?
2. Are you using SDSYNC option? If you are using, did see the problem even after disabling SDSYNC option
3. Is there random noise coupling on SD-modulated signal?
4. I would also try to reduce the input voltage well below 250mv to see whether you see the same behavior as mentioned in

Regards,

Manoj

Hello Tom, Manoj,

Unfortunately, I already unsoldered yesterday all the non-working AMC1303 and I am waiting for fresh ones. They should arrive at the beginning of next week. Not the best idea I realize now, sorry. Therefore, I cannot measure anything for the moment. I will keep you informed as soon as I have news.

Manoj,

1. I use asynchronous input
2. I don’t use SDSYNC
3. I don’t think so. I did not see anything while measuring the signal. I will check again when the new AMC1303 are in place.
4. It doesn’t change anything, on two of them even 0mV gives rubbish. I added two measurements, one with 0V (short-circuit on the voltage divider) and 400V (equals 200mV on the input) to illustrate. However, I also noticed that one of the working AMC1303 goes crazy if the input exceeds +/- 250mV, even if it is bellow +/-320mV. It doesn’t matter though, there is a good margin in normal working condition.

Thank you for your help, best regards

Marc-André

Question for TI Apps engineers: Both pairs of threads mentioned above were marked as resolved, but ended up with the customers using the non-manchester encoded versions of the AMC1303 or AMC1306 and stating that they believed the SDFM module in the 2837x DSP was malfunctioning. The TI employees asked multiple questions and basically concurred that the engineers had done a good job eliminating other possible causes, but there was no resolution that fixed the manchester encoding.

Is this a systemic problem? I'm working on a design now with AMC1306E05 and TMS320F28377D, and these three threads have me concerned that I'll end up having to use the AMC1306M05 version instead. However, I can't use the un-encoded variant, because I didn't route the clock signals to the SDFM inputs on the DSP, because I expected that the Manchester version would work properly.

Hi Andrew,

Sorry for the delay here. I am not aware of any systemic issues with the SDFM of the TMS320F28377D using Manchester encoded devices. The issues I have seen usually stem from the quality of the clock and/or data received at the Cx and/or Dx inputs to the SFDM. In the case of a Manchester encoded modulator, it would be just the data line - excessive ringing can cause data integrity issues, which is the main reason I asked Marsouin (Marc-Andre) if he could provide screen shots for us. Lets see what he comes back with and go from there.

Hi Tom,

Thanks for the reply. Is the non-coded version more robust to signal quality then? Because the two referenced threads (MarkoAnte and Fearghal Kineavy) both had success once they switched to non-coded, even with a soldered air-wire in at least one case.

Thanks,

Andrew

Hello,

So, the new AMC1303E2520 finally arrived yesterday afternoon. I soldered them and voilà, no more problem, they work perfectly. Therefore, I cannot provide you a measurement of a faulty chip. I feel bad that I did not anticipate that.

I noticed something though. On the new board, there were four chips marked with 79TG4 CKVP lot. Three of them did not work. The remaining two are from 74TG4 AVNG lot and are OK. The new chips Mouser just send me are also AVNG and as I mentioned above, they work well. On the first board, all the AMC1303E currently in place are AVNG. I search into my electronic waste bin, and all the unsoldered AMC1303 I found are CKVP.

Before designing these PCB, I made a small proto board plugged onto a LAUNCHXL-F28377S to test the AMC1303E2520 in the way I needed them. All four chips on this proto are AVNG and they work well. Otherwise, I would not have use them on the main system.

Conclusion, on sixteen working chips, one is CKVP (and I will recheck it twice), fourteen are AVNG and one is a non-Manchester version (that I will maybe “depatch” and re-replace by an AVNG). All other previously mounted CKVP were glitchy. Are you sure that there is no problem with this CKVP lot?

Thank you, best regards

Marc-André

Hi Andrew,

There shouldn't be any difference from the modulator (the AMC1303 or AMC1306) standpoint. 

Hi Marc-Andre!

Thank you for the update!  Let me look through our QC database and see if there have been any concerns about the 79TG4 CKVP device lot.

Tom,

I suppose I meant robustness of the decoder in the DSP? Is the clock + data more robust to noise or signal quality than the manchester encoded version which has to extract the data and recover the clock?

Thanks,

Andrew

Hi Andrew,

Not that I am aware of.  The SDFM decoder needs to have a clock running at least 8x the speed of the bit-stream to properly decode the data and since its generated internally on the DSP, I would like to believe it's going to be cleaner than a clock coming across the PCB from the modulator.

Hello Tom,

Tom Hendrick said:

Let me look through our QC database and see if there have been any concerns about the 79TG4 CKVP device lot.

Thank you very much. I will be on vacation next week, but I am looking forward to hearing from you when I will be back to work.

Best regards

Marc-André

Hi Marc-Andre,

I hope you enjoy your holiday!  Our QC engineers have checked, and there have been no quality issues reported with either lot trace codes you provided.

Hi Marc-Andre,

I am from the C2000 team. Can you try the following experiments on your system when using Manchester mode.

The signal of the AMC1303 to the TMS320 device goes through a GPIO mux before going to the SD filters in the chip.

In the GPIO Mux you have the ability to:

1. invert the input signal

2. turn on/off synchronizer circuit (synchronized at 200MHz)

3. Add some digital filtering (3 samples, 6 samples) after synchronization

Not sure how your GPIO Mux inputs are configured, but if you take an input that is misbehaving and play around with the above mode settings and seeing if you obtain a more stable operation.

Cheers,

Alexander Tessarolo

Hi Tom,

Tom Hendrick said:

Our QC engineers have checked, and there have been no quality issues reported with either lot trace codes you provided.

Thank you for the feedback. I guess I had no luck, then.

Hello Alexander,

Thank you for your message. The configuration on the SDFM pins is as follows:

• Inverted input (see here : http://e2e.ti.com/support/data-converters/f/73/p/656400/2411159#2411159 )
• No pull-up
• Asynchronous input, therefore no filtering

That being said, I will not touch anything now that my system seems so work.

Best regards

Marc-André