• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 676 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.

PGA305: OWI Communications and PGA305 Operation/Configuration Questions

James Walker3
Prodigy 30 points
Part Number: PGA305
Other Parts Discussed in Thread: PGA300, PGA900

We are trying to create a calibration system for the PGA305 using OWI communications.  I have been using a scope/bus analyzer to capture the communication using your PGA305EVM module and GUI software and have a number of questions.

1.    With your software, the OWI activation pulse sequence appears to be: three 10mS pulses with 10mS in between each pulse (this matches the datasheet requirement of figure 8), followed by 110mS of no pulses (this matches the datasheet requirement of figure 8), followed by three 10mS pulses with 10mS in between each pulse (this does not match the datasheet requirement of figure 8 [100 ms<time<200 ms]).  Should we follow the datasheet or your software?
2.    Your datasheet states “If the EEPROM is locked, the sequence 0x5555 must be sent within 100 ms after the end of the activation-pulse sequence”.  When your software sends an unlock EEPROM sequence it is 0x55 0x01 0x08 0x55 0x55 0x01 0x09 0x55.
2A    Since the sync field is 0x55 and the unlock sequence is 0x5555 I am not clear what is being written.  Can you clarify what needs to be written?
2B    If the second byte is the command field, it is 0x01 which according to the datasheet (table 4) is a write to a reserved page.  Can you provide information on what this reserved page is?
3.    With your software, OWI activation process reads a reserved memory page (0x55 0x02 0x0C 0x55 0x73 [response 0x03]).  Is this necessary and if so what does it read?
4.    Table 4 has a value of 0x07 being used to access Control and status registers, DI_PAGE_ADDRESS=0x07.  I cannot find anything else in the datasheet that refers to DI_PAGE_ADDRESS=0x07.  Is this a mistake in the datasheet?
5.    I thought perhaps the DI_PAGE_ADDRESS=0x07 was really DI_PAGE_ADDRESS=0x05 since table 4 does not state how to select DI_PAGE_ADDRESS=0x05, but the software seems to read/write to the EEPROM cache (read=0x52) with an address higher than the 0x7F of the EEPROM when accessing DI_PAGE_ADDRESS=0x05.  Is the EEPROM cache the same as DI_PAGE_ADDRESS=0x05?
6.    When your software writes the DAC codes as part of the DAC calibration it seems to step the codes up to the final DAC value.  Is this to prevent a power drop that could cause a reset of the PGA305?
7.    Figure 21 has ADDRESS[3:0] but is only an 8 byte cache. Should this be ADDRESS[2:0]?
8.    Section 7.3.12.3.2.1 states data field 1 is the destination address which has 8-bits.  Are only the lower 3 bits valid when writing to the EEPROM cache (command 0x51)?  Does this then become DI_PAGE_ADDRESS=0x05 when the destination address is greater than 0x7F?

Thank you for your assistance.
James

  • 0
    TI__Mastermind 31655 points

    Hello James,

    1. The datasheet requirement will work, but I'm unsure in this case why the GUI was programmed to operate in that way. It does reliably activate the OWI, so if you would prefer to use the shorter method that the GUI employs, that would work as well.

    2. The GUI for the PGA305 is a slightly modified version of the same GUI used for both the PGA900 and PGA300 which are part of the same device family. There are some commands included that are not necessary for the PGA305's operation, but are there due to their function with the other devices (mostly the PGA900). I agree that to avoid confusion the additional commands should have been left out. They are not necessary for proper communication with the PGA305, and they do not need to be replicated in your setup. The datasheet commands are sufficient.

    3. The register read from the reserved memory page is not necessary.

    4. It is a mistake and will be updated in the next datasheet revision. Page address 0x07 does not contain user accessible registers.

    5. Yes, page address 0x05 is used for the EEPROM cache access.

    6. An immediate change from a 0 to full scale output should not cause any issues with the PGA305, but the incremental output change was just included in the GUI as an additional protection. 

    7. The cache itself is only 8 bytes, which corresponds to the size of one of the EEPROM pages. There are 16 pages of EEPROM (each 8 bytes in size), so there are 4 bits to select the EEPROM page address.

    8. For an OWI write to the EEPROM cache (single write command 0x51 like you mentioned), only the lower 3 bits would be needed to select the address within the EEPROM cache. I'm not sure I entirely understand the last part to this question. If writing to the EEPROM cache, the command field will always use the DI page address for the EEPROM cache (0x05) inserted into P2-P0. Since the EEPROM cache is only 8 bytes, the destination address will always be between 0x07-0x00.The simplest way to read and write to the cache, however is to use the burst read and write commands, although I can understand that may not be desirable if speed is a factor.

    Regards,

  • 0 in reply to Scott Cummins
    Prodigy 30 points

    Hi Scott,

    1.    Thank you.  Since it will be simpler to use the same pulse sequence at the start and end of the activation sequence so that is probably what we will do.
    2.    I don’t understand.  The datasheet for the PGA305 states that “If the EEPROM is locked, the sequence 0x5555 must be sent within 100 ms after the end of the activation-pulse sequence.”  I assumed that this meant a two byte 0x55 0x55 sequence must be sent.  Looking more closely at the transmitted data (0x55 0x01 0x08 0x55 0x55 0x01 0x09 0x55) it looks as if a 0x55 is being written to reserved page 0, offset 8 and 9.  Is this the sequence to unlock the EEPROM?  If not what is the sequence to unlock the EEPROM?
    3.    After looking more closely at your datasheet and GUI it looks like this is the compensation control register (datasheet section 7.5.2.16).  After some experimenting it appears that writing a 0 to this register resets the IC restoring normal operation.  I would suggest that the entry in table 4 be changed from “reserved” to “Control and status registers, DI_PAGE_ADDRESS=0x00”
    4.    Thank you.
    5.    I think I’ve figured this out.  The EEPROM cache starts at offset 0x80.  To write to the cache byte 0 would be <sync>0x51 0x80 <data byte>.  To write to other page 5 status and control registers, <sync>0x51 <DI Page Offset><data byte>.  Reading the EEPROM is done with offsets below 0x80 with “offset” being rephrased as “fetch addresses”.
    6.    Thank you.  I am seeing resets when jumping from OWI current level (about 2mA) to about 17mA but this may be from additional loop resistance in our circuit design for IS approval.  I think we will have to step the current up the same way your GUI does to calibrate the DAC.
    7.    Thank you.  You are saying [2:0] is EEPROM cache and the additional bit is for other page 5 status and control registers.  But if I understand how the IC works these address bits are transparent to the read write sequences.  I simply need to start at offset 0x80.
    8.    I think the reason you don’t understand my question is that I didn’t understand the ICs operation (and may still not completely understand).  Let me restate my new understanding of the operation and you can tell me if it is correct.  The EEPROM reads are not from the EEPROM cache (as table 4 suggests) but from DI_PAGE_ADDRESS=5 with a fetch address of less than 0x80.  This is setup with a read initialization command of 0x52, then triggered with a read –response command of 0x73.  Single byte EEPROM writes are probably not permissible to addresses of less than 0x80.  All single byte writes are to DI_PAGE_ADDRESS=5 with a destination address of 0x80 or greater using an OWI write command of 0x51.  I agree that burst read/writes are a better method but I’m trying to understand the single byte read/writes as well.

    Thank you for your response.  You have given me a much clearer understanding of the low level operation of this IC.

    Regards,
    James

  • 0 in reply to James Walker3
    TI__Mastermind 31655 points

    Hi James,

    2. The 0x55 0x55 sequence should not need to be written to any specific register. There simply needs to be a sequence of 16 alternating bits sent over OWI.

    3. Yes, that is my mistake, the Compensation Control register is actually the only accessible register on page 0x0. A read is not necessary for OWI activation, but you will need to write 0x03 to rest the compensation engine and to activate all of the digital interfaces for device configuration.

    5. That's correct.

    6. Ah, yes that is another application where the slower ramp can be helpful. In a system using OWI and the 4-20mA output mode it can be useful to slow down the output change to allow whatever additional resistance compensation you are using to respond so that OWI communication is not dropped.

    7. Actually I was misinterpreting Figure 21 myself. It is not showing the page address as I expected, but the addresses within the cache as you explained. There should only be 3 bits (starting at offset 0x80 as you mention). This is something I will have updated in the next datasheet revision as well, to show the cache address as [2:0]

    8. That's correct. The reads are done directly from the EEPROM using the commands you described. EEPROM writes are not allowed to the EEPROM directly (offsets under 0x80), they are only allowed to the cache.


    Regards,