• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 98 subscribers
  • Views 293 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.

Original question:

AM6442: Endat2.2 : Loadshare encoder hardware connectivity

LP-AM243: EnDat restart/reconnect fails sporadically

Stefan Schlee
Prodigy 165 points

Part Number: LP-AM243
Other Parts Discussed in Thread: SYSCONFIG

 
Hi experts,
 
I have the same application requirement as described in the original post: the system should support one or two connected EnDat encoders, and it should be possible to detect and use only the channels where an encoder is actually present.
 
I am trying to solve the problem as suggested in the original post: Restart the full EnDat firmware with a different encoder configuration.
I am currently investigating reconnect behavior after stopping and restarting the EnDat diagnostic example.
 
My test is:
 
1. Start the EnDat diagnostic example.
2. Successfully initialize and detect the encoder.
3. Stop all PRUs.
4. Run the same EnDat initialization sequence again.
 
The first initialization works reliably. However, the second initialization only succeeds in about 50% of the attempts.
 
I checked the raw EnDat signals with an oscilloscope. In failing cases, I either see no PRU output signals at all, or the EnDat clock starts with a short pulse on endat_out_en, and then the PRU appears to get stuck.
 
Is there a recommended sequence for stopping, resetting, reloading, and restarting the EnDat PRU firmware so that reconnecting is reliable?
 
I also tried to manually clear all memory which i can see being used
- The PRU RAM
- The static endat priv struct within the endat driver
- The endat receive buffer placed in the local TCM
- cleared the COUNTER_ENABLE flag in the PRU status register, which seems to be not resetted by the ICSSG_resetCore()
- I even did a full memory dump of the ICSSG before the first and second startCore() calls, i can't see any meaningfull difference
 
Maybe you could give some more insights or try to recreate the example?
 
I think for reliable EnDat masters it is crucial to be able to recover from connection errors, which in this case seems to require the full restart of the PRU firmware. Therefore i think this should be added as tested feature.
 
Best regards,
Stefan
  • 0
    TI__Expert 4720 points
    Stefan Schlee said:
    Is there a recommended sequence for stopping, resetting, reloading, and restarting the EnDat PRU firmware so that reconnecting is reliable?

    I will check on this and get back to you.

    BR,

    Achala Ram

  • 0 in reply to Achala Ram
    TI__Expert 4720 points

    Hi Stefan,

    Which motor control SDK version are you using?

    Stefan Schlee said:
    1. Start the EnDat diagnostic example.
    2. Successfully initialize and detect the encoder.
    3. Stop all PRUs.
    4. Run the same EnDat initialization sequence again.

    Are you able to test step 2? are you able to successfully detect the connected/disconnected channels?

    Before executing step 4, you also need to update the EnDat configuration parameters, such as the channel mask and primary core, which are configured based on the selected channel in SysConfig.

    BR,

    Achala Ram

  • 0 in reply to Achala Ram
    Prodigy 165 points

    Hi Achala,

    i am using the motor control SDK 2025_00_00_06.

    The exact example i am using is the "endat_diagnostic_multi_channel_load_share_am243x-lp_r5fss0-0_freertos_ti-arm-clang" on the am243 launchpad + boosterpack.

    Currently, i am not yet tackling the encoder detection/channel configuration update part.

    I am just trying to restart the EnDat connection procedure with the same encoder configuration: Channel 0 and Channel 2 enabled.

    I tried the most simple modification to the example: Copy-pasting the full initialization steps 2 and 3 in the endat_diagnostic.c.

    However, the second initialization fails. Looking at the encoder signals on the oscilloscope, the PRUs are not sending any signal on the second initialization procedure.

    I have attached you my modified endat_diagnostic.c and also the serial terminal log. It shows the first successfull and the second failed initialization:
    modified_endat_diagnostic.zip

    I have also tried only copying the 3. step (load pru firmware), but this did not work either.

    Best regards,

    Stefan

  • 0 in reply to Stefan Schlee
    TI__Expert 4720 points

    7506.endat_diagnostic.c

     endat_api.hendat_drv.c

    Hi Stefan,

    Please find the attached files. With these changes, I am able to detect channel failure during the initialization phase and continue the operation for the connected (partial) channel.

    The changes include the following:

    1. Enabling the PRU core one by one during the initialization step with the updated channel mask.
    2. After initialization is completed for all cores, It updates the attrs parameters and channel mask for connected channel. For attrs  parameters such as the channel mask and enabled channels, I have added a new function in the EnDAT driver named endat_update_channel_mask.

    You will need to update the driver files with these changes and rebuild the libraries to build the modified EnDAT load share example.

    Best regards,
    Achala Ram

  • 0 in reply to Achala Ram
    Prodigy 165 points

    Hi Achala,

    thank you very much for diving into this problem.

    I have applied your changes and I have tested it on my launchpad with two connected encoders on channel 0 and 2.

    However, i am seeing a similar problem as in my first tests: The second encoder on channel 2 is only detected in about 50% of all tests.

    Although i am not changing anything on the hardware setup, on every reboot i am seeing one of these two scenarios:

    1. Both encoders are detected successfully: logfile_success.txt

    2. Only the first encoder is detected, and the application continues with only one encoder:logfile_fail.txt

    Can you confirm this inconsistent behaviour on your setup?

    Best regards,
    Stefan

  • 0 in reply to Stefan Schlee
    TI__Expert 4720 points
    Stefan Schlee said:
    However, i am seeing a similar problem as in my first tests: The second encoder on channel 2 is only detected in about 50% of all tests.

    Hi Stefan,

    Can I get more details about this? What is the scenario for the 50% test cases, is that when both encoders are connected or one disconnected? Also, is the failure that it cannot continue operation for the connected channel, or that it cannot correctly detect the failed channel?

    BR,

    Achala Ram

  • 0 in reply to Achala Ram
    Prodigy 165 points

    Hi Achala,

    In the test scenario, I connected both encoders to channels 0 and 2.

    The expected behavior can be seen in my logfile_success.txt: both encoders are detected and working correctly.

    In the sporadic failure case (logfile_fail.txt), only the first encoder is detected successfully. For the second encoder, endat_wait_initialization() times out. Due to your modifications, the example then continues running with only the first encoder on channel 0.

    Please note that this does not appear to be a hardware issue. When using the original example, the connection to both encoders works reliably every time.

    This also matches my earlier tests using the same hardware setup with both encoders connected. I first initialized both encoders as in the standard example and then attempted to restart the complete connection procedure. That restart also failed sporadically.

    It seems that once any EnDat firmware on the PRU has been started, subsequent startups may fail sporadically.

    Best regards,
    Stefan

  • 0 in reply to Stefan Schlee
    TI__Expert 4720 points

    Hi Stefan,

    There is an issue on the firmware side that is causing this problem. I will fix it and share the updated firmware with you soon.

    BR,

    Achala Ram

  • 0 in reply to Achala Ram
    Prodigy 165 points

    Hi Achala,

    this is good news, thank you for your effort!

    BR, Stefan

  • +1 in reply to Stefan Schlee
    TI__Expert 4720 points

    Hi Stefan,

    Use the attached updated firmware and let us know your test results and feedback.

    Note: Build all firmware project before building application.

    SDK version: Motor control 2025 

    BR,

    Achala Ram

    8156.endat_main.asm

  • 0 in reply to Achala Ram
    Prodigy 165 points

    Hi Achala,

    sorry for the delayed response; I was on holiday.

    I will test it as soon as possible and let you know the results.

    BR, Stefan

  • 0 in reply to Achala Ram
    Prodigy 165 points

    Hi Achala,

    I tested the updated firmware, and everything works!

    I was able to successfully verify both approaches:
    a) Your proposed solution for detecting active channels via sequential initialization
    b) My original approach of restarting and reinitializing the entire PRU slice

    Will this fix be integrated in the next SDK release?

    BR, Stefan

  • 0 in reply to Stefan Schlee
    TI__Expert 4720 points

    Thanks Stefan!

    Stefan Schlee said:

    Will this fix be integrated in the next SDK release?

    Yes, it will be integrated in next release!