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

Unlock NMI and power loss

Seppo Rantala
Prodigy 50 points

I'm using TM4C123G LaunchPad Evaluation.

PF0 is used for CAN communication, so NMI is unlocked. The measurements and communication are working fine with unlocking. But after power loss the program is not continuing execution. Also when starting new session after power up with CCS the program goes to FaultISR. If I debug some other program before starting the unlocked NMI program, it won't go to FaultISR.

Do you have idea what is happening and what should be done?

Regards,

Seppo

  • 0
    TI__Guru**** 244400 points

    Hello Seppo,

    When it is in the FaultISR, did you check the FAULTSTAT and FAULTADDR register? The data there will tell what the fault is for?

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Prodigy 50 points

    Hello Amit,

    FAULTSTAT is 0x00008600 and FAULTADDR is 0x40025524. So after checking the manual, FAULTSTAT tell

    Bus Fault Address Register Valid

    Imprecise Data Bus Error

    Precise Data Bus Error

    I don't have any clue what can cause those. How should I continue?

    Thanks for any help!

  • 0 in reply to Seppo Rantala
    Expert 1635 points

    That is the Commit register(GPIOCR) for port F.

    What's happening is difficult to say, if you show some code(from the start) it would be easier.

     

    Keep in mind that when you want to alter the function of the NMI pin, you need to alter the GPIOLOCK, GPIOCR and corresponding registers, in a matter of successive writes, or it will not work.

  • 0 in reply to marc_rir
    TI__Guru**** 244400 points

    Hello Seppo,

    As Marc mentioned there is an access to the GPIOCR register. Based on the faults it seems that it is occurring due to an access to the register before the clock is enabled. You may want to add a small delay loop after enabling the clock to GPIO Port F before accessing any register for the same.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Expert 1635 points

    Hi Amit,

     

    That's what I was thinking also, but wanted to know if he's running straight from the internal oscillator, crystal or from the PLL.

     

    By the way is there some kind of a flag in a register when the PLL has locked, to be sure that the clock is stable, or in general when there’s a stable clock(using either clock source)?

     

    I used Atmel 8-bit µc before, where one can choose a specific delay at start-up(n- clock cycles), before the PC jumps to any code.

  • 0 in reply to marc_rir
    TI__Guru**** 244400 points

    Hello Marc,

    The SYSCTL.PLLSTAT is the indicator of PLL Lock. For peripherals the SysCtlPeripheralReady API "must" be used to ensure that the CPU does not get an Abort due to clocks not yet enabled.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Prodigy 50 points

    Hi Marc and Amit,

    It is running from PLL. I changed the order of initialization so that there is delay between clock to GPIO Port F and register access of it. Now it is working also after power reset.

    Many thanks!

    Seppo