• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 63 subscribers
  • Views 353 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.

Inconsistent reading of CFG_Px_TRANSITION Registers

David Stewart
Prodigy 220 points
Other Parts Discussed in Thread: TPS65950

During the boot-up of our DM3730-based system with the TPS65950 companion chip, we are finding that the value read from CFG_Px_TRANSITION is different, depending on whether or not we first read the IDCODE. Why?

For example, here is a sequence of TPS reads. (Format of printout: "X@0xAAZZ :VV", X=R means Read, AA=I2C Address, ZZ=Register Address, VV=value read)

TPS R@0x4B36: 00  pmm_cfg_p1_transition
TPS R@0x4B39: 00  pmm_cfg_p123_transition
TPS R@0x4B00: 51  secured_reg_a
TPS R@0x4988: 10  idcode_31_24
TPS R@0x4B36: FF  pmm_cfg_p1_transition
TPS R@0x4B39: AB  pmm_cfg_p123_transition
TPS R@0x4B00: 00  secured_reg_a

I noticed the secured_reg_a register also changes. The highlighted values show the same register read twice successively. Reading idcode_31_24 is the line that makes the difference between whether or not we read 0x00 or 0xAB from that register.

Is this in any way related to ONNOFF vs POR Active modes? It seems like TRM lists registers twice, but says absolutely nothing about it. Is it possible there are two banks of registers? And if so, what is the correct way to switch between them? Reading IDCODE seems to trigger a transition, but I can't find any good reason why.

Thanks,

Dave

  • 0
    TI__Genius 15100 points

    Hi Dave,

    This shouldnt happen. I will have to see what I see on my bench. I doubt if it is due to reading IDCODE, reading any register doesnt change any internal status of other bits. I will let you know what I find out.

    Sorry for the delay on this.

  • 0 in reply to Gandhar Dighe
    Prodigy 220 points

     

    Gandhar,

    I found the problem over the weekend. There is a bug in the TWL driver of the Adeneo WinCE 6.0 BSP. It is a result of an improperly re-initialized variable in the Open routine.

     In TWLOpen() in the file twl_access.c,

     Change

    I2CSetSlaveAddress(Device.hI2C, BSPGetTritonSlaveAddress());

    To

          I2CSetSlaveAddress(Device.hI2C, BSPGetTritonSlaveAddress());

          Device.slaveAddress = BSPGetTritonSlaveAddress();

    Device.slaveAddress gets statically initialized. But because it is a static local variable, it only gets called first time TWLOpen() is called.

    The problem would occur anytime you called TWLClose() then TWLOpen() (could be from different threads), and the first address you requested after TWLOpen() was neither the last setting of the slave address before the close nor the default setting. When a read or write is performed, the driver would use the saved slave address thinking it already had the right value saved. So although I2C address 0x4B was requested, 0x48 ended up on the bus, so the wrong register was being written. The moment you read from a different slave address (in this case the IDCODE happened to be on a different address), the problem would rectify itself. Most functions would call TWLOpen(), do what it needs to, then call TWLClose(), and thus many opportunities for the bug to rear its head.

    Note that this bug could have sparse but far reaching random effects in other stuff that use this driver.

    Thanks for looking into this.

    Dave

  • 0 in reply to David Stewart
    TI__Genius 15100 points

    Hi Dave,

    I am not a sw person and hence some silly questions -

    Does that mean the Adeneo took the Linux drivers from the open community and modified these? And their drivers have a problem?

    I want to know if the open community has the correct code. As you said the problem can be very random and I want to be sure this is not the case. I am hoping the code in the main Linux tree is good, else by now I would have seen lot of issues.

  • 0 in reply to Gandhar Dighe
    Prodigy 220 points

    Gandhar,

    I do not know the origin or history of that driver. But if you post or email the "Open" function of the Linux driver, I can probably tell you with a glance if the problem exists there too.

    Dave