I2C clock frequency division

Hello,

It looks like you used the UCBxBRW register, but this is the eUSCI_Bx bit rate control register.  The MSP430F6659 only has USCI, so you should be using UCBxBR0 and UCBxBR1 baud rate control registers instead.  Try this (along with changing any other eUSCI registers to their USCI variant) and see if it makes any difference.

Thanks,

Ryan

Ryan,

I'm using my own definition of microcontroller registers, linked at the correct address, and not the keywords provided in TI resources.

The user's guide of "MSP430x5xx and MSP430x6xx family" SLAU208M only mentions eUSCI modules (and no USCI) so I figured it was the same. If there are any differences, I'm interested in knowing which. The datasheet doesn't seem to show any difference and the manual doesn't mention limitations of USCI over eUSCI.

Anyway I've used the mapping specified in the datasheet (so USCI places), and in both datasheet and user manual, UCBxBR0 and UCBxBR1 are the same as UCBxBRW register (just a byte or word view of the same place), so that's what I'm talking about and what I used. (address 05E0 and 05E1)

Same for other registers, I access them manually, and I don't see what else could modify the clock frequency.

The User's Guide mentions both eUSCI and USCI modules as either can be found in different MSP430s of the same family.  SLAA522 discusses the differences between the two.

It does appear that the registers are the same.  Therefore, I would check the UCBxBRx registers inside of your debugger to ensure that the values you want are being set correctly.  It wouldn't hurt to also check the UCSSELx bits under the UCBxCTL1 control register to make sure that the USCI module is being sourced by ACLK.

Thanks,

Ryan

Jens-Michael Gross said:

So for the first two lines, you’re operating outside the specs.

True: I first tried the whole table with 1MHz source clock then did it again with 4MHz to see the impact of frequency, that's when I got out of spec.

Jens-Michael Gross said:

. If the pull-up is too weak, the clock signal doesn’t rise fast enough once released, and the USCI will stretch the clock cycles by the rise time

This must be it indeed, I have an ulgy rising time so it must be happening to me. That answers the question "- Is it possible that external hardware elements could slow down my clock ?" and that solves my problem.

A shame the clock stretching chapter doesn't mention this case of 'self stretching', I had disregarded it as the slave had nothing to do with it and there is no other master.

Thanks a lot for your help Jens on this one, and on all threads where you've answered someone else's problem that was happening to me too.

PS: I hope TI pays you ^^

Guillaume Sarrot said:

PS: I hope TI pays you ^^

Ha. They should but don't. There are perks and other recognitions though.

Guillaume, you’re right, the implications of some things are not always obvious, like this ‘self-stretching’. You need to read between the lines and also have a look at the ‘big whole’. It is easy to forget that even in the digital world, signals are still transported on an analog way (except for quantum-mechanical links). And interpretation of these analog signals into digital signals on the other end may be ambiguous.

 I’m indeed not paid for my work here. However, I got a lifelong free access to any MSP tools for winning the 2010 contributor of the year award. And a trip to Dallas last year. And as Brian commented, there are a few other ”perks and recognitions” too.
But I don’t do this for money anyway. Even though I could make good use of some additional bucks.