NHET with 2 PCNT on the same pin

Stefan,
What you are describing should work according to our manual for the N2HET, but it's possible we've got something wrong in the description;  could also be some interaction with the HR prescaler being 45 since most of the time the N2HET is used with the HR prescaler /1 for maximum resolution.

If you are able to send your code or even just your HET code, we can try to reproduce the issue.

I assume there is a little more to your program (like the count instruction... )

Meantime, you can try as a 'workaround' using the HR Share feature.   To do this:

 a) Set bit 8 of HETHRSH register. 

 b) Change the pin # of your 2nd PCNT to be 'pin = 17' instead of pin = 16.

You could also set your 2nd PCNT to Hi-Res if you wish,  since in the HR sharing mode you make use of 2 of the hi-res counter structures to measure one pin (pin 16).      This works because in step b) you are telling the PCNT to use the Hi-Res counter normally associated with pin 17 which is a different hi-res counter than the one in your L00.  But in step a) you are telling the N2HET to mux the pin 16 input to the pin 17 hi-res counter.  So you have 2 hires counters looking at one pin this way.

Well, we have a quite complex N2HET design, which is using all the available N2HET pins and needs therefore also some cycles (timeslots) to completely execute within one LRP. As we do not have resolution requirements lower than the 500ns, we had to select 45 for hr and 4 for lr to have 180 timeslots on each N2HET unit.

I broke the design down to have only the 2 PCNT instructions as posted in the previous post.

We know about the HR share feature, but it is no workaround for us. As far as we understood pin 17 could not be used anymore in N2HET, even not by a only low resolution capable instruction.

Anyway, according to the LS3137 datasheet, N2HET2[17] has no HR counter. Can you confirm this?

Hi Stefan,

Stefan Steinmann said:

Well, we have a quite complex N2HET design, which is using all the available N2HET pins and needs therefore also some cycles (timeslots) to completely execute within one LRP. As we do not have resolution requirements lower than the 500ns, we had to select 45 for hr and 4 for lr to have 180 timeslots on each N2HET unit.

Ok I understand.   Still might ask for the experiment though from a debug standpoint. 

Stefan Steinmann said:

I broke the design down to have only the 2 PCNT instructions as posted in the previous post.

Ok understand you didn't want to post your whole code.   Did you actually test the 2 PCNT example though and catch it giving the jittery results you mentioned?  If this isn't known, then it is the first thing to try next.  Because there is always the possiblity of something going on in a large N2HET program where other instructions might be interacting in a way that's not obvious...

Stefan Steinmann said:

We know about the HR share feature, but it is no workaround for us. As far as we understood pin 17 could not be used anymore in N2HET, even not by a only low resolution capable instruction.

 This part is true, if you turn on HRSHARE then the odd pin can only be used as "GIO".

Stefan Steinmann said:

Anyway, according to the LS3137 datasheet, N2HET2[17] has no HR counter. Can you confirm this?

This would surprise me as the N2HET has hi-res on all pins.  We used to have some older parts with HET that did not but all the N2HET parts have had hi-res on all pins.   If our datasheet says otherwise, would you please let me know where so I can correct the problem?

Hi Anthony,

I can share the a dump of my N2HET RAM and all the N2HET registers. As described in my first post, there are only the 2 PCNT instructions in N2HET2 RAM. For this test, N2HET1 is not used at all.

At the input, I have a 10.8 kHz Signal, with a duty cycle of 48%. But this is not so important.

The high time shall be measured with high resolution (500ns steps), the period from falling to falling edge with low resolution. In a loop I plot every 5ms the measurements over a serial line:

As result we see that the high time (1st column), which should be in high resolution, toggles between 88 and 92, meaning between 44us and 46us. But there are also values with 89, meaning 44,5us. This gives me the impression that somehow the high resolution structure is used, but why is it toggling also to 92?

If I look to the period time (2nd column), which should be in low resolution only, the results toggle between 184 and 189, meaning 92us and 94,5us. Why can there by values of 500ns steps, which corresponds to the high resolution??? I expect only values to the in the multiple of 4, meaning multiple of 2us.

According to the TRM (spnu499b, section 20.2.5.4) the first instruction should lock out the hr structure for other instructions of the current loop resolution period:

When I use only 1 PCNT instruction with high resolution and measure the high time, the result is that what I expect:

The measured high time in 500ns steps (1/2 us units) is toggling between 89 and 88, meaning between 44,5us and 44us. This is exactly what I expect.

Here is the N2HET2 config:

Regarding the point that not all N2HET pins have a high resolution counter (see spns162b, section 5.4.1 and table 5-13):

But N2HET2[17] even does not exist on the LS3137 device. E.g N2HET2[18] has no hr structure according to this table.

Hi,

any news on this topic?

Is somebody trying to reproduce it?

Are some additional informations needed?

thanks and regards,

Stefan

Stefan,

Sorry, I'm out of the office this week w.o. hardware.   I'll see if I can deduce something from your post though.

Hi Stefan,

I have a question on the duty cycle behavior.

could the duty cycle that you are trying measure be less than or equal to 2 us? .

This is your setup:VCLK2 = 90MHz
hr = 45, lr = 4
-> HRP = 500ns
-> LRP = 2us

Henry,

I think Stefan mentioned that the duty cycle was fixed to 50% so it should be very far from the minimum 4 us.

Do you know if the lower Hi-Res bits of PCNT are defined when the instruction is configured for loop-res.

I am wondering if this is just a case where you'd expect to read 00 there but really don't always and the result needs to be masked off.

Stefan,

If you were to zero out the bits 6:1 of the result, would your result make sense?

Stefan,

I see the table you're referring to where N2HET[17] isn't listed. 

That's not really what the table was intended to inform you about but I can see where it's confusing and we'll need to do something to clarify.   This particular table was meant to inform you which pins have the limitation of duty cycle > 2LRP and which were 'fixed' on the TMS570LS3137.  This was a late find and not all the pins could be ECO'd for this part.   So only a subset were.  

Still N2HET[17] is availalble for use as XORSHARE and HRSHARE and the table should actually give the status of it's input structure regardless of whether or not it has an IO pin becuase you might use it together with N2HET[16]..  

Anthony F. Seely said:

Stefan,

If you were to zero out the bits 6:1 of the result, would your result make sense?

For the loop resolution measurement (period) this could be a workaround. Our jitter than would be 1LSB (2us), which is fine. If the high res bits are also mapped when measuring only with loop res, this needs to be documented somewhere. Anyway, when both are measuring with loop resolution, this didn't appear. Is in such a case the hr counter never triggered to count something and therefore still on its initial value of 0?

But the initial problem, that the high res measurement (duty cycle) jitters more than only a few hr LSB (500ns) is still open. 

Anthony F. Seely said:

Still N2HET[17] is availalble for use as XORSHARE and HRSHARE and the table should actually give the status of it's input structure regardless of whether or not it has an IO pin becuase you might use it together with N2HET[16].

Ok, what is still unclear to me if all N2HET pins have a high resolution structure or only those listed in the table to support 32-bit capture.

Stefan,

Yes, the table is trying to explain something that could be tricky to understand.

All of the pins on the N2HET have a high resolution structure,  have 32-bit capture capability, and are capable of measuring some class of waveforms to this 'hr' resolution.

You might also expect that there are restrictions on how fast the input can change, if there are too many toggles too quickly on a pin this might overrun the capture capability of the timer / CPU.

Now, there are two different sets of input timings in the datasheet for the N2HET input capture instructions.  Table 5-11 is a set of constraints that will work with all pins.    Table 5-12 is a set of constraints that allows for 'smaller' features to be seen by those pins with a YES in the 2nd column "Enhanced Pulse Capture".   There should only be 6 of these with a YES.

Table 5-11 should be saying (although probably isn't clear enough) that for any pin the minimum pulse period needs to be greater than 2 loop resolution clocks plus 2 VCLK2 clocks.   And each phase of this signal must be greater than 1 loop resolution clock plus 2 VCLK2 cycles.

The N2HET is a little different here than what you might expect from a hardware counter based timer - for the N2HET if you are doing a period measurement,  even if the period is say 100 loop resolution periods long,   if either the high or low phase of the signal falls below 1 loop resolution clock period the N2HET might miss the entire measurement.   So let's say the duty cycle were 99.99% on a 100 loop resolution period clock.   Even if the 0.01% remainder is several VCLK2 clocks wide, where you might expect that the N2HET *could* capture the input reliably - due to the way that it is designed it won't always do so.   

The 2nd table 5-12 says that for 6 of the pins we have corrected this limitation, or at least reduced it to something you might expect.       For the 6 pins with the fix,  the minimum period that can be measured is 1 loop resolution clock plus 2 VCLK2 cycles and the minimum pulse width high or low is 2 hr clocks plus 2 VCLK2 clocks.

It all boils down to the edge detection circuit.  For the pins without the fix, even though capture is done at hi-res, the edge detection was done at loop resolution.   This combination leads to poor results when the pulse high or pulse low period is less than a single loop resolution period;   as the hi-res hardware counter will generally 'see' the edge and update, but the loop resolution structure that is evaluated when the instruction executes may or may not see the edge.  If it doesn't see the edge, then not only is it going to miss the edge (so you might next get a measurement that is 2 periods instead of 1 period) but since the missed edge at loop resolution was still 'seen' by the high-res counter, the high res counter would be 'upset' and the 2-period measurement that you might get next would also have a large error - possibly the entire hi-res remainder.

The LS3137 has 6 pins with a 'fix' to this limitation.   The LS1227 and newer parts have this limitation corrected on all the N2HET pins.

Ok, so this still doesn't address the jitter problem or your question about why the LSBs don't read 0 for the loop-res PCNT.

I don't have a good answer for you yet on those questions.   However, where do we stand again on the preferred method of using two pins N2HET[16] and N2HET[17] in the HRSHARE mode to overcome the issue you're seeing?  Is this feasible given the answer above, or were you already using N2HET[17] as another function that needs timer support so it's not feasible?

 PS: regarding your comment "If the high res bits are also mapped when measuring only with loop res, this needs to be documented somewhere. Anyway, when both are measuring with loop resolution, this didn't appear. Is in such a case the hr counter never triggered to count something and therefore still on its initial value of 0?"   Yes I agree we need to resolve this and get it documented.  I probably need to attempt to recreate what you see and then analyze further though.  So if in the meantime we can get you going by HRSHARE this will be better I think as the analysis could take some time.

Anthony F. Seely said:

All of the pins on the N2HET have a high resolution structure,  have 32-bit capture capability, and are capable of measuring some clas

So, really every pin of the LS3137 has the high resolution structure? What is then the difference between hr and '32-bit capture capability'?

Anthony F. Seely said:

You might also expect that there are restrictions on how fast the input can change, if there are too many toggles too quickly on a pin this might overrun the capture capability of the timer / CPU.

Now, there are two different sets of input timings in the datasheet for the N2HET input capture instructions.  Table 5-11 is a set of constraints that will work with all pins.    Table 5-12 is a set of constraints that allows for 'smaller' features to be seen by those pins with a YES in the 2nd column "Enhanced Pulse Capture".   There should only be 6 of these with a YES.

Table 5-11 should be saying (although probably isn't clear enough) that for any pin the minimum pulse period needs to be greater than 2 loop resolution clocks plus 2 VCLK2 clocks.   And each phase of this signal must be greater than 1 loop resolution clock plus 2 VCLK2 cycles.

The N2HET is a little different here than what you might expect from a hardware counter based timer - for the N2HET if you are doing a period measurement,  even if the period is say 100 loop resolution periods long,   if either the high or low phase of the signal falls below 1 loop resolution clock period the N2HET might miss the entire measurement.   So let's say the duty cycle were 99.99% on a 100 loop resolution period clock.   Even if the 0.01% remainder is several VCLK2 clocks wide, where you might expect that the N2HET *could* capture the input reliably - due to the way that it is designed it won't always do so.   

The 2nd table 5-12 says that for 6 of the pins we have corrected this limitation, or at least reduced it to something you might expect.       For the 6 pins with the fix,  the minimum period that can be measured is 1 loop resolution clock plus 2 VCLK2 cycles and the minimum pulse width high or low is 2 hr clocks plus 2 VCLK2 clocks.

It all boils down to the edge detection circuit.  For the pins without the fix, even though capture is done at hi-res, the edge detection was done at loop resolution.   This combination leads to poor results when the pulse high or pulse low period is less than a single loop resolution period;   as the hi-res hardware counter will generally 'see' the edge and update, but the loop resolution structure that is evaluated when the instruction executes may or may not see the edge.  If it doesn't see the edge, then not only is it going to miss the edge (so you might next get a measurement that is 2 periods instead of 1 period) but since the missed edge at loop resolution was still 'seen' by the high-res counter, the high res counter would be 'upset' and the 2-period measurement that you might get next would also have a large error - possibly the entire hi-res remainder.

The LS3137 has 6 pins with a 'fix' to this limitation.   The LS1227 and newer parts have this limitation corrected on all the N2HET pins.

Ok, this is clear. Anyway such short signals will not appear in our system. To ensure this we activate the suppression filters.

Anthony F. Seely said:

I don't have a good answer for you yet on those questions.   However, where do we stand again on the preferred method of using two pins N2HET[16] and N2HET[17] in the HRSHARE mode to overcome the issue you're seeing?  Is this feasible given the answer above, or were you already using N2HET[17] as another function that needs timer support so it's not feasible?

 PS: regarding your comment "If the high res bits are also mapped when measuring only with loop res, this needs to be documented somewhere. Anyway, when both are measuring with loop resolution, this didn't appear. Is in such a case the hr counter never triggered to count something and therefore still on its initial value of 0?"   Yes I agree we need to resolve this and get it documented.  I probably need to attempt to recreate what you see and then analyze further though.  So if in the meantime we can get you going by HRSHARE this will be better I think as the analysis could take some time.

Unfortunately the HRSHARE is no option for us. We have not only the N2HET2[16] pin where we measure with high resolution. We have exactly the same measurement on e.g. N2HET1[21]. As this one has an unequal number, we can not use the HR share. Anyway, also the pin before and after is already used (pin 20 and 22).

For now we will go with loop resolution only, but still waiting for an answer why this jitter occurs. 

thanks,

Stefan

Hi Stefan,

Stefan Steinmann said:

So, really every pin of the LS3137 has the high resolution structure? What is then the difference between hr and '32-bit capture capable

No difference.  This might have been a misguided attempt to avoid confusion by not using the term 'hi resolution' in the title becuase of the issue with the input period.   Really the resolution for both columns is an HR clock, but there are classes of input signals that will trick the pins without the fix and if tricked the measurement is completely in error - not just back to 'loop resolution'   Need to figure out how to word that better but that's why I think 'hr' wasn't in the column heading.

Stefan Steinmann said:

Unfortunately the HRSHARE is no option for us. We have not only the N2HET2[16] pin where we measure with high resolution. We have exactly the same measurement on e.g. N2HET1[21]. As this one has an unequal number, we can not use the HR share. Anyway, also the pin before and after is already used (pin 20 and 22).

Are you using pin N2HET1[17] though?   If not you can turn on HRSHARE for the pair 16/17.   The signal only needs to actually be wired to N2HET1[16] for this to work.

Stefan Steinmann said:

For now we will go with loop resolution only, but still waiting for an answer why this jitter occurs. 

Agree.

Anthony F. Seely said:

Are you using pin N2HET1[17] though?   If not you can turn on HRSHARE for the pair 16/17.   The signal only needs to actually be wired to N2HET1[16] for this to work.

Just to confirm that the HR share feature would solve the jitter problem I tested it today, and it works as expected. No jitter.

But as said in previous posts we still would like to measure only 1 part with hr, the other with lr. Otherwise we have not enough N2HET pins. 

Stefan,

I was able to create a test case that reproduces the issue you've reported.  I see a similar result.

1) 2 PCNT instructions both on pin 16.   Guarded by conditional branch so that either 1 or both can be skipped.

   1st is set for hr duty cycle measurement,  2nd for lr period measurement

2) Input is a 500us, 250us pulse generated by HET2 to pin 16

3) With only the 1st PCNT enabled I get a distribution of values (min, max) for the 1st PCNT of  0x6D0 - 0x6D8.

4) After turning on the 2nd PCNT,  the distribution of the 1st PCNT (min,max) increases to 0x698 - 0x720

I don't exactly understand either of these results, because the result in 3 seems to be +/-1 LR not +/-1HR.

But without understanding the issue clearly, I do see that simply turning on the 2nd PCNT does widen the jitter on the 1st.

Will submit this for analysis, but I think you've found something real and so probably will need to juggle pins (even though you don't have any spare) or make some tradeoff.

Hi Anthony,

thank you very much for this feedback. Well, I was quite sure that there has to be something real. Our tradeoff will probably be to use loop resolution only, if there will be really no other workaround.

Stefan,

We have created an internal ticket on this issue and our design verification team is now looking at the code we provided to reproduce the problem.  This is the first step towards analyzing the root cause of the problem.   We have had a first kickoff call to discuss the issue and I think some analysis has been done but I was out of office last week and have not yet sync'd up this week.   I think we need to get a little feedback (i.e. has the problem been reproduced on an enviroment with enough visiblity to debug further) before projecting how long it will take to complete the analysis.

Note: I have been able to produce the problem with both the hr_lr PCNT first, and also second in execution order.  So I am not optimistic about a workaround based on ordering.   I would suggest you proceed with 2x 'lr' PCNT as you mentioned earlier.

Hi Anthony,

thank you for the feedback. Please still keep us informed about any further details on this topic.

br

Stefan