• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1323 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.

CCS/TM4C1233H6PZ: went into fault ISR when using ROM function

jerry wu
Prodigy 60 points
Part Number: TM4C1233H6PZ

Tool/software: Code Composer Studio

Hi all,

I encounter a strange problem.

the system "sometimes" jump into fault ISR when the system still processing initial work. we have used this MCU for a very long time, and that's the first time to notice this problem.

the chance of this problem to show up is very low, I have to reset the system, again and again(without any modification to code), to make this bug happen.

after some debugging, I add a bunch of flags between function calls. finally, I found it's ROM_ function call that didn't jump back the right address and trigger a bus fault.

the code shown below, it's really simple. I can't figure out what will cause this to happen.

int main(void){

ROM_FPULazyStackingEnable();
ROM_FPUEnable();


ROM_SysCtlClockSet(SYSCTL_SYSDIV_4|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
ROM_GPIOPinTypeGPIOOutput(GPIO_PORTB_BASE, GPIO_PIN_3);
ROM_GPIOPadConfigSet(GPIO_PORTB_BASE, GPIO_PIN_3, GPIO_STRENGTH_8MA, GPIO_PIN_TYPE_STD);

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);         //the problem occurs at these two functions, not sure which one.
ROM_ADCReferenceSet(ADC0_BASE, ADC_REF_EXT_3V);   //the problem occurs at these two functions, not sure which one.

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOH);
ROM_GPIOPinTypeADC(SYSCTL_PERIPH_GPIOH, GPIO_PIN_3);

.....
.....
.....
.....

}

it happens more easily with the cold reboot, so I'm thinking this might be related to some HW reboot process.

for now, I add 200ms delay before starting the initial process, and this problem is gone. (but not sure it's gone forever, it's already hard to reproduce before adding delay)

Does dose anyone have an idea about this?

  • 0
    TI__Guru*** 135355 points

    Hello Jerry,

    Trying adding this between the two problem API's:

        while(!ROM_SysCtlPeripheralReady(SYSCTL_PERIPH_ADC0))
    {
    }

    I suspect the PeripheralEnable is not executing quickly enough and then you hit Fault ISR when the next call occurs. See if this adjustment resolves the issue.

  • 0 in reply to Ralph Jacobi
    Prodigy 60 points

    Hi Ralph Jacobi,

    thank you! I think you are right.

    because I saw the return address in FAULT_ISR is 0x0100,XXXX. it's still inside ROM function.

    but I'm wondering, why adding a delay before all initial process can remove this problem. seems like the CPU is ready but the ADC module needs more time.

    is there any guideline that can tell me the booting time for each MCU peripheral modules?

    I see "while(!ROM_SysCtlPeripheralReady(SYSCTL_PERIPH_ADC0)){}" is the best solution, but I like to know more about the booting process.

  • 0 in reply to jerry wu
    TI__Guru*** 135355 points

    Hello Jerry,

    This is the guideline that you should account for regarding the peripheral enabling, from the comments of SysCtlPeripheralEnable

    //! \note It takes five clock cycles after the write to enable a peripheral
//! before the the peripheral is actually enabled.  During this time, attempts
//! to access the peripheral result in a bus fault.  Care should be taken
//! to ensure that the peripheral is not accessed during this brief time
//! period.

    In general, it's a good software practice to check for the peripheral to be ready as shown when doing the initial enabling. I am not certain exactly where the variance comes from where it only causes an issue sometimes like after cold boot, but in any case because of the need for five clock cycles, the best way to avoid any issues is to check for the peripheral to pass the Ready check.

  • 0 in reply to Ralph Jacobi
    Prodigy 60 points

    Hi Ralph Jacobi,

    thank you. I see the note in sysctl.c

    I also see the driver user's guide also calling SysCtlPeripheralReady after SysCtlPeripheralEnable, somehow our engineer just forgot to do this, and the problem occurs after we had sold thousands of products.  :(((

    final question, the "clock cycle" means system clock or clock for the peripheral?

  • 0 in reply to jerry wu
    TI__Guru*** 135355 points
    Hello Jerry,

    It should be system clock cycles, because the peripheral clock shouldn't be in play until the peripheral is properly enabled.