• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 550 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.

AM2434: HDSL Interface

Wolfgang Steinwender
Prodigy 20 points
Part Number: AM2434
Other Parts Discussed in Thread: SYSCONFIG

Hello,

I'm using 2 HDSL connections: On on PRU0-CHannel1 (PRU0) and one on PRU1 Channel 0 (PRU-RTU 1). I'm using of course ICSSG0, compatible with the launch-pad I/O's.

The Channels are configured well and the channels are running calling them one channel at the time.

So far so good, but running both channels simultaneously, is not possible. One channel will shut down after some ms.

It is no EMI issue, because i made various tests, that moves the same wires, and I do not see an problem.

Going on further, it seems that the clock of the TX unit/Fifo is not independent from PRU-Slice-0 to PRU-Slice-1.

As soon i make a test Program running in place of on HDSL Channel and I swtich the Clock from FAST to NORMAL and to SLOW, the other

DSL Channel will go into fault. Transmitting instead data patterns with the fifo withut changing the clock,everything works.

Have anyone an Idea, how to overcome that problem and if my supposition that the Tx-Clocks are not independent is right ?

If it is so, the design of the PRU S/W is not siutable for multi-axis/Encoder Application and must be reviewed.

e.s. The Multi-channel define does not work at all, so I would prefere to have a design that is independent and does not foresee to much mixes.

Note: I interfaced the LP to my H/W (multiaxis (4) Drive/Encoder) which is using FPGA-IP for the HDSL's, so the H/W Setup is without doubt OK.

In advance, thanks to your kindly response.

  • 0
    TI__Mastermind 27824 points

    Hello

    I had couple of questions

    • Which version of SDK are you using?
    • Which SDK example are you using? 

    With 225 MHz PRU-ICSSG core clock frequency, it is difficult to achieve multi-channel HDSL from same PRU-ICSSG slice. Hence we have switched to 300 MHz for 2 channel support. 300 MHz frequency based firmware avoids HDSL interface clock frequency switching which you are seeing if I understand correctly.

    The example which supports 2 channel is available in "motor_control_sdk_am243x_09_00_00_05\examples\position_sense\hdsl_diagnostic\multi_channel" folder. Motor Control SDK can be installed from here : https://www.ti.com/tool/download/MOTOR-CONTROL-SDK-AM243X/09.00.00.05.

    Due to hardware limitation on our evaluation launchpad am243x-lp, we are only supporting this on our am243x-evm right now. 

    Regards
    Dhaval

  • 0 in reply to Dhaval Khandla
    Prodigy 20 points

    Hello, thank you for you immediate response,

    I'm using SDK 12.4.0.00007 and mcu_plus_sdk_am243x_08_06_00_45.

    SDK version should not have any influence. I will try with the support package indicated by you and let you know.

    In the mean time Thank you,

  • 0 in reply to Dhaval Khandla
    Prodigy 20 points

    Hello,

    I tried with the new support package.

    On the AM2434-LP I'm using Channel 0&1 of PRU0 of ISSG0, but I thing thare is no difference. Same setup as for the evm, but on PRU0 instead of PRU1.

    Of course i recompiled two different projects with the right settings for PRU_RTU_0 and PRU0 (respective channel 0 and 1).

    With the new package the data-link channels in multichannel/300Mhz mode are ok for alternate activation as before at 225Mhz

    In 225Mhz mode the data-link channel does not work anymore. (after the first RX-Frame the Tx-Frames are not completed) and the channels restarts. (But I did not do deeper investigations, maybe the tx-fifo is blocked)

    At 300Mhz, respect to the old version the Link of the other channel stays active some more seconds (random 1 to 10s) and does not shutdown immediately as before, but the problem with the clock switching has not been resolved. In the S/W I still find tx-clock-div switching.

    I suppose even everything runs from the beginning at oversample speed and forever or there is no way out.

    Best regards,

  • 0 in reply to Dhaval Khandla
    Prodigy 20 points

    Hello,

    I tried with the new support package.

    On the AM2434-LP I'm using Channel 0&1 of PRU0 of ISSG0, but I thing thare is no difference. Same setup as for the evm, but on PRU0 instead of PRU1.

    Of course i recompiled two different projects with the right settings for PRU_RTU_0 and PRU0 (respective channel 0 and 1).

    With the new package the data-link channels in multichannel/300Mhz mode are ok for alternate activation as before at 225Mhz

    In 225Mhz mode the data-link channel does not work anymore. (after the first RX-Frame the Tx-Frames are not completed) and the channels restarts. (But I did not do deeper investigations, maybe the tx-fifo is blocked)

    At 300Mhz, respect to the old version the Link of the other channel stays active some more seconds (random 1 to 10s) and does not shutdown immediately as before, but the problem with the clock switching has not been resolved. In the S/W I still find tx-clock-div switching.

    I suppose even everything runs from the beginning at oversample speed and forever or there is no way out.

    Best regards,

  • 0 in reply to Wolfgang Steinwender
    TI__Mastermind 27824 points

    Hello

    Wolfgang Steinwender said:
    At 300Mhz, respect to the old version the Link of the other channel stays active some more seconds (random 1 to 10s) and does not shutdown immediately as before, but the problem with the clock switching has not been resolved. In the S/W I still find tx-clock-div switching.

    Is it possible for you to share the snapshot from scope/logic analyzer capture of clock and data signals when the communication is stopping, and when you see tx-clock-div switching? 

    Wolfgang Steinwender said:

    I suppose even everything runs from the beginning at oversample speed and forever or there is no way out.

    Yes, in 300 MHz mode, we are always using oversample and never switching the clock frequency.

    Regards
    Dhaval

  • 0 in reply to Dhaval Khandla
    Prodigy 20 points

    Hello,

    Blu is TX-EN, Red is Data-In, Green is Dataout of CH0,

    Yellow is TX-EN of CH1.  You see as soon PRU0 is starting CH0 will Stop. May because of the REINIT_TX in datalink_init ??

    It is global to all channels as far as I could understand from the TRM, but may be I'm wrong. May in load share mode it is refreed only to one channel ???

    Single channel problem:

    Cyclily the communication restarts becaus of missing response of the Encoder. Something in the Tx-Frame is wrong.

    Maybe only for some few ns.

    With the old files in 225Mhz mode this error is not present.

    If you want a direct link to me contact me on my E-Mail. It's maybe easier to exchange data.

    Best Regards.

  • 0 in reply to Wolfgang Steinwender
    TI__Mastermind 27824 points

    Hi

    Wolfgang Steinwender said:

    Yellow is TX-EN of CH1.  You see as soon PRU0 is starting CH0 will Stop. May because of the REINIT_TX in datalink_init ??

    Are you starting CH1 after CH0 with some delay in between them?

    Wolfgang Steinwender said:

    It is global to all channels as far as I could understand from the TRM, but may be I'm wrong. May in load share mode it is refreed only to one channel ???

    You are correct. REINIT_TX is global, even in load share mode.

    Wolfgang Steinwender said:

    Single channel problem:

    Cyclily the communication restarts becaus of missing response of the Encoder. Something in the Tx-Frame is wrong.

    Maybe only for some few ns.

    Do you see the same issue with 300 MHz Single Channel mode also?

    Regards
    Dhaval

  • 0 in reply to Dhaval Khandla
    Prodigy 20 points

    Hello,

    I commented out the REINIT_TX and both channels are working except for the restart on channel 0.

    Not 100% good, but much better. I'm running in 300Mhz free-run and Multi channel without any modification on the original source code except for the initial reinit_tx comented out.

    The Single channel 300M I did not try. Tomorrow i will do it and let you know.

  • 0 in reply to Wolfgang Steinwender
    TI__Mastermind 27824 points

    Hello

    Wolfgang Steinwender said:

    I commented out the REINIT_TX and both channels are working except for the restart on channel 0.

    Not 100% good, but much better. I'm running in 300Mhz free-run and Multi channel without any modification on the original source code except for the initial reinit_tx comented out.

    Okay. What do you mean by "except for the restart on channel 0" here? I did not understand it fully.

    Wolfgang Steinwender said:
    The Single channel 300M I did not try. Tomorrow i will do it and let you know

    As mentioned in Release Notes of SDK 9.0, 225 MHz based example not working is a known issue in this release.

    Regards
    Dhaval

  • 0 in reply to Dhaval Khandla
    Prodigy 20 points

    Hello,

    The single channel version of the 300M code (compilation of the PRU code with symbol FREERUN_300_MHZ and without HDSL_MULTICHANNEL does not work.

    You see that the response of the Encoder comes, but only one further transmission occurs. Then the communication restarts from scratch This means that the response of the Encoder/test pattern probably is not encoded well.

    What I do not understand is, why you distinguish from Single Channel and Multi Channel. The PRU code is always single channel that does not interact between the other channels, neither for variables nor for Physical signals. I would cancel the term single channel or what do you think ??? But, maybe I do not understand something....

  • 0 in reply to Wolfgang Steinwender
    TI__Prodigy 280 points

    For running HDSL in 300Mhz PRU clock, you need to use both symbols ( "FREERUN_300_MHZ" and "HDSL_MULTICHANNEL") even if you want to use single channel. We already documented that if you want to use single channel you can select channel options in sysconfig menu and rebuild the application. You dont need to rebuild the firmware for that.