MSP430F47186: I2C example for simple EEPROM Communication in single master mode?

Hi BasePointer,

why do you want to use polling when communicating with the EEPROM? In the code examples were lot's of I2C example code which you can use with ease (list of examples http://focus.ti.com/lit/ml/slaa438/slaa438.pdf, code examples MSP430F471x6 / MSP430F471x7)

In addition, there's a nice application note on how to interface the MSP430 with an EEPROM. Find it here http://focus.ti.com/mcu/docs/litabsmultiplefilelist.tsp?sectionId=96&tabId=1502&literatureNumber=slaa208a&docCategoryId=1&familyId=342.

Rgds
aBUGSworstnightmare 

Hi nightmare,

 

I want to pool, because my routines are synchronous. Interrupt handled EEPROM routines, I thought on it, I couldn't see and benefit of doing like so. It requires completely different logic, FIFO, state machines etc.. After writing, I need to verify to complete the process. Another problem for interrupt I need 1Mhz I2C speed, I think such as design decreases the efficiency of the execution.

 

Anyway, your link was exactly what I looked for. But, it is not working. After clicking the source code link, It says TI: Sorry! We couldn't find your page.

 

Thank you.

Hi BasePointer,

the links works fine! But, if you're still facing troubles in accessing the sources pls find them enclosed.

8863.SLAA208b.zip

Kind regards
aBUGSworstnightmare 

Hi,

 

Thanks for the reference. I have checked the codes, It seems this routines are also interrupt driven. Do we really need interrupts?

 

BP.

BasePointer said:

Do we really need interrupts

No. Using interrupts may speed up things and allows transfers to take place in the background, but especially for I2C, interrupt driven transfers are usually overkill. Well, for data storage they might make sense. For most transfers, where the protocol is complex compared to the data, it doesn't make much sense and using a polling process often is much simpler.

So no, you don't nee dinterrupts. You can simply trigger anything based on the IFG flags with busy-waiting code. It is quite simple and straightforward. The key is to do the wait between the individual read/write steps based on the right status bit. The diagrams in the users guide are a good help here.

If you want to implement an I2C slave, however, interrupts are usually the better choice.

Hi,

 

The only problem I faced is reading final byte in receive mode (sequential eeprom reading). Final byte which is read is sometime comming with unexpected value.

The datasheet says that if you are reading the final byte, you have to set stop bit while the byte is being received. If you can not catch this time, it will automatically start reading another byte which belongs to next address for my eeprom and previoues RXBUF will disappear. So timing is very critical, if any interrupt occurs at that line, it will fail, so I need to disable interrupt to be sure.

 

Thank you.

Timing is not as critical as you might think if you're master.

Once you got the interrupt for the forelast byte, you may set the stop bit. Yet there's more: teh I2C module will stop at receiving the last bit of the next byte (or it would overwrite the still unread last byte in RXBUF) until you respond to the interrupt and read the byte. So no matter how long it takes the answer the forlast interrupt, you will still have 1 clock cycle after reading the RXBUF before your time window for setting the stop bit ends. You can even do so before reading RXBUF since when the ISR is called, the reception of the last byte has already begun and setting the stop bit is valid.

You see, it is not time critical at all. In fact you have all the time you want, even an eternity, as I2C standard does not define any timeout time.

One thing:
Are you sure you can clock the eeprom with 1MHz? The original I2C standard was for a maximum clock of 100kHz and the extended one ends at 400kHz. This is why the datasheet limits the mximum I2C clock speed. Not by hardware restrictions but because it is limited by the I2C standard.

If your slave device runs outside the standard limitations, I don't see a reason why the I2C module won't work at this speed too. The logic circuitry surely won't falter at 1MHz. SPI is running with way more (1/2 MCLK? MCLK? I'm not sure for the 4x series)

Hi,

 

Yes MSP is master here and I2C standard is completely synchronous, but timing restriction comes from MSP module itself. Even if you use interrupt, I think it is dangerous. Because of last byte restriction. See the image:

 

I2C standard specifies 100 kHz as standard mode, 400 kHz as fast mode, 1 MHz as fast-mode plus. While SMCLK is 8 MHz, I put 8 as baud rate divider and I2C module works very well at 1 MHz also. We just reduced pull up values to around 2kOhm.

10x,

BP.

BasePointer said:

Yes MSP is master here and I2C standard is completely synchronous, but timing restriction comes from MSP module itself

actually not. Synchroneous master means for I2C that the msp is providing the clock and therefore the progress of the transmission. So there does not come a timing restriction from the MSP, only a transaction order restriction. If you did not read the last byte from RXBUF, teh hardware will NOT clock teh last bit of the next byte in until you did. So the hardware is waiting for you to handle the last RX interrupt before it proceeds receiving the last bit of the next. So you have all time of the world to set the STP bit, The transfer is waiting for you:

"If UCBxRXBUF is not read, the master holds the bus during reception of the last data bit and until the UCBxRXBUF is read."

If you only want to receive a single byte, this of course won't work that easily. But maybe there is a trick: clear GIE before setting the STT bit, then manually set the RXIFG bit and set GIE anew. It's just a guess, but maybe too the reception of the last bit of the first byte is delayed. To avoid immediate call of the RX ISR, clear the RXIE bit before setting GIE.
Once you see STT clear, set the RXIE bit and your RX ISR is called, will receive a fake byte and can set the STP bit. very likely this will work. Not as straightforward as it could be, but well...

Or, since you're already polling, you may just clear GIE until the STT bit clears and then set the STP bit and set GIE. This will of course block other ISRs until STT is sent and acknowledged.

I can imageine some other ways to handle this too, but I must admit it is a bit tricky.

BasePointer said:

1 MHz as fast-mode plus.

Ah, I didn' t know of the fast mode plus, I never came across a device using it (for data storage I prefer SPI, and sensors/RTCs I used didn'T support fast mode plus).

aBUGSworstnightmare said:

MSP430F471x6 / MSP430F471x7)

This includes only the examples that use two MSPs as MASTER-SLAVE!