TM4C1294NCPDT: Input GPIO drives low during reprogram

svl123 said:

My application cannot tolerate these pins going low for this time and the pins must remain at VCC during the reprogramming sequence.

Greetings,

If not mistaken - this (unwanted) effect has been (or may have been) noted by multiple others - and should be 'searchable' via the 'Search Box' up top.

The work-around was a, 'Highly, Non-Intuitive, Sequencing of the GPIO Set-Up & Configuration.'     And that 'differed' from the normally reliable/robust API.

While you're reporting this effect occurring 'here/now' - my small Tech firm has noted (similar) upon 'other vendors' ARM Cortex MCUs - as well.   (a VERY MINOR occurrence)

Should my direction of the 'Forum Search' not succeed to your satisfaction - you may employ a method which 'ALWAYS WORKS!'    This involves the addition of a small circuit which initially, 'Maintains your GPIO Output as you desire' (i.e. pulled-up, logic high) - yet once sufficient time has passed - automatically, 'Re-Engages' (i.e. connects) that 'balky GPIO.'     (a simple MUX IC is one means of achieving this)

As to "how/why" - it's doubtful that all but a very few 'really know.'    (and likely have 'no interest' in detailing...)

If your forum search succeeds - and then 'works for you" - you should be 'good to go.'     If not - I've supplied an alternative, 'brute force method' guaranteed to, 'Meet your Requirement.'   (standard 50 day, 50 foot warranty...)

[edit]   Just noted that you've employed vendor's RTOS - I don't believe that that RTOS appeared w/in earlier forum posts/fixes - yet I see it as 'unlikely' to plague just a 'pair of pins.'

One more standard point - do you note such an effect upon a 2nd, even 3rd board?    Chasing down 'single board anomalies' is 'never fun' - and (often) yields 'effort beyond justification...'

Hi,

  Can you tell me which pin?

Hi cb1_mobile,

yes, I believe I've seen a similar question on this forum - unfortunately I cannot at this time find it. I believe that the issue there, however, was that an output pin was going low whereas my pins are inputs. I am not sure how much of a difference this makes but it seems that if a pin is configured as an input then it should definitely not be driven from within the MCU because that could lead to damaging hardware.

Would you mind sharing a link to the thread(s) that had (and, hopefully, resolved) this problem for others?

It should also be noted that not all pins exhibit this behavior - the pins in question are PD4 & PD5, whereas I have some others, namely PJ0, PJ1, PP0 and PE4 that are identically configured that to do not do this (i.e. they stay high during the re-programming cycle when pulled up to VCC.)

Thank you, svl123.

Hi back,

I could not recall the 'Full/Total' past posting detail - just that the issue 'Came Close' to yours.    And - sometimes - w/luck - the resolution of 'one issue' extends to others.

Now that you've identified the TWO Pins - the vendor agent should be better able to, 'Conduct that past Search.'     (I operate from a (near) photographic memory) which has 'dimmed somewhat' w/age/responsibility - yet still 'wins me drinks at the bar...'

Do note my 'Alternative Method' - it has been proven to ALWAYS WORK.   (and in fact - is 'SOP' in much of our Military and Medical Device Design Work - where such 'Irregularity MUST be PREVENTED!'

Hi,

  Are you using the LaunchPad board or your custom board? I tried on the launchPad with the PD4 connected to the VDD via a 3.3k pullup resistor and reprogram, I do not see it get pulled low. I use the scope to trigger for a fall edge on PD4. Can you try on your launchPad? 

#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_ints.h"
#include "inc/hw_types.h"
#include "inc/hw_memmap.h"
#include "driverlib/sysctl.h"
#include "driverlib/gpio.h"
#include "driverlib/interrupt.h"
#include "driverlib/rom_map.h"




uint32_t g_ui32SysClock=0;


void SW1Handler (void)
{
    GPIOIntClear(GPIO_PORTD_BASE, GPIO_PIN_4);
}
//*****************************************************************************
//
// Main 'C' Language entry point.  Toggle an LED using TivaWare.
//
//*****************************************************************************


int
main(void)
{

    //
    // Run from the PLL at 120 MHz.
    //
    g_ui32SysClock = SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                       SYSCTL_OSC_MAIN |
                                       SYSCTL_USE_PLL |
                                       SYSCTL_CFG_VCO_480), 120000000);

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);
    while(!(SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOD)));
    GPIOPinTypeGPIOInput(GPIO_PORTD_BASE, GPIO_PIN_4);
//    GPIOPadConfigSet(GPIO_PORTD_BASE, GPIO_PIN_4, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);
    GPIOIntTypeSet(GPIO_PORTD_BASE, GPIO_PIN_4, GPIO_FALLING_EDGE);
    GPIOIntRegister(GPIO_PORTD_BASE, SW1Handler);
    GPIOIntEnable(GPIO_PORTD_BASE, GPIO_INT_PIN_4);
    IntEnable(INT_GPIOD);
    IntMasterEnable();


    //
    // Loop Forever
    //
    while(1)
    {
    }

}

Hi Charles,

First - may we link your 'extended forum presence' to the, End of the Baseball Season - thus your, (expected) Release from 'Camera Duties?'    (Kidding of course - yet technology does 'not always' - come in on a white-horse ...)

Now we note that you've:

Charles Tsai said:

  //  GPIOPadConfigSet(GPIO_PORTD_BASE, GPIO_PIN_4, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);

Is that NOT a 'strong break' from the API?    And - is it not the case - that this user, 'Could not be expected, to 'Break from the API sanctioned use of 'GPIOPadConfigSet()?'     Is it fair to ask - how could he 'possibly know' that (some) yet not all - MCU GPIO would behave in this (unwanted) manner?

What is the result when you:

• employ the standard GPIOPadConfigSet()?
• avoid the installation of such a (low value) pull-up R - tied to those (there were 2) suspect pins?
• repeat this procedure upon PD5 - which poster (also) notes as flawed?

I asked the poster to, 'Repeat this test upon SEVERAL Boards' - so that a (dreaded) Single Board Anomaly (single MCU anomaly - in this case) could be, 'Ruled Out.'

Importantly we should note that poster's 'issue detail' included: "During the reprogramming sequence, before the code is even loaded into the chip, the pins are observed to drive low (to 0) for approximately 20uS before returning back high."     Is it possible that this 'detail' has been missed?

This issue of select MCU GPIO (unwantedly) driving low (usually w/power up) has been past noted - and appears w/in the forum's records...

Hi cb1,

  Thanks for your feedback. I intentionally left the commented line there because I actually tried both - with it commented and with it un-commented. I should have noted in the code that either case I do not see the pin going low when reprogram. 

Hi Charles,

I believe there exists an important point - which (both) you/I have missed!     Poster reports this unwanted behavior occurring during, "Re-Programming Sequence" - and that fact (appears) to have escaped us!   (I've just edited my recent post (13:39) to reflect this requirement.)

What is your result (upon both PD4 & PD5) when the EXTRA (external) pull-up R(s) are removed?

And - might the poster's 'Reprogrammng Sequence' somehow be flawed - would you benefit from seeing that?

Hello again,

I did some experimenting using the TM4C 1294XL launchpad and it seems that this only happens when using the XDS110 debugger to program the board. I used the XDS110 to program the launchpad via U6 and PD4 went low for 20uS before the code was loaded. I then used the Stellaris ICDI option via USB cable to the PC and the board programmed without PD4 driving low as before.

To do this, I used the stock gpiointerrupt_EK_TM4C1294XL_TI project from the resource explorer, and changed the two input pins to PD4 & PD5 with no pullup:

/*
 * Array of Pin configurations
 * NOTE: The order of the pin configurations must coincide with what was
 *       defined in EK_TM4C1294XL.h
 * NOTE: Pins not used for interrupts should be placed at the end of the
 *       array.  Callback entries can be omitted from callbacks array to
 *       reduce memory usage.
 */
GPIO_PinConfig gpioPinConfigs[] = {
    GPIOTiva_PD_4 | GPIO_CFG_IN_NOPULL,
    GPIOTiva_PD_5 | GPIO_CFG_IN_NOPULL,
    GPIOTiva_PN_1 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW,
    GPIOTiva_PN_0 | GPIO_CFG_OUT_STD | GPIO_CFG_OUT_STR_HIGH | GPIO_CFG_OUT_LOW,
};

That's a much appreciated effort - good job.   (and a fast one)

However - young staff here (hooky playing - its 55°F here in Chicago) ask you, "Is it wise to leave PD4 & PD5 (potentially) FLOATING?"    For what reason did you remove the MCU's pull-ups - from both inputs?

Hi,

  Unfortunately, I do not have a XDS110. With that said, I don't understand why the XDS110 will impact the PD4 pin. I have a XDS200. I can try if I can replicate the problem. 

Hi,

  I tried with the XDS200 connected to the U6. I still can't replicate it. Can you please try my attached program?

cb1_mobile,

I removed the pull-up because I have external pull-ups. I can certainly leave this in but, ominously, this happens even when the pin is not being configured at all. If I comment out all references to the input pins PD4 & 5, and then connect them via a  pull-up resistor to VCC, they still drive low for 20uS during the programming sequence.

I also tried this with the pins configured as inputs with pull-ups - no difference.

Charles,

I tried the code you provided. I only used the first 3 lines - did not configure any interrupt features. The problem persists. At this point it appears to not even be a code issue since, as I mentioned, it happens even when the pin is not being configured at all.

Well - that's a 'complete reversal' from the earlier, 'Claim of Success.'    (or I need a refund from Evelyn Wood (past speed reading course)

You have NOT answered - have you a 2nd board to test?   Some cruel fate may have befallen those pins - and 'further time/energy investment' may be 'without proper justification.'

Hi,

  Do you have another launchPad board(s) to try?

  What is your JP4 and JP5 settings? Since you said all other pins are fine except the PD4 and PD5, I look at the board schematic to see anything significant about them. The only thing I see is the below? However, I can't explain why it would make a difference compared to other pins. I have the two jumpers in the default 'horizontal' position. 

Hi cb1_mobile,

I do not unfortunately at this time have a 2nd board to test. I may get another one in the next few days. EDIT: I have tried this on 2 boards, actually - my custom design AND the TM4C1294 launchpad, with both showing the problem.

Charles,

I had the jumpers in the horizontal position. I then removed them entirely and the problem persists.

Also, I cannot say for a fact that ALL other pins are fine. I have only tried PD4, PD5 and PJ0, PJ1, PP0 and PE4.

Hi,

  It will be great if you can try another board as I'm unable to replicate the problem. BTW, I also tried PD0 and no difference from my side.  

  This is my current setup. 

  1. Connect XDS200 to U6. 

  2. Connect PD4 to VCC via a 3.3k pullup resistor

  3. Set the scope to trigger on fall edge of PD4.

  4. In CCS, load a program 

 With the above setup I do not see PD4 go low. 

BTW - crack staff asks, 'How did you discover this?'    (pins go low for only 20µS - thus 'how was this noted?')     [cb1 suggests: - the 'connected' outside world device must have 'Squawked' - even w/the arrival of 'so brief' a signal.    Might a resistor 'lessen' the impact of those 'devil pins' going low?]

Note too - w/both of your boards exhibiting this behavior - any (past or present) introduction of 'some illegal (even transient) input' - may have, 'Caused some degradation to those pins.'   During development - such is always possible - even likely.   (as a defense mechanism - our firm deploys series resistors - upon (most all) GPIO pins.  (inputs or outputs - the presence of such 'anomalies' - under that defense - drives toward ZERO!)

cb1,

A part of my custom board is triggered on an edge and thus triggers were coming in at unexpected times - this is how the issue was discovered.

The custom board showing this behavior is brand new and has undergone very limited testing prior to this. At no time was it exposed to conditions that are outside those described in the datasheets. I can certainly try this on a completely fresh board but do not have high hopes that the behavior will be different.

My next step is to try this on other pins using the launchpad to see if there is a pattern of which pins exhibit this behavior.

svl123 said:

I did some experimenting using the TM4C 1294XL launchpad and it seems that this only happens when using the XDS110 debugger to program the board. I used the XDS110 to program the launchpad via U6 and PD4 went low for 20uS before the code was loaded.

1. CCS 9.2.0.00013 under Windows 10 Pro, with TI Emulators 8.3.0.00003 com.ti.emulation.pack.win64.feature.group and Tiva C Series ARM MCUs 2.1.1.15071 com.ti.tiva_tm4c.setup.win32.feature.group

2. EK-TM4C1294XL with TMDSEMU110-U connected to U6.

3. 10K pull-up on PD4.

4. LSA connected to PD4, set to trigger on falling edge.

5. When loading a program in CCS the LSA doesn't trigger. Used a "hello world" program which doesn't access any peripherals. Tried the following XDS110 JTAG / SWD / cJTAG modes:

- JTAG (1149.1), SWD and cJTAG are disabled
- SWD Mode - Aux COM port is target UART port
- SWD Mode - Aux COM port is target TDO pin

[I checked the LSA configuration was correct, by downloading a program which deliberately toggled PD4 and the LSA triggered as expected]

Can you enable the Debug Server Logs as described in CCS Diagnostic Logs and attach the log of a debug session where PD4 is driven low when loading a program?

Chester Gillon said:

I can't seem to repeat this by using:

1. CCS 9.2.0.00013 under Windows 10 Pro, with TI Emulators 8.3.0.00003 com.ti.emulation.pack.win64.feature.group and Tiva C Series ARM MCUs 2.1.1.15071 com.ti.tiva_tm4c.setup.win32.feature.group

a. CCS 9.2 under Ubuntu. This didn't show the problem.

b. CCS 7.4.0.00015 under Ubuntu with TI Emulators 7.0.100.0 com.ti.emulation.pack.linux.feature.group and Tiva C Series ARM MCUs 2.1.1.15071 com.ti.tiva_tm4c.setup.linux.feature.group. With this software when downloading a program using CCS the LSA shows PD4 goes low for 23 to 27 microseconds when a program is loaded.

Will try other software versions to try and determine which cause the problem.

Bravo - great 'deep dive investigation' - followed by clear narrative - and then (very) nicely summarized by that detailed Table.

Hi Chester,

  We are indebted to your detailed analysis. Looks like the CCS 9.0.1 is acting in a manner that requires further analysis by our CCS team. I will forward this post to our CCS team. In the meantime, I will suggest the OP to switch to the latest CCS 9.2.0 version.

Chester,

Yes, thank you for this analysis. I was using CSS v7.2 for this work. I will update to the latest version.

Thank you, svl123.