• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 19 subscribers
  • Views 1459 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

SN74LV8154: Counter counts only up to 16191

Holger Doering
Prodigy 40 points
Part Number: SN74LV8154

We tried to develop a frequency Counter with the SN74LV8154 and ATMEGA328.First we build a test circuit, where an ATMEGA, based on an Arduino nano board sends the clock pulses to the CLKA and CLKB-Pin of SN74LV8154 in order to increase the counter. After this we send a short clock pulse to RCLK to push the data from the registers in the buffer. Than we set GAL from HIGH to LOW and after this we read the data from Y0 – Y7. After reading we set GAL to HIGH again. In order to read the other bytes of the register, we proceed the same way with GAU, GBL and GBU.

It works, but the counter counts only up to 16191. That means if the Counter reaches 16191 it starts at zero again. We tried the also in a single mode, that means for Counter A and Counter B separately. We blocked VCC with 100nF and 10uF. We smooth the signal with resistors. We replaced 6 times the SN74LV8154 against a new chip. But the result is every time 16191.

We developed many logic circuits with counters, like CD4040, SN74HVT4024 or SN74161, but we didn’t saw these effects, like with the SN74LV8154. If anybody has developed a real circuit where the counter counts, like described in the datasheet, please give us a reply.



  • 0 in reply to Holger Doering
    TI__Mastermind 24795 points
    Hello,

    It should not be going back to zero when it reaches 16191 (0011 1111 0011 1111).
    If you clock in something larger than 16191, can you ever get the 15,16 bits to go high?
    Do you ever see where bits 7 and 8 are high, say when the count is 256 (or 255 referenced to 0)?

    It seems strange to me that the two bytes are exactly identical and I wonder if this is being read out correctly?

    I would maybe write the code to do something simple like count to a specific number larger than 16191.
    Can you also share a schematic of your setup?

    Best,
    Michael
  • 0 in reply to Michael J Schultis
    Prodigy 40 points

    Hello Michael,

    I agree the code is quick and dirty, but its only to test basics. Now I changed the write an read commmands into digitalWriteFast and digitalReadFast.  digitalWriteFast and digitalReadFast is copy and paste from a free library. It reduces the write and read times in order to prevent possible conflicts with the timing. If I run the code up to 2 hours I saw that the counter increases more the 16191 after 5 trials. It counts up to 2 million, before I stoppped it. But between the counting cycles every 4th counting result was wrong. I suppose the the SN74LV8154 has general power problems. In looks like microprocessors from the early 80th. If you switch on a neon light in a room, the processor jumped in a undeffined state. Therefore I am interessed on if this chip is already in place in circuit where exact measure is required. We like to use the counter in a RF-circuit where other components work up to 100MHz. In the environment we have many electromagentic dust, which we can't drop to zero.

    The schematic of the test circuit is attached.Counter.pdf

    Regards Holger 

        

  • 0 in reply to Holger Doering
    TI__Guru* 96681 points
    Hi Holger,
    Just to give you my $0.02 -- I know that there are currently millions of these devices in use today across hundreds (if not thousands) of electronics manufacturers (and have been for the last ~20 years), and this is the first incident of incorrect counting I have heard of. I won't completely discount the possibility of an error on our end (sometimes stuff happens), but I find it extremely unlikely that this device is counting incorrectly.

    This device is a very simple analog CMOS IC (no internal processor) and does not have any type of internal shielding. It wouldn't surprise me to learn that a large EM field could disrupt its function, but it's even more likely that the nearby CMOS microprocessor is being affected by the EM interference and is causing spurious/unpredictable outputs/inputs.

    I'm afraid I can't comment on the Arduino device's performance, but I would recommend looking carefully at the signals going into the SN74LV8154 to discover what is happening. In my experience, analog CMOS devices don't do anything on their own -- if the device seems to reset at 16191, then it is probably detecting a reset signal at 16191.
  • 0 in reply to Emrys Maier
    Prodigy 40 points

    Hi Emrys,

    currently we are checking possible causes in the micro controller. Now we find out that the Serial.println command has a big delay. By this it can be, the the old measure value is still in the transmission process to the terminal, without consideration of new measure values. I give a feedback, if we find out more.