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

CCS/TM4C123GH6PGE: TM4C123GH6PGE

satya mishra
Intellectual 330 points
Part Number: TM4C123GH6PGE

Tool/software: Code Composer Studio

Hi All,

My platform is TM4C123GH6PGE

CCS version 6.2,

 I am unable to build my project. I am getting the Reset Faults problem.

in my project,

   i am doing solar water pump project inside this I am using ADC, PWM , SD_CARD , GSM ,LCD in parallel by help of interrupt.

My code is working in perfectway without using SD_CARD or GSM code(any one).

but both(SD_CARD and GSM) using parallel then  Reset_ISR_Fault   occur.

Please Help me ....why ?

this problem is occur?

Thank you! 

  • 0
    TI__Guru**** 158815 points
    Hi Satya,
    Can you first find out what caused the reset by reading the RESC register in the SYSCTL module in the registers browser window? I will suggest before you start either the SC_CARD or GSM code you will first clear the RESC register by writing 0 to it in the registers browser window. You will then continue to run the SC_CARD or GSM code. If you get a reset, read the RESC to find out the cause of the reset.
  • 0 in reply to Charles Tsai
    Intellectual 330 points

    Thanks Sir for giving the Response,
    Sir in my code NO any Syntax error and no any linking error.....
    But problem is occur at a Run Time ( My code is working but affter some time ResetISr_Fault is occur).

    And sir Please tell me Code Syntax(CCS_V6.2) for Clear the RESC register .

  • 0 in reply to satya mishra
    TI__Guru**** 158815 points

    Hi Satya,

    I didn't question if you have a compile/link error. I was asking you to check the RESC register. Please refer to the below screenshot. The RESC register is a register in the SYSCTL module. Make sure the RESC register is clear by writing 0 to the register (you can do this directly in CCS registers browser) and check the RESC after the SD_CARD/GSM code is run.  

  • 0 in reply to Charles Tsai
    Intellectual 330 points

    Thank you sir,

    But sir after doing this process same before problem is occur and CCS debug window showing like as this (in Attach Image).

    So plese send me code syntex for resolving this problem.

                           Thank you!

  • 0 in reply to satya mishra
    TI__Guru**** 158815 points
    Please look at the image you posted. The RESC shows that the the software reset bit is high. It means somewhere in your code you are generating a software reset. Look through your own code and see what might have caused such a software reset. In addition, you can use the watchpoint debug capability to see which instruction might have written to APINT (Application Interrupt and Reset Control) register in the CPU core. The APINT register is at address 0xE000ED0C. Refer to CCS on how to use the watchpoint capability. Once configured, it will watch for the address 0xE000ED0C that is to be written and will halt the CPU. I think these are the capability that you want to acquire during your software development.

    API:
    SysCtlReset() - function to generate software reset
    SysCtlResetBehaviorGet - function to return the types of resets issued
    SysCtlResetCauseClear - function to clear the specified reset bits.

    Refer to the Peripheral Driver Library user's guide for details.

    I don't understand what you meant for the code syntax to resolve the problem.
  • 0 in reply to Charles Tsai
    Guru 117850 points
    Should it "Pass un-noted" that this poster has (now) "appropriated the image" of a "key T.I. staffer" - this registers as "improper" - does it not?
  • 0 in reply to Charles Tsai
    Intellectual 330 points

    yes sir,

     I tried to search.....Why this problem is occur....

    According to me I am using 9 interrupt in my program like as this....


    IntMasterEnable();

    1. IntPrioritySet(INT_TIMER0A, 0x00);

    2. IntPrioritySet(INT_PWM0_0_TM4C123, 0x20);

    3. IntPrioritySet(INT_PWM0_1_TM4C123, 0x40);

    4. IntPrioritySet(INT_PWM0_2_TM4C123, 0x60);

    5. IntPrioritySet(INT_ADC0SS0_TM4C123, 0x80);

    6. IntPrioritySet( INT_HIBERNATE_TM4C123, 0xA0);

    7. IntPrioritySet(INT_TIMER1A, 0xC0);

    8. IntPrioritySet(INT_TIMER2A, 0xE0);

    9. IntPrioritySet(FAULT_SYSTICK, 0xFF);

    may be this problem  is occur by interrupt....

    please suggest me......how to resolve this problem?

  • 0 in reply to satya mishra
    TI__Guru**** 158815 points
    What if you only run the GSM or SD_CARD but with everything else disabled particularly the hibernate?
  • 0 in reply to Charles Tsai
    Intellectual 330 points
    sir,
    My project requirements All process work parallel(like as GSM and SD_CARD Both) .
    and sir I am using the hibernate for SD_CARD purpose.


    All this Modules parallel possible or Not?
  • 0 in reply to satya mishra
    TI__Guru**** 158815 points
    Hi Satya,

    All I'm asking is a method to identify/isolate the problem by finding out if running GSM or SD_CARD alone (without other peripherals running and the device is in normal run mode, not hibernate mode) will cause the reset. I'm not asking you to change your final application requirements. I know that debugging is not simple but I will advice you to start with simple approach. If running GSM or SD_CARD alone will create reset then it will easier to narrow the root cause of the problem. If running GSM/SD_CARD does not cause reset then you can add other peripherals in one by one until you get a reset. This way you will find out which peripheral is the offending module that under some unknown circumstances will result in the problem you are having.
  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:
    Should it "Pass un-noted" that this poster has (now) "appropriated the image" of a "key T.I. staffer" - this registers as "improper" - does it not?

    I don't think it should pass un-noted. Although a behind the scenes contact by TI may be sufficient.
    Robert
  • 0 in reply to Robert Adsett
    Guru 117850 points
    Thank you - do note that such, "behind the scene" effort has been launched.
    More poster time on his code - less on avatar selection - seems advisable...
  • 0 in reply to Charles Tsai
    Intellectual 330 points
    sir,
    My code is running perfect in without sd_card(with GSM) but when i am using the SD_CARD in this condition CPU halt problem is occur.
    and this problem is occur when sd_card code run by Timer interrupt ...
    If I am executing SD_CARD code as a normal condition (without interrupt) then it,s also running fine.
  • 0 in reply to satya mishra
    TI__Guru**** 158815 points
    It is good to hear that you are making some progress. I assume your SD card is accessed via the SPI interface, correct?
    How are you setting up the timer interrupt?
  • 0 in reply to Charles Tsai
    Intellectual 330 points

    Thanks sir,

    yes!
    Hear i am using SPI interface for SD_CARD.
    and Timer interrupt setting like as this.........
    step 1:-
    SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER2);
    SysCtlPeripheralSleepEnable(SYSCTL_PERIPH_TIMER2);
    step2:-
    IntPrioritySet(INT_TIMER2A, 0xc0);
    step3:-
    TimerConfigure(TIMER2_BASE, TIMER_CFG_A_PERIODIC);
    TimerLoadSet(TIMER2_BASE, TIMER_A, 3*SysCtlClockGet());
    IntEnable(INT_TIMER2A);
    TimerIntEnable(TIMER2_BASE, TIMER_TIMA_TIMEOUT);
    step4:-
    TimerEnable(TIMER2_BASE, TIMER_A);

  • 0 in reply to satya mishra
    TI__Guru**** 158815 points
    Hi Satya,
    Not sure if this is the problem. Can you try below instead? If you want to use only the TIMERA as a 16bit timer then you need to use TIMER_CFG_SPLIT_PAIR as to separate the TIMERA and TIMERB.

    TimerConfigure(TIMER2_BASE, TIMER_CFG_SPLIT_PAIR | TIMER_CFG_A_PERIODIC);
  • 0 in reply to Charles Tsai
    Guru 117850 points

    G'Day Charles,

    Should it be noted that poster has set the priority of this Timer Interrupt to be (extremely) low?

    (i.e. "IntPrioritySet(INT_TIMER2A, 0xC0);")    "0xE0" is the very lowest - "0xC0" (rises) - yet ever so slightly!     (might poster have "reversed" his sense of "interrupt priorities?")

  • 0 in reply to cb1_mobile
    TI__Guru**** 158815 points
    Hi cb1,
    Thanks. I didn't look at poster's interrupt priority. Yes, it is low. However, I can't connect the dots as to how the interrupt priority or just having a timer interrupt at all can cause a reset. My suggestion is still for him to monitor the RESC register and step through his code until he gets a reset in which case he can read the cause of the RESC.
  • 0 in reply to Charles Tsai
    Guru 117850 points
    As to "connect the dots" - that's agreed. That said - in such a "Demanding, multi-Peripheral environment" - "Great attention to detail" is required - and as this (rather certain) priority mis-selection suggests - such "attention" may not be (fully) present... (and that's poster's job - not ours...)
  • 0 in reply to Charles Tsai
    Guru 27665 points

    Charles Tsai said:
    My suggestion is still for him to monitor the RESC register and step through his code until he gets a reset in which case he can read the cause of the RESC

    Or if the tools support it a trace with a breakpoint on the reset, at which point you can not only see the cause but walk back to the source (maybe). Not an easy task but at times we have to break out the big tools.

    Robert

  • 0 in reply to Robert Adsett
    TI__Guru**** 158815 points
    Hi Robert,
    That is a good suggestion if the poster has the correct debug probe such as XDS200 or JLink to facilitate tracing via SWO. I'm also wondering if the PC is somehow corrupted during stack return that makes it appear like a reset.
  • 0 in reply to Charles Tsai
    Intellectual 330 points

    Thanks Charles sir and All Community Member(cb1_mobile and Robert Adsett..),

    Finally, I resolved my problem by help of All of you.

    here problem was occur by IntPrioritySet so I increased the priority level and solved this problem.

    Very Very Thanks to ALL!

  • 0 in reply to satya mishra
    TI__Guru**** 158815 points
    Hi Satya,
    Glad your problem is solved. Credit goes to cb1 who questioned the priority level. However, I would like to know why the low interrupt priority level would cause the reset. Could you explain as I don't.
  • 0 in reply to Charles Tsai
    Guru 117850 points

    More GREEN flows here - today - than w/in the Chicago River on, "St. Paddy's DAY!"       (when the city "burns money to "DYE the fool (Asian Carp infested) river" GREEN!)

    It remains (unexplainable) - how & why the API creators - chose the "Lowest Value" to represent the "Highest ISR Priority!"       Such is "Krazy Making" (almost like "Dying a River") - is it not?

    (should the ARM internals (seek) such low values - such could be easily achieved via "bit inversion" - clearly trumping the "unnatural/unexpected!"