• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 34 subscribers
  • Views 190 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM263P4-Q1: Resolver (RDC) Programming

Kier
Mastermind 9920 points

Part Number: AM263P4-Q1
Other Parts Discussed in Thread: SYSCONFIG

Hello,

I'm trying to integrate the resolver diagnostic example (resolver_diagnostics_am263px-cc_r5fss0-0_nortos) into our application.

 

1) Our timing budget means we can't afford to execute all the diagnostics in one call of App_checkDiagnostics() so I intend to split up the diag routines and execute in a round robin style. Is each diagnostic type independent? For example, can I execute " Monitor Sin or Cos DC offset drift(DOS)" in a different 10ms slot to " Monitor Sin or Cos Gain drift (DOS)". If so, is the order of execution of the diagnostics also unimportant?

2) In App_diagnosticsISR() the code commented as “ADC health check” calls calibration APIs (e.g. RDC_enableCalibration(gRdcBaseAddr);) repeatedly writing to RESOLVER_REGS_CAL_CFG. The characters CAL_CFG don’t appear anywhere in the TRM so what are the guidelines for calling these APIs? Must calibration be done before each and every diagnostic type? The TRM Programming Sequence for the diagnostics doesn’t mention this step as far as I understand it.

3) In the TRM it mentions “diagnostics checks can be performed using the registers in below Table…which are referred to as IRQ registers”. In your example, the RDC interrupts are not enabled so is it correct the IRQ registers are usually polled and using interrupts are optional?

4) In the TRM for 7.5.3.3.1.1 Monitor Sin or Cos DC offset drift (DOS) it says “RDC needs to be rotating for this diagnostics to work.” However, the example commented “Checking the Sine and Cosine Offset Drift” does not check for motor rotation. Which out of TRM and example is correct please?

5) In the example, RDC_setDiagnostics... is called every ISR for each type of diagnostic. Is this doing the “diagnostics health check”? If so, is it essential to do the health check on every ISR before polling the error flags or is it for demo purposes only? In other words, in a real application I would do the health check just once per operation cycle rather than every ISR, is that correct?

 

Thank you.

  • 0
    TI__Expert 3740 points

    Hi Kier,

    Apologies for the delay. Please find my replies below

    Kier said:
    For example, can I execute " Monitor Sin or Cos DC offset drift(DOS)" in a different 10ms slot to " Monitor Sin or Cos Gain drift (DOS)". If so, is the order of execution of the diagnostics also unimportant?

    Yes, you should be able to run these in different slots. But do ensure to do those checks based on their requirements. Few checks need the Resolver shaft to be rotating and few do not.

    Kier said:
    4) In the TRM for 7.5.3.3.1.1 Monitor Sin or Cos DC offset drift (DOS) it says “RDC needs to be rotating for this diagnostics to work.” However, the example commented “Checking the Sine and Cosine Offset Drift” does not check for motor rotation. Which out of TRM and example is correct please?

    The RDC needs to be rotating for sure. Since the example is just showing implementation, I guess it does not show the part of checking for rotation.

    I have asked my colleagues to answer the rest of the questions. They should have replies to these questions in couple of days.

    Thanks,
    Tejas Kulakarni

  • 0 in reply to Tejas Kulakarni
    Mastermind 9920 points
    Tejas Kulakarni said:
    The RDC needs to be rotating for sure. Since the example is just showing implementation, I guess it does not show the part of checking for rotation.

    Thank you. My point is that in the example code, other diagnostics do check for rotation:

        if(gMotorState == MOTOR_ROTATING)
    {
    
    }

    However, this is not checked for "Monitor Sin or Cos DC offset drift (DOS)". So from your response, the example code needs correcting at the next opportunity.

  • 0 in reply to Tejas Kulakarni
    Mastermind 9920 points

    Hello  I've not seen any replies from your colleagues for the other questions. Can you prompt them please?

  • 0 in reply to Kier
    TI__Expert 3740 points

    Hi Kier,

    Apologies for the delay. I have reached out again to our colleagues. Please expect a response in couple of days.

    Thanks,
    Tejas Kulakarni

  • +1
    TI__Prodigy 60 points

    Hello Kier,

    Please find the answers to your questions below:

    1) Yes, each diagnostic type is independent of each other. They monitor different signal paths and use separate DIAGx registers and separate interrupt sources. The order of execution is generally unimportant as they are monitoring different physical/mathematical properties. But try to run the more critical diagnostics (for your usecase) at a higher frequency than the less critical ones.

    2) Calling calibration isn't required before every diagnostic type. It is just a way to verify that the adc channels used by the RDC are functioning correctly. Calibration check is best used as "adc health check" during startup or periodically in a low frequency ISR. The TRM programming sequence doesn't mention this because calibration doesn't come under diagnostics.

    3) Yes, using interrupts are optional. Both methods are valid and can be used. Polling is a more efficient method where we can know the status of the diagnostic registers at the end of a control cycle instead of checking for example in a high frequency ISR. Use interrupts if you want immediate notification, otherwise if your application can tolerate a small delay between a fault occurring and being detected, polling is also fine.

    4) The TRM is correct, the external resolver needs to be rotating for the diagnostic "Monitor Sin or Cos DC offset drift (DOS)". The example just shows how the apis should be used, rotation should be checked by the application according to the diagnostic being checked. Diagnostics like Sin/Cos High Amplitude, Sin/Cos Weak Amplitude, offset drift, excitation frequency degradation and sin^2+cos^2 integrity do not require rotation only that a valid excitation and signal is present. Diagnostics like Sin/Cos Gain Drift (DOS), Phase Drift, and Rotational Signal Integrity rely on the Phase Gain Estimation block or the demodulation process. These ones do require rotation.

    5) RDC_setDiagnostics... apis write threshold values into the RDC hardware. Call these only once during initialization (or when the thresholds change). Monitoring using RDC_getDiagnostics... apis is what should be done periodically in the ISR. Here, in the example RDC_setDiagnostics... is being called to inject a fault for self-test. ADC Calibration health check should be done during startup or periodically in a low frequency ISR.

    Best Regards,
    Aditya Byju

  • 0 in reply to Aditya Byju
    Mastermind 9920 points

    Thanks for the thorough reply Aditya.

  • 0 in reply to Aditya Byju
    Mastermind 9920 points

    One more question please . I'm finding the RDC diagnostics are taking a long time (microseconds), CPU time we can't afford in our motor control Core 2.

    Since the diagnostics are largely independent of the resolver use, is it possible to run RDC diagnostics in Core 3 while the RDC position and velocity takes place in Core 2? Put another way, can Core 3 "see" the RDC configured in Core 2 SYSCOFNIG?

  • +1 in reply to Kier
    TI__Prodigy 60 points

    Yes, RDC is a single memory-mapped peripheral so core 3 would be able to access the required registers. You can keep read-only diagnostics in core 3 (RDC_get*() apis). RDC_setDiagnostics() can be called in core 2 itself. Interrupt-based diagnostic apis should also ideally be called in core 2 to prevent any race conditions with core 3. This should help to offload some compute time to core 3. Since Sysconfig sets up the RDC register values, so these would be visible to any core with bus access to the relevant registers.