• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 78 subscribers
  • Views 1701 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.

MSP432 EUSCI registers

Pascal4275
Expert 2045 points

Hello!

I'm playing with MSP432 board, and I have some trouble with registers. The documentation
(page 727) says that the eUSCI_A uart registers are:
00 UCAxCTLW0 for example.
Now when I want to explore the registers in CCS, I would expect EUSCI_A0 to have a
register UCA0CTLW0. However, when unfolding EUSCI_A0, its registers are displayed,
and it starts with UCA3CTLW0. So my first question is: why is it UCA3CTLW0 and not
UCA0CTLW0?

Next, in the unfolded registers, there is a UCA3CTLW0, and the same one with _SPI
extension. But this UCA3CTLW0_SPI is not shown in the documentation. Is there
any pointer about this UCA3CTLW0_SPI register? Is it a simple alias?

Thanks,

Pascal

  • 0
    TI__Guru**** 211947 points
    Hello Pascal,

    I have replicated this behavior on my version of CCS (v6.1.3) and you are correct, this is a bug that shows UCA3 register names under EUSCI_A[0-2]. Further looking into the memory map it is shown that EUSCI_A0_UCA3CTLW0 corresponds to the correct location in memory for UCA0CTLW0, therefore you can write to UCA0CTLW0 in your code and the value of UCA3CTLW0 inside the EUSCI_A0 register window will update correctly. The naming conventions are incorrect but the code operation will work as intended.

    Concerning UCA3CTLW0_SPI, the memory browser once again proves that its location is equivalent to UCA3CTLW0 and simply an alias for that register.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Expert 2045 points
    Hello Ryan!

    Thanks for your reply. In fact, I'm using the logical naming (UCA0CTLW0, UCA1CTL0, etc...) and it seems to work.
    By the way, there is still this problem I had earlier: choosing to treat all files as C++ results in an error because
    the pragmas are not identical in C / C++. I have fixed it by hand, but will it ever be fixed? Many people are likely
    to face the same issue...

    Pascal
  • 0 in reply to Pascal4275
    TI__Guru**** 211947 points

    Hi Pascal,

    I do not have any additional information on that matter outside of what Chester Gillon provided on the other threads, it may be worth asking the C/C++ compiler forum for more details/information.

    Regards,
    Ryan

  • 0 in reply to Pascal4275
    TI__Guru**** 211947 points
    Pascal,

    I've recently learned that TI is already aware of this issue and will release a package which fixes the issue on 6/14 of this year.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Expert 2045 points

    Hello!

    Anyway it works fine now. Apparently it's just a display bug and once you know it,
    you can just wait for a new release.
    I have made this boosterpack (1 LCD, 1 microSD card, i IR receiver). The LCD is
    an extremely low consumption device (without backlight), and 16 gray levels.
    You can notice the gridlines, written in gray, that look thinner than the border.
    The curve is just the ADC input with nothing plugged, therefore this erratic
    behaviour (I was just touching the input pin to check if it works).

    Pascal

**Attention** This is a public forum