• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 2650 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.

EnDAT Firmware - Is there a pure C or Assembly code available?

Jacek Jaworski
Expert 1325 points

Other Parts Discussed in Thread: SYSBIOS

Hello,

I tried to write the software using EnDAT encoder based on my IDK AM437X with sysbios ind sdk 2.1.1. 2. In the motor_control example, the PRUICSS0 is used to handle ADC and EnDAT measurements by downloading SMARTADCPRU1 and EnDatFirmware tables into PRU1 and PRU0. The SMARTADCPRU1 firmware can be analyzed in details in pru_onchip_adc_sampling project. For EnDAT the firmware is provided but I cannot find any project handling EnDAT in sdk/interfaces/endat_master. Where can I find any information about this firmware because I do not know if it is available to change any data related to PRU0, e.g. INTC mapping ( PRU0 and PRU1 Hosts seem to be used for EnDAT triggeringin PRUICSS0)?

Thanks!

JJ

  • 0
    TI__Guru**** 393215 points
    I will forward this to the ISDK team.
  • 0
    TI__Expert 7570 points
    Hi JJ

    There is an EnDAT test application which provides an introduction to EnDAT configuration and operation. This is available at {IA_SDK_HOME}\examples\endat_diagnostic. There is also an EnDat 2.2 System Reference Design which contains API descriptions and Flow charts on the operation at.at www.ti.com/.../tidep0050

    David
  • 0 in reply to David Zaucha
    Expert 1325 points

    Hi David,

    Thanks for your answer. I know these sources and none of them provides information on details of EnDatFirmware from endat_master_bin.h - it is only downloaded into PRU program memory... I suppose the EnDatFirmware source code is not 'publicly accessible'?

    I still have not found any information about a few things, could you please give me some details?

    1: After downloading EnDatFirmware and EnDAT initialization, PRU does not save the angle measurement automatically somewhere in shared RAM - every time I need to send command (e.g. by function endat_get_2_2_angle) and wait for the measurement to be done?  

    2: the EnDAT giude says we communicate to the firmware through the shared memory. Does it mean the general purpose 32KB of PRUICSS shared memory or Cortex L3 OCMC0 SRAM at 0x40300000 written to constant table C30?

    3: in endat_diagnostic example the INTC vector in PRUICSS0 is not mapped, whereas in motor_control example EnDAT in PRU0 seems to be triggered by pr0_pru_mst_intr0_intr_req interrupt via HOST_INTERRUPT_0 and PRU0 informs about measurement completion by pr0_pru_mst_intr3_intr_req interrupt via HOST_INTERRUPT_1. It means that in motor_control example enDAT works in clkmode freerun, am I right? Are these settings (interrupt number and host number) mandatory or can I change them - e.g. to be triggered by different intr_req?

    Thank you!

    JJ

  • 0 in reply to Jacek Jaworski
    TI__Expert 7570 points

    Hi JJ

    The next ISDK release 2.1.2 release will make EnDat firmware sources public.

    EnDat and SDDF only use their corresponding PRU data memory for communication with the ARM . Note that ICSS0 (also known as ICSS_L ) does not have a shared memory. OCMC RAM is not used by EnDat or SDDF

    We are not quite sure if you mean EnDat continuous mode as clkmode free run. In this case, the answer is no. The EnDat encoder is in normal clock mode.
    In the motor control example, we use the periodic triggered mode of the EnDat firmware. The EnDat diagnostic uses the host triggered mode of the firmware.

    Regarding the last question, some background is needed. The only requirement to configure periodic triggered mode is that ICSS_L IEP CMP2 has to be setup with required timing for periodic trigger mode. In the motor control example, This is done by ADC PRU (OnChip/SDDF). The updated API guide usage section that will be in the upcoming release has a some more information on this. The EnDat firmware periodic triggered mode is not triggered by host interrupt and there is no indication provided by EnDat PRU for completion via interrupt. The PRU indicates completion only by clearing of particular bit through the shared memory interface).
    As a result, there is no interrupt settings required for EnDat firmware.

    The sddf design guide in {IA_SDK_HOME}\interfaces\sddf\doc has some additional information. I believe that the references to CMP2 in the document should be CMP1.
     
    David

  • 0 in reply to David Zaucha
    Expert 1325 points
    Hi David,
    Thank you for your answer and sorry for late response - I needed to test the things you wrote.
    My Endat encoder is now properly initialized and works well in host-triggered mode. However, the main problem now is that I cannot find any detailed information about differences between Host-triggered and Periodic-triggered modes. Do they differ in such a way that in the first mode it is controlled by the host (Cortex) which needs to send command and waits for the answer while in the second mode the measurement is triggered by the IEP_CMP2 and the host only needs to get the data from the PRU memory (e.g. by endat_get_2_2_angle function)?
    In my case the FOC must be synchronized by PWM signal - its interrupt may be transported to the respective PRUICSS module for ADC and Endat handling. There is no problem with ADC but I am not sure how to use Endat driver effectively - to maximize the conversion speed I probably need to use Periodic-triggered mode with IEP_CMP2. I saw how to synchronize PWM by IEP signal (there is appropriate gate at the eHRPWM module), but is it possible to do that in the opposite way? I mean - to trigger Endat measurement with PWM interrupt (probably by using IEP somehow)?
    Once again thank you for your answer.
    JJ
  • 0 in reply to Jacek Jaworski
    TI__Expert 7570 points
    Hi JJ

    1. In host triggered mode host triggers command send
    2. In host triggered mode, as well as the periodic trigger mode, the user has to wait until the command is finished to get received data
    3. In periodic trigger mode, the IEP CMP2 event triggers command send, the pre-requisite is that host has to setup the command to be sent beforehand
    4. Though in periodic trigger mode the host has to wait till command process is finished. Note - in the FOC code the EnDat trigger is synchronized to the FOC interrupt such that by the time FOC interrupt happens the last EnDat command is guaranteed to complete. This keeps to keep the interrupt handling code light weight so that there is no wait for the command completion. Additionally, to keep interrupt handling code to minimum, “endat_get_2_2_angle()” is invoked (command setup in FOC is EnDat 2.2 position) instead of an alternative (more lengthily) method which would be a combination of “endat_recvd_process()” & “endat_recvd_validate()” as done in EnDat diagnostic example.
    5. In the current release, Reg triggering EnDat with PWM event, in FOC , is implemented when the Sigma Delta is used for the ADC input.
    In the next release (2.1.2), Reg triggering EnDat with PWM event will be available for both Chip ADC and Sigma Delta input.
    6. All of the components of the drive system are synchronized in Sigma Delta in the current release. The same will be true with the on Chip ADC with next release. The IEP counter is configured by ADC PRU to reset on PWM3 SYNCOUT (which in turn is configured to trigger at PWM start), CMP1 is programmed to trigger ADC SOC from PWM start & CMP2 to trigger EnDat from PWM start. The FOC interrupt is triggered indirectly on ADC EOC (via an event by ADC PRU upon detecting actual ADC EOC). In effect ADC, EnDat & FOC interrupt is in synchronization with PWM.

    David
  • 0 in reply to David Zaucha
    Expert 1325 points

    Thanks David, it is much more clear now.

    Regards,

    JJ