• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 32 subscribers
  • Views 34359 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.

Diagnosing Common Development Problems and Tips & Info for TM4C Devices

Amit Ashara
Guru**** 244380 points
Other Parts Discussed in Thread: UNIFLASH, LMFLASHPROGRAMMER, EK-TM4C123GXL, TM4C123GH6PM

Hello Forum Members,

The Post intends to highlight some of the common problems that you may encounter during product development. More will be Added...

ISSUE#1: GPIO Port C0-3, D7 and F0/E7 Not Working

SOLUTION: The Port Pins C0-3, D7 and F0/E7 are locked pins for specific functionality of JTAG, NMI and NMI respectively. To use them in GPIO or any other function they need to be unlocked and commit register be set. The following example function shows how to unlock and commit the Pins "before" calling any GPIO Pin Configuration Function. Do not forget to include the header files

#include "inc/hw_types.h"

#include "inc/hw_gpio.h"

#include "inc/hw_memmap.h"

TM4C123 Devices Port-C

HWREG(GPIO_PORTC_BASE+GPIO_O_LOCK) = GPIO_LOCK_KEY;

HWREG(GPIO_PORTC_BASE+GPIO_O_CR) |= (GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3);

TM4C123 Devices Port-D

HWREG(GPIO_PORTD_BASE+GPIO_O_LOCK) = GPIO_LOCK_KEY;

HWREG(GPIO_PORTD_BASE+GPIO_O_CR) |= GPIO_PIN_7;

TM4C123 Devices Port-F

HWREG(GPIO_PORTF_BASE+GPIO_O_LOCK) = GPIO_LOCK_KEY;

HWREG(GPIO_PORTF_BASE+GPIO_O_CR) |= GPIO_PIN_0;

TM4C129 Devices Port-C

HWREG(GPIO_PORTC_AHB_BASE+GPIO_O_LOCK) = GPIO_LOCK_KEY;

HWREG(GPIO_PORTC_AHB_BASE+GPIO_O_CR) |= (GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3);

TM4C129 Devices Port-D

HWREG(GPIO_PORTD_AHB_BASE+GPIO_O_LOCK) = GPIO_LOCK_KEY;

HWREG(GPIO_PORTD_AHB_BASE+GPIO_O_CR) |= GPIO_PIN_7;

TM4C129 Devices Port-E

HWREG(GPIO_PORTE_AHB_BASE+GPIO_O_LOCK) = GPIO_LOCK_KEY;

HWREG(GPIO_PORTE_AHB_BASE+GPIO_O_CR) |= GPIO_PIN_7;

NOTE: Changing Port C Pins "will" cause loss of debug as the JTAG Function will be lost

ISSUE#2: After Enabling the Peripheral, the program goes into FaultISR

SOLUTION: The Enable Function writes to the SYSCTL.RCGCxxx Register for the xxx Peripheral. It takes 5 System Clock Cycles after which the peripheral will be addressable. It is advised to put a delay or even better get the Status of Ready from the Peripheral. The following code shows you how to use the better approach...

SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C2);

while(!(SysCtlPeripheralReady(SYSCTL_PERIPH_I2C2)));

ISSUE#3: Spurious Interrupt when the program is restarted.

When the CCS program is restarted using CPU reset, the peripherals are not reset causing them to generate spurious interrupt when the Interrupt is enabled. There are two solutions to this

1. Always use System Reset instead of CPU Reset

2. Add the following lines that will make sure that the peripheral is reset before enabling the clocks. As an example we are showing I2C2 but all peripherals can be coded using the given lines of code

SysCtlPeripheralDisable(SYSCTL_PERIPH_I2C2);

SysCtlPeripheralReset(SYSCTL_PERIPH_I2C2);

SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C2);

while(!(SysCtlPeripheralReady(SYSCTL_PERIPH_I2C2)));

ISSUE#4: JTAG does not connect on my custom board with a Fresh TM4C Part...

More information on this topic is available in the following application note.

ISSUE#5: USB DFU gets detected but does not download.

1. For a TM4C129 with Ethernet PHY enabled and a crystal other than 24-25Mhz, the USB DFU will show up in the device manager but not download. To correct the same add a resistor of 4.89K between RBIAS and GND pin for the ROM Boot Loader to work with the USB DFU

2. Other than above for a TM4C129 and TM4C123 which has the same issue, if the CCSv6 has been installed then the drivers for the USB DFU may have been overwritten. To revert the driver, in the device manager uninstall the USB DFU driver and replace it with the stellaris_icdi_drivers from http://www.ti.com/tool/stellaris_icdi_drivers

ISSUE#6: JTAG connects, the program loads but on RUN JTAG connection breaks..

CAUSE: When a working program stops after making some changes there can be the following issues

1. The System Clock is less than 10 times the JTAG TCK Clock. As an example if the System Clock is 10MHz, the JTAG TCK Clock Frequency must not be more than 1MHz.

2. When porting code between TM4C123 and TM4C129 be careful about configuring the System Clock. The API SysCtlClockSet is meant for TM4C123 only and SysCtlClockFreqSet is meant for TM4C129 only. Even the arguments are different.

3. The JTAG Port Pins may have configured to a non-JTAG Port Select

REMEDY: You would have to run the Device Unlock Sequence using LMFlashProgrammer or UNIFLASH. Please follow the given steps

1. Unpower the board and press reset

2. Power the board but do not release the reset

3. Run the unlock sequence by the "dialog box"

4. Power Cycle the board and then do a Flash Erase Check

The following post will give more details on LMFlashProgrammer Unlock Device View for TM4C123 and TM4C129 Products

ISSUE#7: Code goes to FaultISR..

CAUSE: Fault ISR means that the CPU has hit a condition either internally or externally (w.r.t peripherals) that it cannot resolve

1. The Registers that need to be checked to begin analysis are the NVIC_FAULTSTAT and NVIC_FAULTADDR registers at absolute address 0xE000ED28 and 0xE000ED38.

2. Precise Bus Fault in NVIC_FAULTSTAT would mean that the address of Faulting location is captured in NVIC_FAULTADDR

3. Similarly every fault type mentioned has a cause associated to it, some being easy to diagnose and some being difficult to diagnose.

Refer to the following document to understand Fault Types Better...

http://www.ti.com/lit/pdf/spma043

TIP#1: Make your post informative rather than just going with the issue. Solution tends to arrive faster when a problem statement is formulated with data

1. Give the Full Part Number and Revision of the device

2. Which TivaWare release and IDE/Tools are you using

3. What are the emulators/debugger hardware being used

4. Is it a EK, DK or a Custom Board. If it is a custom board that you have an issue on, then attach the schematics

5. Crystal Frequency being used is sometimes the key...

TIP#2: Avoid Direct Register Access Macro's

TM4C devices support Direct Register Access Macro's which can be seen in inc/tm4c12xxxxx.h file when TivaWare is installed. It works for sure, but one should remember

1. It is easy developing simple codes but when the code grows and the device stops working for some reason, it can be difficult for forum members to debug

2. The code is not readily portable between TM4C123 and TM4C129 as register definition may have changed.

SUGGESTION: Use TivaWare Instead...

TIP#3: Using EK-TM4C123GXL as a Programmer

The EK-TM4C123GXL can be used as a programmer for custom boards containing TM4C12x devices. More info in the following application note

INFO#1: Reduce Issues due to IO Configuration

TM4C supports TI Pin Mux Tool. This tool can be used to correctly generate the IO Configuration Function so that application development does not require debug of user created IO Configuration that may not be working correctly.

INFO#2: USB VID:PID Use

TI allows reuse of TI's USB Vendor Identification Number (VID) and use of TI's assigned USB Product Identification Numbers (PID) under specific conditions. More details can be found in the post below

INFO#3: Using XDS100v2 and XDS200 for executing Device Unlock

In CCSv6.1.1, if the TI Emulator Version is at least 6.0.83.0 then you can use XDS100v2 or XDS200 to unlock the device. The following application notes gives the command line utility and steps to perform device unlock using XDS100v2 and XDS200.

INFO#4: ICDI Drivers for Win10

The Win 10 ICDI drivers have been uploaded to TI website and can be accessed using the details in the following forum post

More to be Added.....

  • 0
    Guru 27285 points

    Amit Ashara said:
    More to be Added.....

     Its my time to add some cent to another issue porting code across series 129 to 123:

    -----> on 123 class avoid use both APB and AHB, FAULT ISR come from accessing peripheral wrong mode, after enabling AHB then APB mode cannot be used due to exclusive access mode, fault is not so simple to trace and NVIC_FAULTADDR point to a nonsense code also if precise bit is set.

    so this code work well on 129 (AHB and APB can coexist) but raise fault ISR on 123( AHB disable APB access):

     ENABLE GPIO APB bus default mode

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

    ENABLE GPIO AHB mode WARNING!!! APB DISABLED After setting AHB mode!!!!

        SysCtlGPIOAHBEnable(SYSCTL_PERIPH_GPIOD);
        SysCtlGPIOAHBEnable(SYSCTL_PERIPH_GPIOB);
        SysCtlGPIOAHBEnable(SYSCTL_PERIPH_GPIOA);

    // These lines added last to check if unused line of port D was
        HWREG(GPIO_PORTD_BASE+GPIO_O_LOCK) = GPIO_LOCK_KEY;

        HWREG(GPIO_PORTD_BASE+GPIO_O_CR) |= GPIO_PIN_7;

        GPIOPinTypeGPIOOutput(SYSCTL_PERIPH_GPIOB, 0xff);

        GPIOPadConfigSet(LCD_DATAH_BASE_D, 0xff, GPIO_STRENGTH_12MA,
                GPIO_PIN_TYPE_STD);
     

     After enabling AHB mode (yellow marked) APB mode cannot be used from (orange marked) and this case bus fault consequently an ISR FAULT where raised to. This is OK on 129 class accepting to share both mode not valid on 123 where APB result disabled causing this bus fault issue.

     From data sheet tm4c123gh6pm june 12 2014 revision on page 258 (D S -T M 4C 123G H6 P M - 1 5 8 4 2 . 2 7 4 1
    S P M S 376E)

    Register 9: GPIO High-Performance Bus Control (GPIOHBCTL), offset 0x06C
    This register controls which internal bus is used to access each GPIO port. When a bit is clear, the
    corresponding GPIO port is accessed across the legacy Advanced Peripheral Bus (APB) bus and
    through the APB memory aperture. When a bit is set, the corresponding port is accessed across
    the Advanced High-Performance Bus (AHB) bus and through the AHB memory aperture. Each
    GPIO port can be individually configured to use AHB or APB, but may be accessed only through
    one aperture. The AHB bus provides better back-to-back access performance than the APB bus.
    The address aperture in the memory map changes for the ports that are enabled for AHB access
    (see Table 10-6 on page 660).
    Important: Ports K-N and P-Q are only available on the AHB bus, and therefore the corresponding
    bits reset to 1. If one of these bits is cleared, the corresponding port is disabled. If any
    of these ports is in use, read-modify-write operations should be used to change the
    value of this register so that these ports remain enabled.

     Edit:

    On porting 129 to 123 remember to reduce clock, overclocking also result in intermittent worstest fault ISR or strange behaviour.

    Edit [feb 22 2015] changed some color where contrast was too much and distracting from successive issue.

  • 0
    Intellectual 320 points

    using a while loop with a variable that you do not control can lead to an infinite loop.

    I suggest adding a counter:

    whileLoopCounter =200; // depends on the delay you need 20, 200, 2000

while(     !(SysCtlPeripheralReady(SYSCTL_PERIPH_I2C2))   &&  (whileLoopCounter>0)  )   {

whileLoopCounter--;  // this will eventually decrement to 0 and break out of the while loop

}

    // check here to see if whileLoopCounter decremented to 0, if it did SYSCTL_PERIPH_I2C2  was never ready, take appropriate action such as flagging the problem or resetting the peripheral.

  • 0 in reply to ClaudeArpin
    TI__Guru**** 244380 points
    Hello Claude,

    An exit routine with a value parsed to it must be placed to make the capture of any such failing scenario traceable. Otherwise the user needs to figure out which while loop caused it.

    Regards
    Amit