I am trying to set up a proper I2C driver (none of the SMBus stuff will do), so following the path laid out in spru98c, CH18, section 1.5.
I'm doing my initial experiments in CCS3.3 (CCS4 is still flakey it seems).
Using I2C2.
I try to set the prescaler divisor to 8 by writing 7 to the register I2C_PSC at 0x48072030, but write fails, the register still contains 0.
I am using our own device connected via a Blackhawk USB560 JTAG emulator - have done plenty of similar stuff with other registers.
I also cannot change any I2C_PSC register from the debugger.
Does anyone have any idea what could be wrong?
/Paul
Did you see this note in the TRM:
"The I2Ci registers are limited to 16 bit and 8 bit data accesses, 32 bit dataaccess is not allowed and can corrupt register content."
The fact that 0x3FF is in both words sounds like perhaps the wrong size accesses are being performed.
Is that I2C device enabled through the PRCM and is the interface clock on?
Hi Brad, thanks for the speedy response.
I'm (blindly) following the instructions in spruf98c. That is to say I have enabled the F and I clocks for I2C2. I haven't got to the initialize part yet - it says first configure the module. I assumed that all the registers need to and can be set first. Is that right?
Are these the bits you configured:
CM_FLCKEN1_CORE[16]
CM_ICLKEN1_CORE[16]
If you open a memory window to the I2C registers do all of them show their default values? For example does I2C_SA = 0x000003FF?
So can you still not configure I2C_PSC? What happens when you write to it? Can you do it through a memory window?
Yes Brad, I set those bits, I2C_SA is 0x3FF, in both words actually. No, I can't write to I2C_PSC, and I can't change it in a memory window.
Oh dear, no, I did not see that, may explain things, but it is 00.30 h here so I'll look into it tomorrow. Thanks.
But I did not set the 0x3FF in I2C_SA, don't know how it got there, or set by the Linux kernel which I had booted up earlier.
The I2C_SA register has a hardware default of 0x000003FF, so it's expected to be that value rather than 0x03FF03FF which I believe was a result of a 32-bit access instead of a 16-bit access. That's probably the issue you're having with I2C_PSC as well.
Brad
Indeed Brad, using 16-bit access I am able to write I2C_PSC. The weird thing is that the follwoing code
uint16 set_bits_in_reg_16(uint32 areg, uint16 mask){//changed this so arg passed for reg is just a 32-bit int register uint16 u; register uint16* pReg; pReg = (uint16*)areg; u = *pReg; u |= mask; *pReg = u; return *pReg;}
writes the same value to the low and high words. I wonder how that can happen.
If I manually write in the memory window this not the case..
As noted, I2C_SA, contains 03FF 03FF but this is not my doing. Moreover I cannot change it from the memory window.
What is the underlying mechanism? Is it necessary to read and write back the upper word unchanged to be sure?
Now I also observed that even with byte access, writing to I2C_OA0 to set the I2C2 module's own 7-bit address, the same value gets written to the high word as well,
How are you reading back this data to verify? Are you using a memory window in CCS? If so, we should verify that the CCS memory map has been configured to define that space as 16-bit access only (if you're even using CCS). Have you tried using code that makes 16-bit accesses to read back the top and bottom half of the register?
I'm looking at the CCS Memory Window, set to 8-bit - Ti Style.
01.30 here , so continuing tomorrow
Are you using the omap3530_cortexA.gel file in your CCS configuration? If so, it defines the memory map like this for I2C:
GEL_MapAddStr(0x48070000, 0, 0x00001000, "R|W|AS2", 0); /* I2C1 - module (msi2cocp_func.doc)*/ GEL_MapAddStr(0x48071000, 0, 0x00001000, "R|W|AS2", 0); /* I2C1 - L4 interconnect */ GEL_MapAddStr(0x48072000, 0, 0x00001000, "R|W|AS2", 0); /* I2C2 - module (msi2cocp_func.doc)*/ GEL_MapAddStr(0x48073000, 0, 0x00001000, "R|W|AS2", 0); /* I2C2 - L4 interconnect */
The "AS2" means that the access width is 2 bytes, so even if you put the memory window as a 32-bit display it should still be doing 16-bit accesses. (Though on the flip side, if you're NOT using the gel file than regardless of the display size I think you might be getting 32-bit accesses. I'm not sure for that case.)
ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". TI AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY TI. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM TI.
Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.