search

energia / Energia

Fork of Arduino for the Texas Instruments LaunchPad's
http://energia.nu
Other
794 stars 672 forks source link

i2c not working on MSP430FR5969 #651

Closed battosai30 closed 8 years ago

battosai30 commented 9 years ago

i2c simply does not work on MSP430FR5969 Launchpad.

Topic here : http://forum.43oh.com/topic/8602-fr5969-and-i2c-issue/

rei-vilo commented 9 years ago

What is the revision of the MSP430FR5969 LaunchPad?

battosai30 commented 9 years ago

Rev 2.0

StefanSch commented 9 years ago

Just gave it a quick try with a master_reader - slave_sender pairing of two boards but this seems to work fine. Which pins have you used for the I2C interface? Do you have external pull up resistors used for the I2C line. If not, ensure that the internal gives enough drive strength.

rei-vilo commented 9 years ago

I've experienced issues with the Internal pull-ups. Try instead external resistors, 10 kΩ or 4.7 kΩ as standard values.

battosai30 commented 9 years ago

Ok I made so news tests : as I thank, my BMP180 module integrates pull-up resistors (10k). I connected my logic analizer and strictly nothing happens on SDA or SCL pins ... So here it's not a pull up problem. As I said in the topic, there is a problem with UCB0CTLW0 register and setting UCTXSTT. With word register it does not work, instead of UCB0CTL1.

StefanSch commented 9 years ago

The only difference is that the bit is once set in Byte mode and once in Word mode. Unfortunately this does not give any reason why it should not work.

battosai30 commented 9 years ago

I know that, but it's a fact. It's not the first time I have problem with word access, it happens to me when I wrote my RTC_A library on CC430 : setting a bit in word register did not work but in byte register yes. For other word register it was okay, it was just a specific word register.

A friend who worked years ago on mincrocontrollers told me that it happens to him to find this type of bugs and they are internal to the micro, so only TI can correct that.

spirilis commented 9 years ago

While I have not done much I2C work with the FR5969 and Energia, I have played with the peripheral a fair amount recently and can vouch that there does not appear to be any issues accessing the UCB registers in word mode. Works great from my experiments.

I say you thoroughly investigate your BMP hardware and try your own external pullups (2K to 4.7K, doesn't matter that much) before blaming the chip and/or stack. I always end up wasting prodigious amounts of time when I go down this path myself questioning the stack & MCU.

StefanSch commented 9 years ago

Still does not give me an idea why it is working on my system. Have you used one of the example sketches? I could give it a try with it too.

battosai30 commented 9 years ago

The problem is not about pull up or anything else outside the MCU I guess because I have obsolutly no signal on my logic analyzer ...

I tried example code from different libraries, and simply code wire.beginTransmission() + wire.write() + wire. endTransmission() still doesn't give any signal ... So it's not a problem of adress or even from the BMP, I have no start condition.

My launchpad is new so I could not burn anything, and I am not the only one (another guy on 43oh/energia seems to have the same issue). Maybe a revision problem (of the MCU, not launchpad)?

spirilis commented 9 years ago

No signal meaning, it sits at Vcc, or GND?

battosai30 commented 9 years ago

VCC

battosai30 commented 9 years ago

Ok guys, I have some good news :)

I found a lot of errors and bugs, I am surprised that it worked for you ... I will try to list everything, all the modifications are done in twi.c :

pinMode_int(TWISDA, TWISDA_SET_MODE); pinMode_int(TWISCL, TWISCL_SET_MODE);

has to be changed to

P1SEL1 |= BIT6 + BIT7;

I don't know why for now, but with pinMode_int() it does not work ...

UCB0IE |= (UCRXIE0|UCALIE|UCNACKIFG|UCSTTIFG|UCSTPIFG);

should be :

UCB0IE |= (UCRXIE0|UCALIE|UCNACKIE|UCSTTIE|UCSTPIE);

Finally it gives that : http://pastebin.com/J2fMdKbU

I have just tested write() function, and see that was ok on my logic analizer.

battosai30 commented 9 years ago

Ok I have found the problem with pinMode_int() : my pins_energia file was wrong ! But when I looked in the github, it's okay .... And I have never modified it ! I downloaded my Energia15 directly on the website as .zip, so maybe it's a "bad version" available.

I just checked : that the problem. I still have the original zip in my download folder and take a look at my variant for msp430fr5969 :

if defined(MSP430_HAS_EUSCI_B0)

static const uint8t SS = 8; /* P1.3 / static const uint8t SCK = 26; / P2.2 _/ static const uint8t MOSI = 31; / P1.6 aka SIMO _/ static const uint8t MISO = 32; / P1.7 aka SOMI _/ static const uint8t TWISDA = 31; / P1.6 _/ static const uint8t TWISCL = 32; / P1.7 */

It should be like https://github.com/energia/Energia/blob/master/hardware/msp430/variants/launchpad_fr5969/pins_energia.h

rei-vilo commented 9 years ago

Thank you for the finding. I'm escalating it as Security.

See another examples of discrepancy between the GitHub repository and the binaries at

StefanSch commented 9 years ago

OK, that make sense now for me - thanks for all your investigations. I tried to find out why the old files are in the release version of Energia 15 but could not see the issue there, it will be correct in the next release at least as this file in master are now correct.

Also thanks for the code clean ups - i am not sure about all of them being required or correct but i will review then. I have to consider also some multi master situations where maybe a flag can be set without transition by the Energia sketch.

rei-vilo commented 9 years ago

See #658.

battosai30 commented 9 years ago

There is still some problems : write() is ok but not read(). If a resquestFrom() is done, it's stuck and even if I reload a new working code with write(), it does not work anymore ... I have to disconnect and reconnect the launchpad to get it working well. Very strange ...

EDIT : finally it's okay. I used this library for BMP085 : https://github.com/astuder/BMP085-template-library-Energia/blob/master/BMP085t/BMP085_t.h

The problem comes from Wire.endTransmission(false). Without false argument it's okay, I don't know why for now

robertinant commented 9 years ago

Energia release 15 came from the EnergiaPrivate repository. Unfortunately a wrong pins_energia.h got checked in a while back and ended up in the release. The next release will come from the public Energia repository which does have the correct pins_energia.h.

@StefanSch, could you please look into the issue? I tried here with an Aardvark and I see issues with the transactions.

Thanks!!

robertinant commented 9 years ago

Ignore my comment about Aardvark not working. It works perfectly with the Aardvark I2C tool. Can't get it to work with the BMP085. @battosai30, I was not able to get it to work with your twi.c. The BMP085 works perfectly on the F5529 LaunchPad.

battosai30 commented 9 years ago

Hum ... You used the same library ? With the modifications I suggested ?

StefanSch commented 9 years ago

i have merge the suggested updates (at least all which i think could have some effects on the detected behavior). Unfortunately i do not have the BMP085 available for testing. Can you please check if the updated file does work on the BMP085. I have push it to the git branch : https://github.com/energia/Energia/blob/issue_651/hardware/msp430/cores/msp430/twi.c

If it works i will trigger a merge request.

Thanks, Stefan

battosai30 commented 9 years ago

It works for me on BMP180, but it still stays stuck if I don't modify Wire.endTransmission(false) to Wire.endTransmission()

StefanSch commented 9 years ago

i have completely reviewed the code again and i think that some updates did not get merged in. At least there are some things missing which i would have expected to be in. I have updated the files again and did some basic I2C read and write test on the F5529, FR4133, F2553, F5739 - so that all types of USCI / eUSCI should be used.

May you could give it another try on the BMP085 (would be good to test the F5529 and the FR5969) before merging this into the master branch. I have also fixed an wrong assignment for the launchpads where the pins for SCL and SDA are swapped against the documentation on the web. Updated files: https://github.com/energia/Energia/blob/issue_651/hardware/msp430/cores/msp430/twi.c https://github.com/energia/Energia/blob/issue_651/hardware/msp430/variants/launchpad/pins_energia.h

csjall commented 8 years ago

Is there a plan to release an installer update with these changes integrated? I am currently using 0101E0016 which does not include these updates. If nothing is forthcoming, then I will attempt to patch my current installation.

rei-vilo commented 8 years ago

A new release is on the making. Stay tuned!

robertinant commented 8 years ago

Give this a try: I2C has been moved to pins 9 (SCL) and 10 (SDA).

You can find the release candidates here:

https://s3.amazonaws.com/energiaUS/energia-0101E0017-macosx.dmg https://s3.amazonaws.com/energiaUS/energia-0101E0017-linux.tgz https://s3.amazonaws.com/energiaUS/energia-0101E0017-linux64.tgz https://s3.amazonaws.com/energiaUS/energia-0101E0017-windows.zip

High level release notes:

1: Lots of bug fixes 2: CC2650 SensorTag support 3: Updated to the latest DSLite for MSP432 and CC2650 4: WiFi library enhancements 5: I2C has been moved to pins 9 and 10 as per the new BoosterPack standard 6: RedBearLab WiFi Micro support

csjall commented 8 years ago

The release candidate is not working for me as expected. I am not getting "sane" I2C signals on the wire. It seems the SCL is low instead of being high. Neither the G2 or the FR5969 are working as expected. See attached screenshot.

i2c

Additionally I have some errors when I try to use the MspFlash library.

I didn't realize the SCL pin assignments were changing. This may case some problems for some of my existing PCBs.

StefanSch commented 8 years ago

the new version has the default I2C assignment on pin 9/10 but you can always switch to the alternate module if this is available on the device Just use setModule(uint8_t i2cModule) with the number of the hardware instance of the communication module. Some other question which would help to identify the issue:

csjall commented 8 years ago

1) I am using 10k Ohm resistors pull up resistors. 2) I have the following pins connected on the slave: 1 - VCC 8 - debugging pin 9 - SCL 10 - SDA 20 - GND 3) I am inclined to agree with you, except that the exact same circuit works just fine with 0101E0016.

The part that is suspect is that SCL has a 20kHz frequency when I am running 0101E0017 vs. the expected 100kHz when I am running 0101E0016.

StefanSch commented 8 years ago

The clock speed difference is based on the software emulated I2C interface. This was required on some device wgich did not had a hardware I2C module mapped to that pins

rei-vilo commented 8 years ago

Please refer to the MSP430FR5969 LaunchPad pins map.