I2C problem on EK-LM3S2965

Hello Duy

The SDA and SCL Pin requires to be configured as

    GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_2);

    GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);

instead of

    GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3 | GPIO_PIN_2);

Regards

Amit

Amit Ashara said:

GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_2);

Please don't hate me - but that's not true!  (in this case)  Poster has (defrocked) LM3S - those devices did not suffer the indignity of PinTypeI2CSCL!  (we've shipped over 500 LM3S811s - never/ever used nor saw I2CSCL until (ill fated) LX4F arrived)

I'd bet that his LACK of pull-ups (at minimum) contributes to lack of signal...

Further - should that MCU be "Tempest class" - poster requires "PinConfigure()" function call, too...

The fact that when ordered into push-pull GPIO - proper signal reveals - indicates that it very likely is the improper ordering of those pins into I2C mode - along w/awol pull-up Rs.  Poster's follow on attempt then - by manually "undoing the I2C set-up/config - (of course) can only make matters worse.

Suggestion: add 2 proper external pull up Rs - check if yours is Tempest (that's fun) and use your model I2C code minus any of that "last ditch" attempt to "set pin parameters manually."  I2C pintype & pinconfig (if required) do it properly - unwise to alter...

Hi Amit,

It doesn't work!!!

I found something unusual in the statement

GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_2);

1) It set GPIO as INPUT mode, so how it sends out SCK & SDA ???

2) It set OD (Open Drain), but there's NO physical pull-up on board, so how can the line go high as required by the I2C specs ?

So, I modified as below

1) Set GPIO as OUTPUT mode

2) Turn on PU, and turn off OD, then the line goes high as required by I2C spec

However, in debugging using single-step, I see the MDR always 0, it never gets set, even I did change manually, but it's always 0!!!

So, you have any known working I2C example and sent to me ?

Thanks

~Duy-Ky

Duy-Ky Nguyen88210 said:

GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_2);

Based from Stellarisware Peripheral Driver Library User's Guide, that this function above should be used for "Blizzard- Class" device. See, the User's Guide for further info.

LM3S2965 is Fury-Class device, so the use of GPIOPinTypeI2CSCL is not recommended.

- kel

Hello Duy,

I would defer to Kel and cb1 as they are more experienced on the LM3S devices than me. However the MDR register behavior has remained the same over the product lines. When it is read, then it is the receive data that is sent to the CPU and not what has been written. That is why you see 0. Can you connect a scope probe/LA and see what is physically happening on the SCL and SDA.

Regards

Amit

Hi Amit,

I uses scope to probe signal and found no activity on SCL. There should be SCL activity regardless data value

I just loaded another program to toggle GPIO and now I cannot connect to target

CORTEX_M3_0: Error connecting to the target

I believe the target keeps running and the on-board USB debugger cannot stop it for connection.

Any idea how to solve this problem ?

Thanks,

~Duy-Ky

Hello Markel,

It's a mistypo, the right statement is

GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_2);

Is it the right one ?

Thanks,

~Duy-Ky

Duy-Ky Nguyen88210 said:

GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_2);

From the User's Guide, see below regarding GPIOPinTypeI2C.

This function cannot be used to turn any pin into an I2C pin; it only configures an I2C pin for
proper operation. Devices with flexible pin muxing also require a GPIOPinConfigure() function
call.

This code snippet below is from master_slave_loopback.c from Stellarisware 10636. See, if this code below works for your board.

    //
    // The I2C0 peripheral must be enabled before use.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C0);

    //
    // For this example I2C0 is used with PortB[3:2].  The actual port and
    // pins used may be different on your part, consult the data sheet for
    // more information.  GPIO port B needs to be enabled so these pins can
    // be used.
    // TODO: change this to whichever GPIO port you are using.
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);

    //
    // Configure the pin muxing for I2C0 functions on port B2 and B3.
    // This step is not necessary if your part does not support pin muxing.
    // TODO: change this to select the port/pin you are using.
    //
    GPIOPinConfigure(GPIO_PB2_I2C0SCL);
    GPIOPinConfigure(GPIO_PB3_I2C0SDA);

    //
    // Select the I2C function for these pins.  This function will also
    // configure the GPIO pins pins for I2C operation, setting them to
    // open-drain operation with weak pull-ups.  Consult the data sheet
    // to see which functions are allocated per pin.
    // TODO: change this to select the port/pin you are using.
    //
    GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_2 | GPIO_PIN_3);

- kel

As stated (my 1st response) LM3S has never required the "bandaid" of, "GPIOPinTypeI2CSCL()." 

As also stated (that same {ignored} post) pull-up resistors ARE Required!  (they are not "nice" to have - they are mandatory!  You remain "silent" as to your use of these much needed, adjunct components!  (Not good!)

Past StellarisWare examples (not TivaWare) reveal the proper set-up/config. of the I2C peripheral.  Again (as past started) we've 500+ LM3S modules (still) operating succesfully in a variety of field applications - each one employing I2C to transact w/sensors and/or EEproms.

One poster "wove in" Blizzard which has nothing to do w/LM3S devices.  (such started w/departed LX4F)

Markel Robregado said:

// Configure the pin muxing for I2C0 functions on port B2 and B3. // This step is not necessary if your part does not support pin muxing. // TODO: change this to select the port/pin you are using. //

GPIOPinConfigure(GPIO_PB2_I2C0SCL);

GPIOPinConfigure(GPIO_PB3_I2C0SDA);

Even though this code is w/in StellarisWare - as the warning (highlighted) states - (and your earlier post revealed - II did not fact check) his part is NOT Tempest class - which alone required (w/in LM3S) GPIOPinConfigure().

Thus both such "PinConfigures" should be removed!  (as they cannot "work" and may in fact disturb/disrupt earlier (I2C set-up.)  Below is an extract from the ever-robust, StellarisWare:

12.2.2.11 GPIOPinConfigure
Configures the alternate function of a GPIO pin.

Note:
This function is not valid on Sandstorm, Fury, and Dustdevil-class devices. Also, if the same signal is assigned to two different GPIO port pins, the signal is assigned to the port with the lowest letter and the assignment to the higher letter port is ignored.

As poster appears to be using one of those 3 described devices - such PinConfig use is, "verboten."

Absent everywhere (but for BOTH) my earlier posts - is the absolute requirement for pull-up Rs on both I2C lines...

Hi Markel,

That is the very code I got from Stellarisware and it fails working for me. In this code, I have com[pile error with

    GPIOPinConfigure(GPIO_PB2_I2C0SCL);
    GPIOPinConfigure(GPIO_PB3_I2C0SDA);

so I have to comment then out

Thanks,

I totally agree that PULL-UP is mandatory, that's why I mentioned in my previous email that I didn't see the line go HIGH and it violated the I2C specs.

I'm also a FPGA designer and implemented successfully several I2C core to add new communication line per customer request in the last minute, without making new PCB. So there're NO physical pull-up on board, I had to do Internal pull-up inside FPGA and they all worked fine. Actually this technique of internal pull-up I also used for Active_Low chip-select too.

So, I believe I would have the same effect with LM3S2965 by turning off OD (Open-Drain) and turn on PU in the LM3S2965, it would be equivalent to external physical pull-up resisters.

Now I'm trying to find physical R for external PU to see if it works.

Thanks so much for your reponses, in particular this time, really appreciated

~Duy-Ky

How to take back control of EL-LM3S2965 to do JTAG debugging ?

I loaded a program to toggle SCL0 pin to see how it behaves and now I'm NOT able to load any program with the error msg below

CORTEX_M3_0: GEL Output:
Memory Map Initialization Complete
CORTEX_M3_0: Error connecting to the target

I guess the MCU keeps running and the emulator could not stop it. So I download LM Flash Programmer to erase the flash

I select option "LM3S2965 CAN Evaluation Board" but it gave me error "

**ERROR** : Unable to connect to target!

How to take back control of JTAG Debug ?

Thanks,

~Duy-Ky

You're awesome, Amit

Thanks so much

~Duy-Ky

Hi CB1

You're absolutely correct!

I just soldered two of 2 K R's to SCL and SDA, I could see I2C signal right away.

So, I'm wrong in expecting internal and external pull-up behave the same for this chip, even it never fails me in FPGA.

You're awesome, CB_1

Thanks so so much for your time, during this time in particicular

Kind Regards,

~Duy-Ky

Hi Duy-Ky,

Indeed Amit's awesome - this reporter - not so much...  (but I can "marry you" @ sea - or sue you when on land...)

Your (expectation) was not wrong - it just failed to anticipate that what may work for an FPGA may not (fully) carry over to an MCU - due to internal logic-flows/other mechanisms...

Those I2C pull-ups are (cheap) insurance - their cost is more than justified by your savings of time/frustration...

Dear CB1,

It's awesome just because of nothing else but attitude.

To me, the most important thing is attitude, a lot more important than anything else (knowledge, skill set, ...), as it's a key factor to success, solution to any problem.

And you guys have an excellent attitude and I'm really impressed ;-)

You guys and myself could be more or less  the same in the fact that we see this kind of thing not just as a career,  not just as a job to earn the living, but also a HOBBY, really enjoy to work on it. It's fun and it causes frustration, and once we get over it, it's fun. That's why we're still working on this during this time in year, the time others enjoy social activities.

Happy Holidays.

~Duy-Ky

Dear Duy-Ky,

Would that (long departed) 3rd grade, NYC public school teacher - hear/read your kind words.  You absolutely, "Get it." 

It is possible to work hard/long - and "fun/play" proves an excellent lubricant.  (past teacher did not - she banished the youthful cb1 to back of room - to high stool/conical cap!)  (for talking - entertaining the "troops" - while she droned on - hey lady - we GOT it!)  I'm not too terribly scarred...

Don't be so sure about "not" enjoying social activities - cb1's been known to ply/sail high seas w/"far out of his league, unskilled/rowdy (dare I say enhanced) blonde crue!"  (It's a "line" not a "rope!")  (boat captain may perform "marriage" while @ sea - success/duration w/out guarantee...)

Do consider vendor's latest/greatest MCUs - you'll not (easily) be able to acquire many more of your LM3S.

Bon chance, mon ami - keep your methods/attitude as well...

Hi CB_1,

I meant we enjoy not only social activity, but also technical one, during this special time

I'm using LM3S2965 as it's available to me, I got it 5 years ago, now using to evaluate Starterware for controlling Touch-Screen LCD. Now I'm able to write/read back for verification a block of 256 bytes to an EEPROM.

Next step is SPI. SPI for LCD, I2C for Touch Panel.

I also realize this MCU is not recommended for new design, so I put an order of EK-TM4C123GXL-Tiva™ C Series TM4C123G LaunchPad Evaluation Kit. It's cheap, so I ordered 3 of them, in case I burn any!?!? My hands are not good in dealing with board, that's why I hesitated to solder PU R's per your recommendation, only after failure in using internal PU!

Have Fun, CB_1

Duy-Ky,

Our methods/madness - very much alike.  (we also - (only) order a minimum of 3 of ea. new chip/board!)  Dreaded "Murphy" always lurks - and having "more than one" enables famed, "A-B" test - we hate "single board anomalies."

Our small firm has acquired used (yet high end) pick n place & reflow oven (both @ auction) yet we bought 500 of another vendor's Cortex M0 (assembled/tested) boards.  (No way could we build/assemble/test for the sub 8 (USD) price we paid...and we'd (still) then have to program/part load the pick n place!)  We note (thank God) not a single 0-ohm MCU-MCU gotcha resides - these maker's boards...  (buried (this vendor's schematic's "mice-type") - if you're "eagle eyed" - you just might spot the (afterthought) 0-ohm warning...)  Watch for this - your new (3) boards...

You may find it useful to design/develop a secondary pcb - to plug into your new kits.  That added board can house your specialized components, level shifters and other chips/headers which see "normal action."  We find this method makes great sense for all but the highest volume - and size-constrained opportunities - and those are areas where our marketing/victory pennant is not often hoisted...