• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 1000 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.

SysCtlPeripheralEnable not always required? TM4C1231H6PZ

Cam Shaw
Intellectual 405 points
Other Parts Discussed in Thread: TM4C1231H6PZ

Hello Everyone,

I have two boards with the same TM4C1231H6PZ processor that are acting differently with the same code, and I am hoping someone can explain why.

The questionable code is as follows:

.

.

.

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOP);
while( ( !SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOP) ) && (PeriphStartup < 5u) )
{
     PeriphStartup++;
}
SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOP);

GPIOPinConfigure(GPIO_PD4_U6RX);
GPIOPinConfigure(GPIO_PD5_U6TX);
GPIOPinTypeUART(GPIO_PORTD_BASE, GPIO_PIN_4 | GPIO_PIN_5);

.

.

.

As you can see I have mistakenly enabled the GPIOP peripheral before accessing the GPIOD peripheral.  On my original hardware this caused no problems. I then programed another processor with the exact same code, and I end up in the fault ISR with NVIC_FAULT_STAT_BFARV bit set and the NVIC_FAULT_STAT_PRECISE bit set.  The address in the NVIC_HFAULT_STAT register is pointing the the GPIOPinConfigure call above.

At no point in the code is the GPIOD peripheral enabled.

My question is why did this not fail on the first board that I was using, and it does fail on the second? I would have expected this problem to have appeared on both processors.

I appreciate the help, and look forward to any responses!

  • 0
    TI__Guru**** 244440 points
    Hello Cam,

    Can you check the SYSCTL register RCGCGPIO for both the boards?

    The erase the flash and power cycle both the boards and then try the code?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 405 points
    Hello Amit,

    I thank you for your quick response. It turns out that there was an eeprom value not set correctly in the processor that was faulting, and it was not executing the same code that was not faulting.

    The enabling of the peripheral is needed or the fault ISR will fire. I was running the same binary, but the code that was actually getting executed was different!

    Thanks again,
    Cam
  • 0 in reply to Cam Shaw
    TI__Guru**** 244440 points
    Hello Cam,

    That's the missing piece of info I never get to know. So try to keep my questions as simple as possible to understand the Root Cause.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Amit Ashara said:
    That's the missing piece of info I never get to know.

    We too!   You are far from alone in that, Amit!

    This poster was detailed in his requirement - and then quick/honest in his diagnostic findings - we cannot say that's "too often" the case.  (spinning wheels, anyeveryone!)

    When code runs outside of expectations - one of our favorite test techniques is to systematically "switch off" peripherals - hoping that the cause agent may be thus isolated and then identified.   Often we find that ARM's provision of, "a wealth of peripherals" - coupled w/user's desire to enable many simultaneously (because that seems the "organized thing to do") opens the door to such issues.

    Would be of interest - and value - to learn "how" poster here made his issue identification...   Good for him - and for reporting here - too!