• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 554 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.

TLV320AIC3107 : Setting PLL_Enable or MICBIAS disables future I2C R/W

Donald Bosley
Prodigy 180 points

As a safety for prototyping I have been using reads to verify that what I'm writing into my registers via I2C matches with the original reset value, and that my new write was successful. 

1. The first strange behavior is that Page 0, Register 25 (0x19) MICBIAS, returns a 0x02, not a 0x00 after reset. I also noticed that when I try to write or read to this register in particular something is happening that causes it to look for two-byte messages for data, versus the single byte I've been writing to everything else. Once I write a legal sequence to MICBIAS, it gives me a voltage as desired, but I lose my I2C. 

2.I also lose my I2C anytime I write a one to the PLL_Enable bit Page 0, 0x03. 

3. I understand that page 0, registers 5&6 require a sequential write, and there are cases of this with registers relating to page 1.  Looking at the command line interface of the EVM software in DEMO mode (I don't have an eval-kit) I see that the PLL registers are all written sequentially as well i.e. "w 30 03 91 20 1E 00" - is this a requirement, or a convenience? 

Thanks. 

Add: is there a particular "order" or proper sequence to program the various registers, or is it OK to just do them in numerical order of the registers? 

  • 0
    TI__Genius 9410 points

    Hello Donald,

    Do you have access to a logic analyzer? I recommend starting with that to monitor the I2C lines and make sure that you are expected to send is actually happeneing. Though if you are getting correct data dumps this seems unlikely, but its a common thing that comes up so we always like to check this

    Also, do you get an I2C Bus error? (register 107 page 0 D0). What happens if you disable this (same register D2).

    In regards to number 3 the registers do not need to be programmed sequentially unless explicitly stated so that was done for convenience.

    Programming in order does actually matter, and is not always numerical order of the registers. I actually discuss how this affects issues and recommended order in this post: http://e2e.ti.com/support/data_converters/audio_converters/f/64/p/359906/1269666.aspx#1269666 

    I recommended following the order in the examples as closely as possible to avoid sequencing issues. If you do that and follow the above post you should be in good shape.

    Please let me know if this continues to be an issue,

    Nate

  • 0 in reply to Nate Enos
    Prodigy 180 points

    Do you have access to a logic analyzer? I recommend starting with that to monitor the I2C lines and make sure that you are expected to send is actually happeneing. Though if you are getting correct data dumps this seems unlikely, but its a common thing that comes up so we always like to check this

    ---> Everything is being verified using a scope and counting bits since I do not have access to a logic analyzer

    Also, do you get an I2C Bus error? (register 107 page 0 D0). What happens if you disable this (same register D2).

    ---> Atmel twi_status returns success for the transfer (write verified below), but no matter what happens the transfer is NACK result. There is no way I can read 0:107 D0 because I2C has failed/stopped

    Programming in order does actually matter, and is not always numerical order of the registers. I actually discuss how this affects issues and recommended order in this post:http://e2e.ti.com/support/data_converters/audio_converters/f/64/p/359906/1269666.aspx#1269666 

    I recommended following the order in the examples as closely as possible to avoid sequencing issues. If you do that and follow the above post you should be in good shape.

    ---> Can you please point me to these examples? There are no application notes that explicitly describe the programming sequence that I have found on this site, nor through google, and other than the Class D amplifier and RESET, the datasheet doesn't describe  this. The other post is nice, but there isn't anything about clocking, PLL, etc...

    ----> With nothing else written in after RESET, I converted this example sequence from EVM-DEMO software, 

    w 30 11 0F
    w 30 12 F0
    w 30 16 7C
    w 30 13 7C
    w 30 0F 00 ---> fails
    w 30 10 00 
    w 30 19 80

    ACTUAL SCOPED RESULTS OF WRITING 19 80 after reset ---->

    SDA Low, SCK Low;  0011 0000 ACK // Start Bit 0001 1001 ACK // Start 1000 0000 ACK // CLOCK w/SDA LOW // SCK High, SDA High

    Next attempt at doing anything on the I2C Bus results in an error

    Thanks.

  • 0 in reply to Donald Bosley
    TI__Genius 9410 points

    Hello Donald,

    Are you sure the Atmel chip is properly holding the reset pin low (at least 10 ns, pg 19 of datasheet: http://www.ti.com/lit/ds/symlink/tlv320aic3107.pdf) Ive seen this cause some sporatic I2C issues.

    Also can you confirm that all of the writes are meeting the timing requirements?

    The fact that the EVM example isn't working suggests a system level or hardware configuration issue.

    In regards to the examples, I was just refering to what Vitalii used for routing. You shouldn't run into any issues with setting the clocks and PLL. If you follow the order of the script setups in the GUI for the EVM DEMO you won't run into any issues.

    Please let me know if you continue to run into issues,

    Nate

  • 0 in reply to Nate Enos
    Prodigy 180 points

    We went ahead and bought the EVM-K, so we may be able to rule my break-out construction as the issue, because all of the timings appear acceptable per the data sheet.

  • 0 in reply to Donald Bosley
    Prodigy 180 points

    We bought the EVM-K. We hooked up the Atmel SAMG53. The reads and writes all seem to be working now, without the freezing / shut-down problems we had before, with the writes verified by a read and comparison. Except...

    Register 25 still reads 0x02 after proper reset. According to the datasheet it should be 0x00. When I write 0x80 into that register, then read out the result I get 0x82. 

    Is this detrimental to operation in any way and if so, any suggestions? I haven't tried to read/write every register so I have a feeling this isn't going to be the only one like this.

    Thanks.

  • 0 in reply to Donald Bosley
    TI__Genius 9410 points

    Donald,

    Glad to hear using the EVM helps isolate what is going on. Register 25 bits D2-D0 are actually don't care reset values, so this won't be an issue as long as you write zeros to the reserved bits.

    I apologize for the confusion,

    Nate