• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 439 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.

TMS570LC4357: HET HTU, first PCNT (RISE2FALL) for slow signals always zero

Ju_We
Intellectual 845 points
Part Number: TMS570LC4357

Hi,

I am getting started with writing my own HET Programs in the HET IDE and using HTU for data transfer. (Double buffer mode, but should not matter here).

Here's the program, captures duty-cycle and period on HET1_PIN12

L00 PCNT { hr_lr=LOW,next=L01,type=RISE2FALL,pin=12};
L01 PCNT { hr_lr=LOW,next=L02,reqnum=0,request=GENREQ,type=RISE2RISE,pin=12};
L02 CNT { next=L03,reg=B,max=1171,data=0};
L03 ECMP { next=L04,hr_lr=LOW,en_pin_action=ON,pin=7,action=PULSELO,reg=B,data=527};
L04 ECNT { pin=12,event=RISE,reg=A,data=0};
L05 BR { next=L00,cond_addr=L00,event=NOCOND};

L00 and L01 are of interest, L02 and L03 are just generating a signal, L04 is irrelevant.

The HUT is set up to transfer DF of L00 (on-time) and DF of L01 (period) to buffers bufferA and bufferB, which works well.
I am setting a breakpoint in the HTU interrupt 'bufferA finished'. I am wondering why for slow signals (~ 10Hz), the first on-time value is always zero. For faster signals it's not the case, the on-time is correct then.

Can anyone explain that behavior?

Regards,
Juergen

  • 0
    TI__Guru**** 196736 points

    The request is not enabled in L00, so the request in L01 is used to trigger the transferring of L00 DF and L01 DF, right? In this case, the frame count is 2, HET addr increment is 16bytes in HTU control packet. 

    I am not very clear about the "on time" transfer in your message. 

  • 0
    Intellectual 845 points

    Hi OJ, 

    let me be more clear about it. 

  • 0 in reply to Ju_We
    Intellectual 845 points

    Oops, sorry ...

    L00 PCNT { hr_lr=LOW,next=L01,type=RISE2FALL,pin=12}; on-time
    L01 PCNT { hr_lr=LOW,next=L02,reqnum=0,request=GENREQ,type=RISE2RISE,pin=12}; period

    I don't think it's correct what you said about the frame count. The frame count is the buffer depth, the element count should be 2. Either way, my HTU setup seems correct, it work as expected, except when I feed it with slow signals ( <= 10Hz).
    HTU is set up in double buffer mode with automatic switch between bufA and bufB.
    I set a HTU interrupt breakpoint which triggers when either bufA or bufB is full. The first interrupt is triggered when bufA is full. I'd expect follwing result in the buffer, assuming the frame count is 6:

    bufA      CONTENT  
     0        on-time cycle 1
     1        period cycle   1
     2        on-time cycle 2
     3        period cycle   2
     4        on-time cycle 3
     5        period cycle   3
    This is fine for for faster signals. For 10 Hz and smaller I get:
     bufA     CONTENT  
     0                  0
     1        period cycle   1
     2        on-time cycle 2
     3        period cycle   2
     4        on-time cycle 3
     5        period cycle   3
    This is only the case for the very first time the interrupt fires, after that it's fine. I don't expect that because L00 and L01 both start with rising edge. L00 ends and falling edge and L01 at rising edge. That's why I'd expect L00 to always be valid and never zero. L01 triggers the HTU transfer.

    Regards,
    Juergen

  • 0 in reply to Ju_We
    TI__Guru**** 196736 points

    Hi Juergen,

    Ju_We said:
    L00 PCNT { hr_lr=LOW,next=L01,type=RISE2FALL,pin=12}; on-time

    The HTU request and request number are not enabled in L00. How is HUT triggered to transfer L00 DF to RAM?

    For RISE2FALL (on-time), L00 PCNT captures the counter value into the DF field on the FALL edge.

    For RISE2RISE (period), L01 PCNT captures the counter value into the DF field on the RISE edge. But you should discard the first HTU request.

  • 0 in reply to QJ Wang
    Intellectual 845 points

    Hi QJ,

    I didn't intend L00 to trigger the HTU transfer, it's done by L01. My assumption is, that L00 has already captured the counter into its data filed since it measures from Rise2Fall and L01 from Rise2Rise. L01 triggers a HTU transfer which transfers DF of L00 and L01 in frames of two elements. Why do you suggest to discared the first transfer? I read something like that in ony of the docs. I believe it had to to with the sequence how HET and HTU are enabled and how HTU might trigger a request in a specfic situation which is not caused by edges of a signal. I tested that, I don't get unwanted transfers from HTU at startup. I don't just want to discared a result if I don't understand why it behaves the way it behaves.

  • 0 in reply to Ju_We
    TI__Guru**** 196736 points

    Hi,

    It's good to transfer L00 DF and L01 DF using one HTU request.

    Ju_We said:
    Why do you suggest to discared the first transfer?

    The L01 uses RISE2RISE, the period counter is captured and reset at rising edge.

    Please see the note in the PCNT instruction description section:

    Note: For FALL2FALL/RISE2RISE, the user should always discard the first interrupt/HTU request if
    interrupt/request are enabled before HET_ON. For both the types, reset edge and capture edge are the
    same and the interrupt or HTU request is triggered on capture edge (which is nothing but the reset edge).
    Once the execution unit is enabled, the first edge generates an interrupt but the value of the counter is of
    no use as this is not the period between 2 edges. So first edge after turning on N2HET is used mainly for
    resetting the counter and start the period count.