• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 78 subscribers
  • Views 3088 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

eUSCI bit rate setting in SPI mode - confusing formula / description

Dennis Eichmann
Guru 74080 points

Good morning!

Actually I'm setting up a connection between my FR6989 and an EA DOGS102-6 LCD and I'm trying to figure out the best bit rate which consumes less power, but still gives me smooth grafics.

My SMCLK is running at 1.8432MHz and is sourcing UCB1 in SPI mode. The FR6989 uses the eUSCI which, compared to the USCI, uses a different bit rate setting formula - at least the user's guide says it does, actually it does not as I figured out. Or I have misunderstood the description.

This comes from the FR6989 user's guide:

It says, that setting the right prescaler is done by:

Bit clock = ( SMCLK / ( UCBR + 1 ) )

Now I wanted to try 460.8kHz which is a quarter of 1.8432MHz, so the formula is:

460800 = ( 1843200 / ( UCBR + 1 ) )

UCBR = ( ( 1843200 / 460800 ) - 1 )

UCBR = 3

But writing 3 to UCBR register results in a divider of 3 which gives me 614.4kHz at a duty cycle 66% high / 33% low. Having a look at the description of the bit rate setting...

It says that odd UCBR settings result in even divisions with a duty cycle of 50% / 50%. But as far as I remember 3 is odd and it outputs an odd duty cycle. And I think there is a contradiction between the given formula and the description because the text says that the 16bit value forms the prescaler which on the other hand is correct.

Maybe I don't get it, but in my opinion the description in the user's guide is

a) wrong

b) misleading

It seems as if everything is equal to the older USCI modules. The given formula for calculating the bit rate for the USCI was:

BRCLK / ( UCBR0 + ( UCBR1 * 256 ) )

This one was clear to me. Writing 4 into UCBR0 resulted in a division of....surprise...4.

Here are the results for different UCBR values for the eUSCI with SMCLK running at 1.8432MHz:

  • UCBR = 0 results in 1.8432MHz @ 50% high / 50% low
  • UCBR = 1 results in 1.8432MHz @ 50% high / 50% low
  • UCBR = 2 results in 921.6kHz @ 50% high / 50% low
  • UCBR = 3 results in 614.4kHz @ 66% high / 33% low
  • UCBR = 4 results in 460.8kHz @ 50% high / 50% low
  • UCBR = 5 results in 368.64kHz @ 66% high / 33% low
  • UCBR = 6 results in 307.2kHz @ 50% high / 50% low

  • 0
    TI__Guru 68116 points

    Hi Dennis,

    Thanks for the detailed notes - I'll look into this and let you know what I find.

    Regards,

    Katie

  • 0
    Guru 16361 points

    Dennis Eichmann said:
    • UCBR = 0 results in 1.8432MHz @ 50% high / 50% low
    • UCBR = 1 results in 1.8432MHz @ 50% high / 50% low
    • UCBR = 2 results in 921.6kHz @ 50% high / 50% low
    • UCBR = 3 results in 614.4kHz @ 66% high / 33% low
    • UCBR = 4 results in 460.8kHz @ 50% high / 50% low
    • UCBR = 5 results in 368.64kHz @ 66% high / 33% low
    • UCBR = 6 results in 307.2kHz @ 50% high / 50% low

    I'd have expected UCBR = 5 to give 60% high / 40% low (3:2 ratio). Is that what you got when testing?

  • 0 in reply to Robert Cowsill
    Guru 74080 points

    Yes, you are absolutely right! It's 60% / 40%

    Sorry, I didn't measure it last week, I just had a look at the screen of the oscilloscope, but it is 3:2.

    Anyway - if the duty cycle isn't symmetrical, that's OK for me. And that is pointed out in the user's guide and any slave does not give a thing about that. It's more the misleading explanation of how to set the prescaler.

  • 0 in reply to Dennis Eichmann
    Guru 58965 points

    It seems to me that saying Bit clock = ( SMCLK / ( UCBR + 1 ) ) is almost certainly a mistake. The +1 simple should not be there. And, without the +1, this is consistent with the usage of UCBR in the UART mode. There is no logical, technical, or practical reason the UCBR divider acts differently in UART mode vs, SPI mode

    Once you removed that +1. odd becomes even and even becomes odd. No more problems.

    Let's wait to see what Katie finds.

  • 0 in reply to old_cow_yellow
    TI__Guru 68116 points

    Hi all,

    As a quick update: I've found that this description actually goes back to even the F5xx/6xx user's guide www.ti.com/lit/pdf/slau208 which was the first family where some devices had the eUSCI module. So I have done tests on some F6xx parts as well as FR59xx both eUSCI_A and eUSCI_B, and have consistently found the behavior to be matching what you have described where the +1 in the user's guide seems incorrect.

    I am now working with the user's guide owners and some people with more information about the eUSCI module's internals to try to make sure that this was not really ever designed to have this +1 be correct, but rather that the description in the user's guide was just wrong and was where the mistake was introduced (basically making sure this was a documentation bug, not a device design bug - I'm very sure it's the former, but should check anyway). Then we'll get this corrected in the user's guides. This last piece may take a little time though.

    Thanks again for reporting this and all the detailed information you have provided.

    Regards,

    Katie

  • 0 in reply to Katie Pier
    TI__Guru 68116 points

    Hi guys,

    I've got confirmation now that this was a documentation mistake, and we are working to fix this in the next releases of the user's guides.

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Guru 74080 points

    Thank you for that information!

  • 0
    Guru 227245 points

    Katie, are you sure teh 5x/6x family was first with eUSCI?

    I remember seeing it first mentioned in the FR57xx users guide.

    Btw, I could imagine getting 50/50 on 3 too, as a clock transition can happen at a source clock transition. So if the source clock has 50/50 DC...
    Just as it happens for a divider of 1 too.

  • 0 in reply to Jens-Michael Gross
    TI__Guru 68116 points

    Jens-Michael Gross said:

    Katie, are you sure teh 5x/6x family was first with eUSCI?

    I remember seeing it first mentioned in the FR57xx users guide.

    FR57xx and the first F5xx/6xx part with eUSCI were in development and came out at a similar time, I'm not really sure which was first - however I found all User Guides that mention eUSCI had the same description and all needed to be fixed. Looks like it is something that's been propagated through the successive other user's guides that use eUSCI (like FR59xx).

    -Katie

  • 0 in reply to Katie Pier
    Guru 227245 points

    Maybe the F5x family users guide has been updated when the devices were released while the preliminary FR5xx users guide was released earlier, so I noticed the eUSCI there first.

    Yes, copying errors across documents is quite a common problem (in general). And even more, while the original occurrence might be fixed long ago, the copy may remain uncorrected for ages.

    Btw: what happened to the list of documentation ‘quirks’ I sent you quite some time ago? I have a ‘couple’ more collected since. I just have to check whether they may have already been fixed in recent updates. (and I seem to never find the time to do so).

  • 0 in reply to Jens-Michael Gross
    TI__Guru 68116 points

    Hi Jens-Michael,

    I provided your list to document owners a while back, but I'm not sure which things have been updated or not since then.

    Probably the best way to submit most doc feedback is by clicking the "submit documentation feedback" button on the bottom of the datasheets or user's guides. Unfortunately I know that this doesn't necessarily notify you when changes have been made in the docs though. I see that someone else has pointed out the same: http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/362713.aspx This in itself is good feedback and something that I will bring up.

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Guru 227245 points

    Hi Katie,

    My very first finding, the one that brought me here before I figured out that it was a documentation error, I did reported through the feedback link. But shortly after, the feedback link disappeared from the documents. Now it is back, but only for newer documents.

    However, it is a bit cumbersome to fill-in the form for each report. It is rather for occasional single findings. :)

    Yes, lack of feedback makes it a bit difficult to check whether an issue has been fixed, evaluated as no error (this may happen too) or just not yet handled.
    So from time to time, when I update and synchronize my document directory, I go through my list, check the newest document version and remove the topics that have been fixed. This is especially difficult because not only the page but also the chapter numbers sometimes change, so comparing the two revisions is not easy. But the change list at the bottom of most newer documents (thanks that my suggestion was implemented) is a big help.

**Attention** This is a public forum