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.

CCS/TMS570LS0432: HTU data Transfer using N2HET is not working as configured

Part Number: TMS570LS0432
Other Parts Discussed in Thread: TMS570LC4357

Tool/software: Code Composer Studio

Hello,

          In our project we are using the HTU module to transfer the data using N2HET when falling edge is detected. But the order of the buffer elements are transmitted randomly when data is written into the free buffer. I have described the scenario better in the image attached below. Please help us resolve this issue asap. We have also enabled interrupt and the flag is getting set but it is never going to the interrupt service routine.

Thanks/Regards,

Rahul Balachandran

  • Hello Rahul,

    Once a request is triggered, it starts a frame transfer. A frame can contain one or more elements. It won't transfer frames per one trigger. Do you have more than 1 HTU request per LRP in your code? Can you share your NHET code?

  • Hello Wang,

                  No, we have only one htu request per LRP. Also TMS570LC4357 is the uC which we are using. I tagged the wrong part number by mistake. In our case, we have 3 frames with each framing having 2 32 bit elements. In the first instance of the trigger, 0's are being transmitted and then frame 1and frame 2. In the next trigger, frame 3 is transmitted first, then frame 1 and frame 2. I am attaching an image below for your illustration. 

  • Hello,

    Are there any error bits set in HTU error register (ACPE)? Can you please share the HTU configuration?

    At the rising edge of the second pulse, the DCP should be disabled, then enabled after the falling edge happens. If you don't stop the DCP, it will transfer the next frame (frame 3).

     

  •  Hello Wang,

                 The desired sequence is frame 1, frame 2 & frame 3. We are not able to understand why HET is transmitting zeros instead of frame 1. To meet our requirements, we have written a HET code to detect the falling edge of the pulse to transmit frame 1 , frame 2 and frame 3. When this falling edge is detected, htu triggers transfer frame1 from the main memory to HET instruction (SHFT) and we have configured additional two more HTU triggers for frame 2 and frame 3 before the detection of next falling edge. As shown in the image below, 3 htu triggers occur between two consecutive falling edges.

    The HTU configuration is as shown below:

    IHADDRCT_U.Value = htu2DCP->DCP[0].IHADDRCT;
                IHADDRCT_U.IHADDRCT.TMBB = CircularBuffer; //Configure BufferB as AutoSwitch.
                IHADDRCT_U.IHADDRCT.TMBA = AutoSwitch; //Configure BufferA as circular Buffer.
               htu2CDCP->CDCP[0].CFADDRB = htu2CDCP->CDCP[0].CFADDRA;

    same is done for buffer A also.

    Thanks/Regards,

    Rahul B

  • Hello Rahul,

    If you don't use "CP A", please don't define the control packet for "CP A" and don't enable "CP A". 

    CPENA is used to enable and disable the CP: CPENA[1:0] = b10 --> CP B is enabled and CP A is disabled          

    If CP A is enabled, the buffer A is transferred first, then switch to buffer B automatically since  CP A is "Auto Switch Mode"

  • Hello Wang,

            We are using both the buffers. one buffer is used for transferring contents to NHET and when it is busy we are saving the new data in the other buffer. Our primary issue is that even though we have configured to transmit the 3 frames in the buffer somewhere this is getting affected with zeros getting transmitted only in the first instance of the htu trigger thereby altering the frame order.

    Expected sequence

     falling edge -> Frame 1 Frame 2 Frame 3 Next falling edge -> Frame 1, frame2 and frame3 and this continues

    but what is actually happening is

    Falling edge -> Zeros Frame 1 Frame 2 Next falling edge -> Frame 3, Frame 1 and frame 2 and this continues

    or this is occuring

    Falling edge -> Zeros Zeros Frame1 Next Falling Edge -> Frame2, Frame 3 and Frame 1.

    Sometimes we are getting the actual expected sequence. We are not able to understand from where the zeros are getting transmitted.

    Thanks/Regards,

    Rahul Balachandran

  • Hello Wang,

         Can you please share your id ? I can share the code to you privately. It is very critical to resolve this for us so please support to close this asap. Due to project confidentiality we cannot share the code here in the forum.

    Thanks/Regards,

    Rahul Balachandran

  • Rahul,

    Please refer to the "Dual Buffer Implementation" in TRM.

    The frame is transferred after the HTU trigger event occurs, and the transfer is not triggered by the falling edge of the pin. There are 3 trigger events in the first period of pin, there are 3 frames are transferred. If you want to transfer frame 3 in the 1st period, you need another trigger event. 

  • Hello Wang,

      We have implemented code to initiate HTU trigger event which will transfer data from SRAM to the SHFT instruction in HET code. The HTU will be triggered based on the following two conditions

       a) After falling edge of the pin is detected

       b) After data in the shft instruction becomes zero.

    Our preferred transmission sequence is Frame 1, frame 2 and Frame3. I have attached another image describing our issue. Our main issue is sometimes it is working as expected and most of the times it is working as shown in the highlighted box (Shuffled order of frames). Please share your contact details so that we can discuss offline. Looking forward to your support.

    Thanks/Regards,

    Rahul Balachandran.

  • Hello Rahul,

    I just send you friend request, so we can work on this issue offline. Thanks

  • Discussing the issue offline.