• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 326 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.

RM48L952: N2HET 32Bit Capture Support

Mux
Intellectual 620 points
Part Number: RM48L952

Hello TI

I have a question regarding serveral instructions e.g. PCNT in order to measure pulse lengths. According to the TRM, TI says that the PCNT instruction is using a 32 Bit data field which consists of 25 bit real data as well as 8 Bit data field for the HR structure. According to the eletrical datasheet the timing requirements are limited to 25 bit as I assume this is the maximum value (0..2^(25)-1) you can measure on this pin. Additionaly, the TRM refers sometimes to a 32 Bit capture capability when using the HR structure although the description says when HR is activated the only difference you can see is that the measured values are updated after the HR delay (HR active) or at the end of the loop resolution (HR not active). But I don't see any Bit increase which will allow me to use a value range of [0..2^(32)-1] for the PCNT instruction. Furthermore the electical datasheet speaks about several N2HET pins which support such 32-Bit feature.

So I don't understand how to deal with that "issue" when you refer to the "capability of 32 Bit capture" ? Does the application engineer need to apply some additional calculation when reading the data field in order to have an valid 32 Bit capture value? Or did I get something wrong with this and a 25 bit value is the maximum you can measure for a PCNT instruction, depending on your current (hr) and (lr )settings?

How can I use that feature and what needs to be prepared when the C-application is reading the PCNT.data field as most of the time the first byte is shifted out because most instructions refer only to a 25 bit data field?

  • 0
    TI__Mastermind 49120 points

    Hello,

    The High-End Timer time base is made up of two separate clocks with different resolutions. The high-resolution (HR) clock is divided down from VCLK2 and the loop-resolution (LR) clock is further divided down from the HR clock. The 32-bit data field of the PCNT instruction (and others) is made up of 25 bits of loop-resolution counts and 7 bits of high-resolution counts.

    This is explained in the TRM SPNU503c in section 20.2.3.2 on page 802 in the chapter on High-End Timer.

    The input timing constraints specified in the datasheet limit on the input signal pulse width and period for it to be measured correctly. Some input channels have an enhanced input timing capture ability, so that the minimum input pulse widths and periods for these channels are shorter than those for the other channels.

    Hope this helps.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 620 points

    Hello Sunil,

    I have read that chapter again together with the example pdf (spraba0b) in order to get a better understanding. For me I am still hanging on the same spot. In the end you cannot extend the limitation of 25 Bits for the maximum timing constraint for the input capture as it is specified to be (2^25) *hr*lr*tclk in both scenarios (loop resolution and high resolution) (Table 20.7, Table 20.8 - TRM). The high resolution structure only allows you increase the accuracy moving the lower threshold value for the electrical specification from [2*(lr)*(hr)*tclk] to [(lr)*(hr)*tclk].

    Is that assumption correct?

    Anyhow, when I enable the HR structure on the PCNT instruction with a loop resolution divide ratio (lr) set to 128, all 7 bits (LSB for the HR structure) in the PCNT.data field become valid.

    When the C application is reading that data field, how should you deal with a PCNT.data field which contains the max value for 32 bits (= 0xFFFFFFFF)?

    When converting it into a valid value with a timing unit as I assume I cannot just take the 32 Bit value and mulitply it with (hr)*(lr)*tclk

    (0xFFFFFFFF * ((hr)*(lr)*tclk) ) as you will violate/bypass the maximum timing speification which is (hr)*(lr)*(2^(25))*tclk.

    Is that assumption correct and how to convert it correctly?

  • 0 in reply to Mux
    TI__Mastermind 49120 points

    Yes, that is correct. Based on your configuration, there are 128 HR periods in each LR period. The lower 7 bits of the data field give you the number of HR periods while the upper 25 bits give you the number of LR periods for an input capture instruction such as PCNT.

    So the time calculation will be (PCNT.data & 0x3F) * hr * tclk + (PCNT.data >> 25) * hr * lr * tclk

  • 0 in reply to Sunil Oak
    Intellectual 620 points

    Hello Sunil, 

    thanks for the clarification. Just one small question regarding the mathematical expression for the second part.

    The upper 25 bits [31D : 7D] of the data field (32 bits ) contain the numbr of LR periods for an input capture, so it needs to be right-shifted 7 bits, but your expression is right-shifting it 25 bits 

    I assume it was a typo, so it should be : ((PCNT.data & 0x3F) * hr * tclk + (PCNT.data >> 7) * hr * lr * tclk)

    Is that correct?

  • 0 in reply to Mux
    TI__Mastermind 49120 points

    Yes, that is correct. Thanks for catching the mistake.

    Regards, Sunil