• Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 915 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.

PinMux strange pin conflict

Dan K
Expert 1210 points

I have gotten Stellaris PinMux (Version 1.0.1) confused somehow! In trying out the pin configuration tool, I got it to generate a pin collision conflict that I can't get it to resolve. In particular, there's a conflict on PB7 with SSI2TX, but T0CCP1 and GPIO for pin 4 are not enabled. When I disable the SSI2 module, PB7 is still considered enabled by something! I have included the Pin file in which it appears there are two lines in it describing PB7/pin 4:

PB7,4,4,cEnabled
PB7,4,SSI2TX,cEnabled

The first PB7 line appears odd compared to the rest of the lines in the file. In the Log Window, when reloading the Pin file, the relevant complaints are:

16: 4 enabled by auto-selector in port PB7, pin 4
17: SSI2TX generated a collision with Enabled in port PB7, pin 4

7128.pins1.pin.txt

Dan

  • Guru 47900 points

    Sorry to read of your plight.  We use different M4F (231 - 64 pin QFP variant) and have had no trouble w/manually setting-up PB6 & PB7 as PWM Module 0, PWM Generator 0.  We employed the, "normal/customary" GPIOPinConfigure() and GPIOPinType() in that successful effort.  So - light may shine @ end of your tunnel.

    You are one of the very early adopters of this new tool.  And - as you are finding - such "pioneers" sometimes absorb arrows - often in tender spots... 

    What to do?  Suggest that you devise a very limited, simple program which only deals w/troubled PB7.  (a PB7 "blinky" - if you will)  Use "normal/customary" set-up of this Port & Pin.  Once this verifies - you may systematically enable successive ports & pins - testing/verifying every step of the way.

    May be time to let vendor firm "complete" their test/verify - minus further Dan K blood-stains across this rough prairie...

     

     

  • Expert 1210 points

    Additional followup:

    I found another case, which may be related, where dual lines are output for a signal pin in the Pin file output and misleading legend is shown in the GUI display.

    Here's how to reproduce the symptoms:

    1. Start Sellaris PinMux Utility
    2. Select Device Series "LM4F12 series"
    3. Select Device "LM4F120H5QR"
    4. "Go"
    5. In the Timer Module, select "Timer4"
    6. Select  NO to both JTAG_warning dialogs

    At this time, despite declining to reconfigure the JTAG pins, the GUI's Timer4 module appears successfully enabled as indicated by its blue Timer4 text and green boxes for PC0 and PC1 pins boxes. However, the actual text for PC0/PC1 and their pin #'s are now white (barely readable). The same result appears when selecting the Timer5 module in the same manner declining JTAG reconfiguration. This is shown in the following image:

    The Log Window does *not* give any output when not selecting the pins in this way. However, in trying to subsequently configure any one of those JTAG pins as a GPIO pin, a collision complaint is displayed and in the output Pin file (included below), it can be seen that the pins appear to be configured for both the JTAG and the Timer functions (when reloading that pin file, the GUI display appears normal for those Timer pins as enabled).

    3010.pins4.pin.txt

    Dan

  • in reply to Dan K
    TI__Genius 12380 points

    Hello Dan,

    Thank you for brining this to our attention. We are in the process of investigating this issue, and have added this to our list of improvements for the next release of the Pin Mux Utility.