Since I had an I2C address conflict on LogicPD EVM I was forced to switch to I2C1 interface on OMAP L138 (code runs on DSP). As I can see, this interface does not work. After starting bus activitiy by setting start bit in ICMDR, I observed the follwing:
The driver I have programmed works on I2C0. To run it on I2C1 I did the following changes:
I also have attached a TMS320C6748 SOM to the baseboard to run the same code on it and it worked perfectly! So this seems to be a silicon bug to me. To prove that I attached a 2nd OMAP SOM to the baseboard and observed the same problems.
Any ideas or is there a workaround?
Thanks in advance.
Roland
Hi Roland,
Are you saying the same code works when you drop a C6748 SOM, but not when you drop in a OMAPL138 part? If that's the case, I would first check on logicPD website to make sure the SOM and baseboard are compatible. You also need to make sure you OMAPL138 SOM is not damaged. =)
regards,
Paul
PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question. Thanks!
Hi Paul,
that's true, C6748 SOM works, OMAPL138 does not (with identical code). Following your recommendation I came to these results:
After all, to me it seems that OMAP I2C is not working. When I attach a logic analyzer to the SDA and SCKL wires, I can see bus activity (start bit) but it stops before slave address appears. On the baseboard the were a RS232 transceiver attached to the I2C1 pin, but I removed it prior to my checks. SOM has no I2C slaves on I2C1, so my 2 external I2C devices are the onlöy slaves that are attached to I2C1.
Any other ideas?
Regards,
Roland,
This is really weird. Is there a simple testcase that you can send it to me to quick test it out locally? Preferablly with a failure/pass checking mechanism.
Paul,
sorry I'm not allowed to post an example. If you send me your email address to my registered email address, I'll send you a reduced and modified code that shows the effect.
What's the ARM core doing while you're running this code on the DSP? Are you sure it's not running Linux and perhaps getting in the way?
What's the SCL frequency for the little bit of activity that you're seeing? Please dump the I2C registers just before you kick off the transaction and just after it fails.
---------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.---------------------------------------------------------------------------------------------------------
Hi Brad,
I assume this issue is still unresolved? After you've unsuccessfully attempted to run your code, can you load this gel file and do the "Run All" script:
http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files
Please paste the results into a txt file and attach to a reply.
Thanks,Brad
here is the output:
C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: | Device Information |C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: DEV_INFO_00 = 0x1B7D102FC674X_0: GEL Output: DEV_INFO_01 = 0x00000000C674X_0: GEL Output: DEV_INFO_02 = 0x0000000CC674X_0: GEL Output: DEV_INFO_03 = 0x00000032C674X_0: GEL Output: DEV_INFO_04 = 0x00000000C674X_0: GEL Output: DEV_INFO_05 = 0x000003E0C674X_0: GEL Output: DEV_INFO_06 = 0x08000200C674X_0: GEL Output: DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 0-0-5929125-14-48-26C674X_0: GEL Output: DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 2,0,0,10514C674X_0: GEL Output: -----C674X_0: GEL Output: DEV_INFO_17 = 0x00030003C674X_0: GEL Output: DEV_INFO_18 = 0x00000000C674X_0: GEL Output: DEV_INFO_19 =C674X_0: GEL Output: 0C674X_0: GEL Output: 0C674X_0: GEL Output: 0C674X_0: GEL Output: 0C674X_0: GEL Output: 0C674X_0: GEL Output: C674X_0: GEL Output: -----C674X_0: GEL Output: DEV_INFO_20 = 0x30303864C674X_0: GEL Output: DEV_INFO_21 = 0x3630306BC674X_0: GEL Output: DEV_INFO_22 = 0x00000000C674X_0: GEL Output: DEV_INFO_23 = 0x00000000C674X_0: GEL Output: -----C674X_0: GEL Output: DEV_INFO_24 = 0x0E01A030C674X_0: GEL Output: DEV_INFO_25 = 0x005A78A5C674X_0: GEL Output: DEV_INFO_06 = 0x08000200C674X_0: GEL Output: DEV_INFO_26 = 0x52240002C674X_0: GEL Output: C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: | BOOTROM Info |C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: ROM ID: d800k006 C674X_0: GEL Output: Silicon Revision 2.0C674X_0: GEL Output: Boot pins: 12C674X_0: GEL Output: Boot Mode: SPI1 FlashC674X_0: GEL Output: ROM Status Code: 0x00000000 Description:C674X_0: GEL Output: No errorC674X_0: GEL Output: Program Counter (PC) = 0xC316194CC674X_0: GEL Output: C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: | Clock Information |C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: C674X_0: GEL Output: PLLs configured to utilize crystal.C674X_0: GEL Output: ASYNC3 = PLL0_SYSCLK2C674X_0: GEL Output: C674X_0: GEL Output: NOTE: All clock frequencies in following PLL sections are basedC674X_0: GEL Output: off OSCIN = 24 MHz. If that value does not match your hardwareC674X_0: GEL Output: you should change the #define in the top of the gel file, save it,C674X_0: GEL Output: and then reload.C674X_0: GEL Output: C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: | PLL0 Information |C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: C674X_0: GEL Output: PLL0_SYSCLK1 = 300 MHzC674X_0: GEL Output: PLL0_SYSCLK2 = 150 MHzC674X_0: GEL Output: PLL0_SYSCLK3 = 25 MHzC674X_0: GEL Output: PLL0_SYSCLK4 = 75 MHzC674X_0: GEL Output: PLL0_SYSCLK5 = 100 MHzC674X_0: GEL Output: PLL0_SYSCLK6 = 300 MHzC674X_0: GEL Output: PLL0_SYSCLK7 = 50 MHzC674X_0: GEL Output: C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: | PLL1 Information |C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: C674X_0: GEL Output: PLL1_SYSCLK1 = 300 MHzC674X_0: GEL Output: PLL1_SYSCLK2 = 150 MHzC674X_0: GEL Output: PLL1_SYSCLK3 = 100 MHzC674X_0: GEL Output: C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: | PSC0 Information |C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: C674X_0: GEL Output: State Decoder:C674X_0: GEL Output: 0 = SwRstDisable (reset asserted, clock off)C674X_0: GEL Output: 1 = SyncReset (reset assered, clock on)C674X_0: GEL Output: 2 = Disable (reset de-asserted, clock off)C674X_0: GEL Output: 3 = Enable (reset de-asserted, clock on)C674X_0: GEL Output: >3 = Transition in progressC674X_0: GEL Output: C674X_0: GEL Output: Module 0: EDMA3CC (0) STATE = 3C674X_0: GEL Output: Module 1: EDMA3 TC0 STATE = 3C674X_0: GEL Output: Module 2: EDMA3 TC1 STATE = 3C674X_0: GEL Output: Module 3: EMIFA (BR7) STATE = 3C674X_0: GEL Output: Module 4: SPI 0 STATE = 3C674X_0: GEL Output: Module 5: MMC/SD 0 STATE = 3C674X_0: GEL Output: Module 6: AINTC STATE = 3C674X_0: GEL Output: Module 7: ARM RAM/ROM STATE = 3C674X_0: GEL Output: Module 9: UART 0 STATE = 3C674X_0: GEL Output: Module 10: SCR 0 (BR0/1/2/8) STATE = 3C674X_0: GEL Output: Module 11: SCR 1 (BR4) STATE = 3C674X_0: GEL Output: Module 12: SCR 2 (BR3/5/6) STATE = 3C674X_0: GEL Output: Module 13: PRUSS STATE = 0C674X_0: GEL Output: Module 14: ARM STATE = 3C674X_0: GEL Output: Module 15: DSP STATE = 3C674X_0: GEL Output: C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: | PSC1 Information |C674X_0: GEL Output: ---------------------------------------------C674X_0: GEL Output: C674X_0: GEL Output: State Decoder:C674X_0: GEL Output: 0 = SwRstDisable (reset asserted, clock off)C674X_0: GEL Output: 1 = SyncReset (reset assered, clock on)C674X_0: GEL Output: 2 = Disable (reset de-asserted, clock off)C674X_0: GEL Output: 3 = Enable (reset de-asserted, clock on)C674X_0: GEL Output: >3 = Transition in progressC674X_0: GEL Output: C674X_0: GEL Output: Module 0: EDMA3CC (1) STATE = 3C674X_0: GEL Output: Module 1: USB0 (2.0) STATE = 3C674X_0: GEL Output: Module 2: USB1 (1.1) STATE = 3C674X_0: GEL Output: Module 3: GPIO STATE = 3C674X_0: GEL Output: Module 4: UHPI STATE = 3C674X_0: GEL Output: Module 5: EMAC STATE = 3C674X_0: GEL Output: Module 6: DDR2 and SCR F3 STATE = 3C674X_0: GEL Output: Module 7: MCASP0 + FIFO STATE = 3C674X_0: GEL Output: Module 8: SATA STATE = 3C674X_0: GEL Output: Module 9: VPIF STATE = 3C674X_0: GEL Output: Module 10: SPI 1 STATE = 3C674X_0: GEL Output: Module 11: I2C 1 STATE = 3C674X_0: GEL Output: Module 12: UART 1 STATE = 3C674X_0: GEL Output: Module 13: UART 2 STATE = 3C674X_0: GEL Output: Module 14: MCBSP0 + FIFO STATE = 3C674X_0: GEL Output: Module 15: MCBSP1 + FIFO STATE = 3C674X_0: GEL Output: Module 16: LCDC STATE = 3C674X_0: GEL Output: Module 17: eHRPWM (all) STATE = 3C674X_0: GEL Output: Module 18: MMC/SD 1 STATE = 3C674X_0: GEL Output: Module 19: UPP STATE = 3C674X_0: GEL Output: Module 20: eCAP (all) STATE = 3C674X_0: GEL Output: Module 21: EDMA3 TC2 STATE = 3C674X_0: GEL Output: Module 24: SCR-F0 Br-F0 STATE = 3C674X_0: GEL Output: Module 25: SCR-F1 Br-F1 STATE = 3C674X_0: GEL Output: Module 26: SCR-F2 Br-F2 STATE = 3C674X_0: GEL Output: Module 27: SCR-F6 Br-F3 STATE = 3C674X_0: GEL Output: Module 28: SCR-F7 Br-F4 STATE = 3C674X_0: GEL Output: Module 29: SCR-F8 Br-F5 STATE = 3C674X_0: GEL Output: Module 30: Br-F7 (DDR Contr) STATE = 3C674X_0: GEL Output: Module 31: L3 RAM, SCR-F4, Br-F6 STATE = 3
Looks normal...
Can you dump your I2C registers before and after the transaction?
Hello Brad,
I found out, that I2C1 doesn't work while ARM is in Suspend (not running any code). I2C0 does ... no idea why this is different.
When I run the ARM at the debugger (even if there's no executable code) I2C1 is working as it should.
Anyhow, thanks for your help.
Thank you for reporting back this info to the forum. It's very strange indeed. A colleague suggested that perhaps the behavior is related to the Suspend Source Register (SUSPSRC). You can find that register documented in Section 11.5.11 of the TRM.
Best regards,Brad
Has this problem get be solved? We met the same problem as Roland, however the difference is that even when code is running on the ARM side, the I2C1 is still not working.
One TI employee Franklin Cooper suggested (thread link) that the problem might be related to the fact that I2C1 PSC module is not enabled by default at startup. I did two things: 1)using GEL function to turn on PSC1 module 11(I2C1), 2) also repeated the process using C code. After doing these the PSC1.MDSTAT11 (0x01e2782c) register reads 0x00001E03, of which bits [5-0]=00,0011=3=ENABLE. Even with this I2C1 is still not working.
For what Brad suggested (SUSPSRC register at 0x01c14170), it reads 0xFFFFFFFF, and its bit 17 I2C1SRC is showing that :1 - DSP is the source of the emulation suspend, which is the same as bit 16 I2C0SRC as well as all other bits.
If I configure the I2C1 pins as GPIO output, I was able to generate square waves of arbitrary shape and frequency. But when they are configured as I2C1 pins there is simply no output. I don’t have a logic analyzer but with an oscilloscope powerful enough there is simply no appreciable SCL and SDA signal on the lines.
Regards,Paul
Just need a confirm from TI whether the L138 I2C1 is faulty or unstable. If true, I would use the workaround of configuring the two I2C1 pins as GPIO and simulate the simple protocol.
There are no known issues with respect to I2C1. I was just looking at the LogicPD EVM schematics and wondering if perhaps there's some kind of board issue related to using I2C1. There's a lot of pin muxing on those pins, e.g. they also happen to be UART pins. In fact, I see a TRS3386ECPWR device hooked up to those pins. In particular that device has a /PWRDOWN pin on it which would disable the outputs. Have you tried changing the population of that pin such that you disable the TRS3386E? Also, what is the voltage level of whatever you've connected to the I2C bus? Seems like there could be opportunity for things to get mixed up due to the dual-voltage support on these pins.
Brad,
We are using a customized board. Though the I2C1 pins are multipled with others, it should not be a cause of problem as long as Pinmux registers are set. However one question I have with pinmuxing is:
// pinmux defines.#define PINMUX_I2C0_REG (4)#define PINMUX_I2C0_MASK (0x0000FF00)#define PINMUX_I2C0_VAL (0x00002200)#define PINMUX_I2C1_REG (4)#define PINMUX_I2C1_MASK (0x00FF0000)#define PINMUX_I2C1_VAL (0x00440000)
Though pinmux register for both I2C0 and I2C1 are pinmux 4, the value to set them as I2C pins are different (2 for I2C0 and 4 for I2C1). I had suspected that 4 for I2C1 was a typo both in the TRM and the BSL. However changing it to 2 as I2C0 doesn't solve the problem.
Regarding power group, DVDD3318_A, DVDD3318_B and DVDD3318_C all use the same 1.8V voltage and have been merged as one single group.
On the logic PD EVM does the I2C1 really work? Could someone run a test and measure the pins to make sure it is really error-free?