Counter not always handling capture

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
WaMa_286156
Level 5
Level 5
First comment on blog 100 replies posted 50 replies posted

 I'm working on a project, R/C control of a device, non disclosure and such.  I'm giving as much info as I can.

   

 The transmitter/receiver pair turn joystick position into a pulse that measures approximately 1 millisecond to 2 milliseconds in width (hard stop to hard stop).

   

 I am using an up counter in one shot mode, with rising edge enabling the counter through a FF, and a capture triggered by the falling edge through an inverter (not).  I am interrupting on capture.  I have 6 of these, in total using 79.2% of the UDB resources,for  2 sars, 2 lookup tables (LUT), 8 counters, some clocks, etc.

   

  The circuit fragment giving me the problem is attached as a .png.  It is under PSOC Creator 4.0.

   

  This works most of the time.  Sometimes the capture never triggers.  I have an ISR on the terminal count and it always triggers at the terminal count.  (I use pins for debug output, 100mhz oscilloscope and a cheap Saleae logic analyzer to prove the issue.)

   

  I was getting a timing violation warning with 24mhz clock into the counter clock, but I dropped that to 12 mhz and the violation went away. The AC characteristics datasheet says it can do 33mhz, but PSOC Creator 4.0 does not believe the data sheet. (Note: the PNG shows 24mhz as I have not yet re-labeled the wire.)

   

This turns out to not be an issue, because I don't use the bogus value due to not having received it through an interrupt.  I can't share the project, but the circuit is simple enough.  However, it is annoying, and either points directly in my face, or to possible underlying issues with the verilog compiler/placer.

   

Any suggestions as to a fix?   During my debugging sessions *sometimes* adding an output pin to the input net fixed the problem, but that was when I was getting timing violations.  Now it makes no difference.

0 Likes
1 Solution
odissey1
Level 9
Level 9
First comment on KBA 1000 replies posted 750 replies posted
        wsm, Having bus clock violation at less than 24MHz means that design is really overloaded. The UDB saturation at -80% indicates that almost all "unique P-terms" are used (it will never reach 100%), which means that there is a routing problem (not enough internal connections to route signals). In this situation fitter is trying to optimize the internal web of connections, it does not works well, and max. allowed bus frequency drops down. I observed that in such situations adding a pin may suddenly dramatically change entire routing and thus timing and signal integrity. So my thinking that optimizing (shrinking) design should alleviate the problem. Reducing bus clock works same direction. Both Counter interrupts will fire simultaneously. One isr should suffice. What matters is Counter settings and code inside isr resetting the Counter.   

View solution in original post

0 Likes
4 Replies
WaMa_286156
Level 5
Level 5
First comment on blog 100 replies posted 50 replies posted

 I just modeled the circuit only in CC3.0sp2, it worked.  I took the same circuit into 4.0 and it appears to be working there also,.

   

 I suspect that it gets to be a problem when the UDB is almost full.  I can live with it in this case.

0 Likes
odissey1
Level 9
Level 9
First comment on KBA 1000 replies posted 750 replies posted
        wsm, Having bus clock violation at less than 24MHz means that design is really overloaded. The UDB saturation at -80% indicates that almost all "unique P-terms" are used (it will never reach 100%), which means that there is a routing problem (not enough internal connections to route signals). In this situation fitter is trying to optimize the internal web of connections, it does not works well, and max. allowed bus frequency drops down. I observed that in such situations adding a pin may suddenly dramatically change entire routing and thus timing and signal integrity. So my thinking that optimizing (shrinking) design should alleviate the problem. Reducing bus clock works same direction. Both Counter interrupts will fire simultaneously. One isr should suffice. What matters is Counter settings and code inside isr resetting the Counter.   
0 Likes
WaMa_286156
Level 5
Level 5
First comment on blog 100 replies posted 50 replies posted

  Interesting.  I was thinking along the same lines, dropping a couple of counters for not-yet used channels.  I had not thought about dropping all of the individual isr's.  That is a good idea, I can make it work.

   

 Is there any documentation on determining when the design is saturated?  

   

  I had tried using a mux and a single counter, but I had trouble switching the signals, I may understand enough of the issues now to try that again.

0 Likes
AnkitaS_51
Employee
Employee
100 likes received 50 likes received 25 likes received

You can check the Resource Meter in Creator.

0 Likes