• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 12 subscribers
  • Views 501 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.

GC4016 checksum problem

Marc S48146
Prodigy 85 points

Hello,

I have a GC4016 interfaced to a C5515 DSP through EMIF to configure the chip's registers.  I'm trying to get diagnostic test 1 to work where the checksum should be 0xEC.  I've verified that all of the global and paged registers are correct.  I've followed table 5-13 in the GC4016 datasheet to program all of the registers for diagnostic test 1.  After configuration, the code goes back to all of the global and paged registers to print out the contents.  All of the values match with the table.  The code also waits for the checksum to be stable and then prints out the checksum values over multiple iterations.  Instead of the steady checksum, I get random, changing checksum values.  Below is a sample print out of the checksum over multiple read iterations.  We have a 24 MHz clock going into the chip. 

On another note, we had a past project that used a C5509A to interface to the GC4016 and got the expected 0xEC checksum.  I've compared the register settings between the C5509A and C5515 and both match.

Has anyone ever seen this kind of behavior with the GC4016?  Any ideas on what could be causing this?  Thank you very much for any advice.


GC4016: 0) CHECKSUM = 0xae
GC4016: 1) CHECKSUM = 0x1d
GC4016: 2) CHECKSUM = 0xa9
GC4016: 3) CHECKSUM = 0x80
GC4016: 4) CHECKSUM = 0x7b
GC4016: 5) CHECKSUM = 0x03
GC4016: 6) CHECKSUM = 0x47
GC4016: 7) CHECKSUM = 0xce
GC4016: 8) CHECKSUM = 0x27
GC4016: 9) CHECKSUM = 0x9f
GC4016: 10) CHECKSUM = 0xab
GC4016: 11) CHECKSUM = 0xa2
GC4016: 12) CHECKSUM = 0xe3
GC4016: 13) CHECKSUM = 0x7c
GC4016: 14) CHECKSUM = 0x5d
GC4016: 15) CHECKSUM = 0xa7




  • 0
    TI__Mastermind 37500 points

    Hello,

    The GC4016 checksum test injects a set of values at the input port, goes through the Mixer, CIC, CFIR, PFIR, Resampler, and Output block, and compares the results

    of the Syndrome check with the value in the datasheet.  The checksum value should be stable, and ideally the correct value.  Since the checksum test passing relies on the following items:

        a) register values programmed are correct

        b) device is not in JTAG mode (which is tested by reading registers back)

        c) device has proper power supply voltages - measure the core and pad voltage for rms value, and ripple and noise

        d) device has a clean CK clock at the appropriate rate, CMOS levels.  The Clock should have terminations, and not have ringing especially around the LVTTL threshold.

             DVAL(inv) pin is grounded

    There is a general purpose counter described on page 51 of the datasheet , sets the counter to create a terminal count every (CNT+1)*256.  You can calculate the number of clock pulses that should cause a terminal count 1->0->1 change on the sync output pin.  Output Sync must be set to 5.  If you calculate the Sync Output period, and it is correct and stable the CK is OK. 

    Looking at the CK pin on an oscilloscope can help to determine that the signal meets the AC requirements for the clock for risetime, falltime, duty cycle, and voltage level.

    Regards,

    Radio Joe

     

     

  • 0 in reply to Radio-Joe
    Prodigy 85 points

    Radio Joe,

    Thank you very, very much for your detailed response.  It turns out the random checksum was caused by a bad clock, as you suggested.  There was significant ringing in the clock to the GC4016, which was caused by an oscillating power supply to the clock generator.  After cleaning that up, we got the correct checksum for multiple diagnostic tests.  Thanks again!

    Regards,

    Marc