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

Unwanted I/O activity on Stellaris Launchpad

Pete Owen
Prodigy 40 points

Hi,

I'm working towards using a Stellaris Launchpad as a master to control eight TI C2000 BLDC eval boards, using SPI.  I had success testing with the Launchpad and one slave, but I've run into problems while trying to configure additional I/O pins as slave selects (one for each BLDC board).  It seems that I have somehow "corrupted" the processor, such that the SPI pins continue to toggle in a meaningless pattern, as observed with an oscope, even when the processor execution is paused in the debug state.  I am using CCS V5.3, on a windows XP machine.  

I've tried using the LM Flash tool to both:

1) Erase flash with verify: the erase verify passed but the pin activity continues even after power cycle.

2) Debug port unlock, as instructed towards the bottom of this post: http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/61036.aspx --- this also did not stop the pin activity even after the power cycle.  I used the blizzard option.

I plan to write a simple program to set all pins as input and see if this has any effect on the I/O activity.  Any other suggestions on how to do a "hard" or "low level" reset of the board? 

Thanks for any advice,

Pete

  • 0
    Guru 47900 points

    Over the years group/myself have made our share of mistakes - never observed what you report.  Unsure if its possible to "corrupt" and produce such outputs... 

    Your report of uncertainty with regard to the LM Flash tool also is unsettling.  My sense is that this may instead be a "power issue" - with the MCU returning repeatedly into Reset. 

    Your chosen board has had reports of improper USB connector attachment - which could exactly cause the symptoms described!  In addition - this board strives for flexibility (2 USB connectors + a switch) but you have to get these both "right."  In the excitement of a new project - necessary detail/procedures may be lost.  I'd take a "magnified" look @ both USB connectors (with my ESD wrist strap emplaced) if I were you.

    There are certain "gotchas" unique to your board - one being several port pins being "joined."  Best to avoid their selection.  A recent post identified that board's header pins as being somewhat "thinner" than normal/customary - thus your mating interconnect may be intermittent.  http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/901/t/246176.aspx  (read from post's end)

    Board to board interconnect - as you describe - also demands discipline.  Ideally - each/every board should be powered from the same (adequate) power-source - to prevent one board powering up before the other(s).  (MCU unhappy when its pins are driven - while it is unbiased/un-powered)

    On the SW side - harvesting additional SPI Slave Selects is usually done by declaring each as GPIO output - not as a member of the SPI configuration.  Yet still - can't imagine what sin/violation would cause the "meaningless pattern" you observed... 

    Power/Connector issue is "top suspect" on this reporter's list...

     

     

  • 0 in reply to cb1
    TI__Intellectual 2615 points

    cb1- said:
    Ideally - each/every board should be powered from the same (adequate) power-source - to prevent one board powering up before the other(s).  (MCU unhappy when its pins are driven - while it is unbiased/un-powered)

    Pete,

    If you isolate the board and connect only an o-scope/analyzer to the SPI pins, do you still see the same strange behavior after the erase/verify?  

    --Miles

     

  • 0 in reply to Stellaris Miles
    Prodigy 40 points

    cb1/Miles,

    Thanks for the replies. My issues were power/ground related, as cb1 guessed: the solution was to stop powering the Launchpad from the USB port (I'm now using a bench supply) and to use a grounded supply on the laptop.  I was clued in when the behavior went away when I unplugged the two-prong A/C adapter for my laptop, but immediately returned when I plugged it back in- I believe it was causing ground loop noise.  I had been running without issue for some time prior, but I must have changed my grounding which resulted in the apparent I/O chaos.  Thank you for your help, I'll post back if I have further issues.

    By the way, I did notice that some pins were joined, I removed resistors R9 and R10, and I also noticed that the header pins are thinner than a normal square pin, I'll keep an eye out for loose connections.

    Thanks again!

    Pete

  • 0 in reply to Pete Owen
    Guru 117855 points

    Thank you, Sir.  Power seems so easy - yet is so often "cause agent" for such strange/exotic behavior...