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

LX4F232H5QC A3 has PA0 interrupt enabled on reset

John Osen
Genius 3585 points

I am working with identical boards using LX4F232H5QC A3 chips and emulating using CCS 5.2 and a XDS560v2.  Three of the five boards have a problem.  I have specifically set PA6 to interrupt when PA6 is low.  This is how the two 'working' boards interrupt.  On the offending boards I am analyzing, I 'CPU reset' from the debug tab, then I see in the CCS Registers window  that PA0 is set to interrupt on low and both edges:  GPIO_IBE: 0x00000001, GPIO_IM: 0x00000001.

But these conditions are causing continuous interrupts on PortA.  PA0 is configured for CAN.  My apps initilization code should be irrelevant as I am looking at port registers at setup. 

Is this a problem with A3 silicon? 

Errata says nothing about interrupts or PA0.  What it does say about Port A should be fixed in A3 silicon.  Data Sheet says the bits I am worried about should be cleared on reset and hence I should not be seeing this.

  • 0
    Guru 117855 points

    Our belief is that PA0 & PA1 default to UART0 and require special handling/treatment to repurpose.  Here is extract from our M4 datasheet (smaller device than yours) but iirc - applies to yours too.  If not - pardonnez-moi...  Do hope this helps - cannot explain how some boards appear to "work."

    Further - we have noted that multiple pins - among several ports - appear to deviate from their "trusted/listed" POR values.  Have long ago passed this "up chain..."

  • 0 in reply to cb1_mobile
    Guru 117855 points

    Merci beaucoup, monsieur John.  J'avais l'appreciation tres grande. 

    Same tripped us up/others too I'd bet.  Devil lurks in such detail - our group deals w/such by now, "Always" - Combing thru datasheet - and noting each/every pin which requires special, "Care/Handling" - before we allow any programming. 

    We then reduce this to small index card - colored highlight immediately identifies such pins - yields big improvement!

  • 0 in reply to cb1_mobile
    Genius 3585 points

    I am the trailblazer on the LM4F and CSS dev environment.  And that is a great idea to implement ASAP before the next engineer follows me down the trail - like starting in the next two weeks.  Thanks for the pointer.

  • 0 in reply to John Osen
    Guru 117855 points

    You are most welcome - you're also quick - easy to assist.  As iic (xxiot-in-charge) if my mis-steps, mistakes replicate down the line - have only myself to blame!  And small firms cannot afford such inefficiencies - waste time, deplete funds and drain morale. 

    And yet - w/in some larger wasteland - appear same questions - endlessly repeated - suggesting no strong/experienced/corrective hand @ the tiller... 

  • 0 in reply to cb1_mobile
    Genius 5695 points

    CB1:

    Good idea on the color coded lists on index cards Hopefully many others will see this series of posts!  You are right that this problem comes up many times. So far I have been printing the pin assignments and keeping them on top of all the other detritus on my desk.

    Only downside of your idea is that I must review how to print -- and also how to sharpen my crayons. Will work on it!

    Cheers!

  • 0 in reply to Dave Robinson
    Guru 117855 points

    Dave Robinson said:
    I must review how to print -- and also how to sharpen my crayons.

    How jealous am I - institution in which I'm confined frowns on any sharp objects...

    You would expect less than good idea - sacre bleu!