• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 1226 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3200MOD: New PinMUX Tool won't allow pin 46&47 to be assigned to UART1

Dallas Posey
Intellectual 440 points
Part Number: CC3200MOD
Other Parts Discussed in Thread: CC3200

Apparently, since the recent (12/19/16) update to the PinMUX Tool, pins 46 and 47 cannot be assigned to UART1.  Is that intentional, a bug or am I using the tool wrong now?  Also when I load designs saved under older versions of the tool, I cannot generate the c/h/csv files.

Dallas

  • 0
    TI__Mastermind 38980 points
    Hi Dallas,

    It looks like pins 46 and 47 do not have the ability to be muxed to UART1 (page 15 of the datasheet: www.ti.com/.../cc3200.pdf).

    I actually am not sure the limitations of designs from previous versions of the PinMuxTool. You can ask that question on the CCS/PinMuxTool thread for a complete answer: e2e.ti.com/.../

    Best regards,
    Sarah
  • 0
    Guru 39650 points
    Hi,

    Yes, I think you have right. This sounds like bug in web version of PINmux. I don't see any reason why this pins should not be used as UART1. In desktop version of PINmux (3.0.625) this pins can be assigned.

    Jan
  • 0 in reply to Hnz
    Guru 39650 points
    Hi Sarah,

    No, he uses CC3200MOD. In MOD version are PINs assigned differently.

    Jan
  • 0 in reply to Hnz
    TI__Mastermind 38980 points
    Hi Jan, Dallas,

    If you look in the CC3200MOD data sheet, there is an explanation in section 3.2 Pin Attributes:
    "Table 3-1 lists the pin descriptions of the CC3200MOD module. "DEVICE PIN NO" refers to the pin number of the QFN part CC3200. This is stated here because the QFN pin is referred to in the SDK."

    The SDK still uses the CC3200 device pins, despite what they are mapped to on the MOD device. The PinMuxTool generates code, so it must use the CC3200 assignments. This would make the PinMuxTool confusing, and I can approach the team for a possible solution (notes with an explanation, adding the corresponding MOD pin, etc).

    In any case, please use Table 3.1 in the CC3200MOD data sheet when pinmuxing to match up your code to your layout.

    Best regards,
    Sarah
  • 0 in reply to Sarah P
    Intellectual 440 points

    The problem with that is the layout is done, the second spin boards are in my hand and we have our application wired to pins 46&47 of the MOD.  The hardware guy verified his pin choices using the PinMUX tool which prior to 12/19/16 allowed those assignments without warning or error.  So if we can't use those pins with UART1 in run state (SOP = 000) then we are hosed.  In that case it begs the question: If UART1 can be assigned to those pins by the Bootloader, why can they not be assigned by the application.  And the bootloader does work as I've successfully formatted and programmed the serial flash on these boards.

    Thanks

  • 0 in reply to Dallas Posey
    TI__Mastermind 38980 points

    Hi Dallas,

    If you are talking about the MOD pins 46 and 47, yes, those can be used for UART1. They correspond to pins 55 and 57 in the software and in the PinMuxTool. This is shown in Table 3-1 of the CC3200MOD datasheet  on page 8.

    Best,

    Sarah

  • 0 in reply to Sarah P
    Guru 39650 points
    Hi Sarah,

    Yes, I know that. You don't need explain me obvious things.

    He talk about PINs 46 and 47 of MOD which are physically mapped to PIN_55 and PIN_57 of QFN. When you select CC3200MOD in web pinmux then you add physical pins of MOD not pin of QFN. According datasheet of CC3200 QFN pins PIN_55 and PIN_57 can be used for UART1. But web pinmux not allows set pins 46 and 47 of MOD to UART1. But in QFN is possible set PIN_55 and PIN_57 to UART1. I am almost 100% sure, that this is bug in web pinmux.

    Jan
  • 0 in reply to Hnz
    TI__Mastermind 38980 points
    Hi Jan,

    The MOD still uses the CC3200 SDK. To use physical pins 46 and 47, you will need to pinmux to 55 and 57.

    The PinMuxTool may be misleading, but you are not mapping to the physical pins with that tool. You are adding what the application software thinks are the pins. If that is a recent change without explanation, we can work with the PinMuxTool team to clarify this in the future. For now, UART1 will work with your layout if you use the tool for the QFN muxing listed in the table above.

    Best,
    Sarah
  • 0 in reply to Sarah P
    Guru 39650 points
    Hi Sarah,

    Sorry, in not make sense continue in this debate. You probably not understand what I want say due to my poor English. I only said that is bug in web pinmux for CC3200MOD, not less not more.

    Jan
  • 0 in reply to Hnz
    TI__Mastermind 38980 points

    Hi Jan,

    I'm sorry for the confusion. Would you prefer the PinMuxTool map to the physical pins of the MOD? I don't remember working with the MOD on the previous version of the tool, so I'm not positive if that is what was done before. It does sound that way from Dallas' input though.

    Best,
    Sarah

  • 0 in reply to Hnz
    TI__Mastermind 38980 points
    Hi Jan, Dallas,

    I tried out an older v3 of the tool, and I see that it did use to give you the physical mappings. Once you generated the pinmux.c and .h files, it did the software conversion for you. We will bring this up to the PinMuxTool team.

    Thanks,
    Sarah
  • 0 in reply to Sarah P
    Guru 39650 points

    Hi Sarah,

    From my point of view this is not important for me. I have no problem deal with that.

    I think biggest confusion comes from wrong pin layout image which is in web version. If pins are assigned from QFN point of view, there need to be QFN image and in this case, it not make sense to have MOD package in web pinmux...

    You can compare:

    Jan

  • 0 in reply to Hnz
    Intellectual 440 points
    In this sense I certainly believe Jan is right. Regardless of what calls to to PinTypeUart() the tool generates, when I select the MOD package type, the tool should allow me to configure UART1 to use *MOD* pins 46 &47. Which should generate the following code snippet taken from the previous version of the tool:

    //
    // Configure PIN_55 for UART1 UART1_TX
    //
    PinTypeUART(PIN_55, PIN_MODE_6);

    //
    // Configure PIN_57 for UART1 UART1_RX
    //
    PinTypeUART(PIN_57, PIN_MODE_6);

    Right, those correspond to the chip pins which map to 46 and 47 on the MOD. Cool, no problem. *However*, the version of the tool released on 12/19/16 *does not* allow the assignment of 46&47 when the package type is MOD. The tool should allow assignment from the selected package types perspective. Otherwise, why even have that option in the tool?

    Thanx to you both for the insight,

    Dallas
  • 0 in reply to Dallas Posey
    TI__Mastermind 38980 points
    Hi Dallas, Jan,

    Thank you for the input. We are working with the PinMuxTool to remedy this from the previous version. My concern in this thread was being sure we understood that it did not affect the MOD layout, which may have gotten us off-topic a bit.

    I can post a timeline here for the tool fix when I get it. In the meantime, the previous version 4.0.1223 is available as an offline installer on the wiki: processors.wiki.ti.com/.../TI_PinMux_Tool

    Best regards,
    Sarah
  • 0 in reply to Sarah P
    TI__Mastermind 38980 points
    Hi Dallas, Jan,

    A fix has been added to dev.ti.com. The fix for the offline version should be added by the next revision release.

    Best regards,
    Sarah