AM263P4: AM263P4 Resolver Diagnostic Faults not clearing.

Hi Harveen,

Harveen Janjua said:

excitation frequency amplitude of 140

Can you try setting the excfreq_level threshold to a lower value and check once, since you mentioned Excitation frequency has an amplitude of 140? Two more checks I can think of is

• If possible, can you please probe the actual signals and see if you are able to see the zero crossings in the Cosine signal?
• Also, since you mentioned of using Mode 0, can you please cross verify if the Cosine signals are correctly connected to ADC_R1_AIN0 and ADC_R1_AIN1 pins as shown in the Figure 7-140. Mode -0 of AM263Px Sitara Microcontrollers Technical Reference Manual (Rev. D).

I will ask my colleague to help with the SDK questions.

Thanks,
Tejas Kulakarni

Above screenshots for Excitation Frequency Degradation Diagnostics were with excfreq_level set to 140. 

I am using a single mode of sampling and RDC_SEQUENCER_MODE_0 with ADC_R1_AIN0(R16) for Cos and ADC_R0_AIN0(T18) for Sin. I do not have differential mode of sampling selected hence only one sin and one cos is provided as input to ADC_R0 and ADC_R1, where reference design is an excitation amplifier and analog front end for resolver sensors TIDA-01527 reference design | TI.com (TIDA-01527 Schematic)

I am attaching the screen shot where encoder feedback is recorded - channel 1 is differential Sin+/-, channel 2 is differential Cos+/- and channel 3 is differential Excitation. All the channels record a frequency of around 5KHz and are crossing at same point on x-axis.

Please not that speed and nngle feedback from RDC is correct its only just few faults that are not clearing.

Hi Harveen Janjua,

Harveen Janjua said:

Excitation Frequency Degradation Diagnostics sin and cos counts are toggling between 218/219 to 469, while expected count is suppose to be between 450 and 550. I see in oscilloscope that zero crossing for sin and cos is occuring at 5KHz but still this fault is not clearing.

The `excfreq_level` needs to be higher than noise margin, like Tejas mentioned, could you please try with a higher value like 255 or 300 ?

Harveen Janjua said:

Sine/Cosine Gain Drift and Cosine Phase Drift fault is triggered when going is positive direction but cleared in negative direction of speed.

Also, I have observed that gain_drift_threshold_hi, gain_drift_threshold_low, phase_drift_cos_hi and phase_drift_cos_lo are cleared while calling their individual set functions RDC_setDiagnosticsSinCosGainDriftData and RDC_setDiagnosticsCosPhaseDriftData. I am not sure if this is intentional or something that might have been fixed in other versions of SDK.

We identified that the writes are happening in the set functions for phaseGain related diagnostics at incorrect register offset. we get this corrected in the later releases. This could also resolve incorrect flag setting up in your case.

Thanks and regards,

Madhava

Thank you, Mihira, and Tejas for looking at this issue. 

I used 300 for excfreq_level and recorded excfreqdetected_sin in graph as shown below. I see the values of excfreqdetected_sin go in and out of threshold limits, but fault does not clear. Also modifying the excfreq_drift_threshold_lo / hi completely changes the feedback and I start getting random values for excfreqdetected_sin. In my understanding threshold is for checking sin/cos are within defined threshold and should be changeable based on my feedback on excitation signal. Like in below example if I change my threshold to be 350 and 450 then my sin feedback is ranging from 12 to 120 to 200 which is very confusing.

Apart from this I have seen that changing excfreq_level changed signal integrity sinsq and cossq values. I could be delusional here but just looking for more help as now signal integrity checks are failing.

Hi Harveen,

The excfreqdetected_cos/sin counts should never have been under threashold, if so, its a fault and would have flagged the error flag. the counts is a runtime counter data, having a CCS graph (slower graphing) will not help understand its behavior. what do you mean by feedback?  

thanks and regards,

Madhava

Hope you are doing well. As you pointed out data captured via debugger by CCS graph was very random and did not define the problem well. 

This time I am logging data by Serial Terminal COM port. Hope it gives you better picture of my problem. I am attaching 3 csv files which record diagnostics on excitation frequency and signal integrity.

/cfs-file/__key/communityserver-discussions-components-files/908/freq_5F00_exc_5F00_level_5F00_300.csv

• freq_exc_level_300.csv: Excitation level 300, excitation freq detected sin/cos counts are not between excitation drift low (450 excfreqdrift_threshold_lo) and high counts (550 excfreqdrift_threshold_hi). Cos*Cos is 6802, while Sin*Sin is 330 in magnitude for ADC input range of 70-90% [8027 sinsqcossq_threshold_lo, 13270 sinsqcossq_threshold_hi]

/cfs-file/__key/communityserver-discussions-components-files/908/freq_5F00_exc_5F00_level_5F00_240.csv

• freq_exc_level_240.csv: Excitation level 240, excitation freq detected sin/cos counts are not between excitation drift low (450 excfreqdrift_threshold_lo) and high counts (550 excfreqdrift_threshold_hi). Cos*Cos is 759, while Sin*Sin is 7129 in magnitude for ADC input range of 70-90% [8027 sinsqcossq_threshold_lo, 13270 sinsqcossq_threshold_hi]. Why is Sin*Sin magnitude more than Cos*Cos magnitude here is a mystery to me.

/cfs-file/__key/communityserver-discussions-components-files/908/signal_5F00_integrity_5F00_low_5F00_threshold_5F00_changed.csv

• signal_integrity_low_threshold_changed.csv: Signal Integrity responds with zero counts for Cos*Cos and Sin*Sin when ADC input range is reduced to 40% ie sinsqcossq_threshold_lo is 4095.

If there is something you want me to check on hardware side, then please do let me know. Thanks.

Hi Harveen,

This still seems very weird to us. We could not think of what would be causing this. Few below points can we check to ensure on hardware side everything is fine

1. Can we try to capture the raw Sine and Cosine waveforms just like above from the console terminal? This is just to see if ADC is having any issues and seeing noisy internal to MCU. Later we can figure out if we have to try out different ADC parameters like S&H or delay from ADC trigger.
2. Are you using ADC internal or External references? If using external voltage reference, can you please probe and verify if the reference is perfect 1.8V with no noise on it?
3. Is there any other switching circuit on board which can introduce noise (especially over time of few milli seconds) on these ADC lines? If yes, can you please disable all that circuit and may be run only this Resolver related circuitry?
4. If possible, can you please share the schematic of Resolver related circuitry. I can do a double check to see if we are missing anything.

Apologies if there are very basic checks but just want to ensure we are not missing anything.

Thanks,

Tejas Kulakarni

Thank you Tejas for looking into the issue. Response to your questions is as listed below:

1. Recorded ADC_observationalData data at 12RPM, 23RPM, 125RPM. Files attached.

/cfs-file/__key/communityserver-discussions-components-files/908/Resolver_5F00_ADC_5F00_logs.zip

2. I looked at TP20 on control card for AM263P4 PROC159A(001) and it is measured to be a constant of 1.8V. This TP corresponds to ADC_VREFHI_G3_R >> ADC_DAC-VREF >> VCC_1V8_LDO4.

3. We have just resolver related circuitry populated on external board which is connected to control card through HSEC connector.

4. I cannot share resolver circuitry on public forum. Are there any other modes of sharing required hardware design ?

Appreciate your time and help. Thanks

Hi Harveen,

Thank you very much for these.

Harveen Janjua said:

1. Recorded ADC_observationalData data at 12RPM, 23RPM, 125RPM. Files attached.

/cfs-file/__key/communityserver-discussions-components-files/908/Resolver_5F00_ADC_5F00_logs.zip

I checked the 12RPM data (resolver_adc_12RPM_2.csv) after PGC, I see that the Sine data seems to be offset? I will try to analyze other data later on. But can we try to fix this?

Harveen Janjua said:

2. I looked at TP20 on control card for AM263P4 PROC159A(001) and it is measured to be a constant of 1.8V. This TP corresponds to ADC_VREFHI_G3_R >> ADC_DAC-VREF >> VCC_1V8_LDO4.

Were you able to probe this on an Oscilloscope to see the voltage over time? I mean if there is any ripple on this reference voltage. Also, this VCC_1V8_LDO4 is used only if the SW7 is toggled and ADC is made to use external reference. Can you please cross verify this too from your Sysconfig/project?

Harveen Janjua said:

4. I cannot share resolver circuitry on public forum. Are there any other modes of sharing required hardware design ?

I have sent you an email. Please do share over email if that is fine and I will ask relevant people to review it.

Thanks,

Tejas Kulakarni

1. Fixed the sin cos signal by disabling DC offset configuration and enabling band pass filter on Core 0 and Core 1. For some weird reason my DcOffCal1 had incorrect assignment as discussed in another E2E query - AM263P4: Resolver RDC static config checks failing - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

2. Moved resolver ADC ref to HSEC_ADC-VREFHI by toggling SW7 to position 3 and providing an external 1.8V on corresponding HSEC connector. This 1.8V is stable with no noticeable ripple.

Attaching logs for 12RPM and 65RPM. Signals will not look smooth due to serial console COM communication.

/cfs-file/__key/communityserver-discussions-components-files/908/Resolver_5F00_BPFEnable_5F00_HSEC_5F00_ADCRef.zip

Thanks

Harveen

Hi Harveen,

Thank you very much for these. I am not able to infer much from these. Yes, the offset that was there is now fixed in both 12RPM and 65 RPM waveforms. But the waveforms look like below, mostly due to the COM communication artifacts as you mentioned.

Harveen Janjua said:

Please not that speed and nngle feedback from RDC is correct its only just few faults that are not clearing.

I know you had shared this Oscilloscope waveform from earlier, but can you take one more capture with the full rotation of a resolver? So that we can see that the excitation frequency is not getting clipped or something at lower amplitudes? Please do share that when possible.

Thanks,
Tejas Kulakarni