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.

Problems with TM4C123BH6PM's SSI interface

Other Parts Discussed in Thread: TM4C123BH6PM, EK-TM4C123GXL

Hi, I'm using TM4C123BH6PM to interface with accelerometer and gyroscope using SSI interface.

(Accelerometer : LIS331DLH, Gyroscope : L3G4200 from STMicro)

0830.SSI problem project.zip

The following source code above is about positioning.

When the EK-TM4C123GXL board(wired with acceleerometer and gyroscope

plus DC motor and a servo motor from a RC Car.)

moves more than 2 meters to the Y-axis, the PWM and the ADC is used to rotate left

and starts calculating the angle using the gyroscope.

Also, when the calculated angle becomes bigger than 90 degrees,

the code runs to a infinite loop with a decreased PWM duty.

Testing with the EK-TM4C123GXL board gives results as I thought.

( Move about 2 meters => Turn left 90 degrees  =>Stop, infinite loop)

However, while using the TM4C123BH6PM with the same source code,

sometimes the data from these MEMs sensors give terrible results.

For example, the gyroscope's yaw value (Z-axis) is almost constantly 15~16.

Due to this, the car goes round in circles. (about 2 circles) and stops later.

Also the acceleormeter sometimes acts like the gyroscope too.

(It gives constant acceleration value while moving.)

+) The sensors are well soldered. When reading the Who Am I register from the sensor, it returns normally.

I can only think of hardware problems. The file below is the schematic.

8424.schematic.pdf

However, I designed quite similar to the EK-TM4C123GXL board and can't understand why mine doesn't work...

Could it be a hardware problem?

What could be the reason?

Appreciate your help.

Regards Min-Ku

+) The tested condition.

When I used the EK-TM4C123GXL board, I connected with the USB.

I didn't used external battery source.

However, testing with the TM4C123BH6PM, I use a 7.4V LiPo battery (2 cell, 850mAh).

This 7.4V goes to the motor driver and 5V regulator. The 5V also goes to 3.3V regulator.

  • Hello Min-Ku,

    Would it be better to use the 7.4V battery pack to the EK-TM4C123 to rule out any issue from the battery pack powering the uC and the motor?

    Regards

    Amit

  • Min-Ku Yeo said:

    using the TM4C123BH6PM with the same source code,

    sometimes the data from these MEMs sensors give terrible results.

    Well - that's better than famed, "MCU does not work!" but would be strengthened if you had stated that - at times - correct results arrived!  I don't believe that the battery power source is the culprit here - as it appears you can successfully harvest, "Who am I" transactions.  Note that 7V4 is "close" to older, linear 5V Reg's, "drop-out point" if reasonable (or beyond) currents flow. (if that 5V0 stems from switcher - there's no issue)

    More likely - on your "one-off" proto board - is noise generation/pickup - possibly missing/inadequate bypass Cs and all other, "usual board proto" suspects.  You don't identify this 2nd board as launchpad - thus your remote staff must guess - never fast/efficient/fun.  (but surely saved "you" time/effort/consideration...not so your ever hapless, remote staff!)

    You built more than one proto board - did you not?  Diagnosing (just one) never fun - having 2,3 enables "A-B" comparison - rules out (always dreaded) "single board anomaly!"  (boring to troubleshoot improperly made, soldered, routed, populated - such board...)  (sorry - but that's a fact - we no longer do that for {pardon} paying clients!)

    Had you thought to disable all "noise generating" components (i.e. motors/actuators) and use that same SSI channel to "transact" with simple eeprom or gpio extender SSI chip?  So much is in play here - "KISS" quickly/efficiently enables you to determine that "something" is right.  Then - moving systematically - you (usually) may better identify issue source.

    When all else fails serious review of the "fine manual" (MCU) - looking especially for any differences between early and newer MCU - often proves insightful.  (i.e. might one/several pins serve different roles - those 2 MCUs?)

    Beware - vendor here is not obligated to provide multi-post - back-forth - to diagnose clear, application issues as you present.  Time spent on your, "non vendor specific" fine detail - necessarily subtracts from vendor's time/energy to satisfy the more appropriate MCU normal/customary use cases...

  • Hello Amit.

    I'll try that soon. It's that I don't have extra regulators...

    I'll do it as fast as I can.

    Regards, Min-Ku

  • Hello cb_

    Before starting, I have to apologize to you that you're right.

    TI (this community) isn't obligated to provide post for my non vendor product.

    Sorry for the inconvenience. I know this is a stuff I should solve by my own.

    Getting stuck on something for couple of weeks made me post this question. Sorry for that.

    In short, I do have something suspicious.

    Whenever I disable the PWM module, the MEMs sensors worked fine though.

    As you mentioned, the noise generating component (which in my case the DC and the servo motor?)

    seems to bother the sensors.

    May I ask you some information how to block these noises?

    I really don't have a clue to solve this....

    I think I have to add some Caps (100uF~1000uF) near the regulator and the motor,

    but I don't know where exactly I should connect the Caps.

    May I ask you a link to aid my study?

    I would be really thankful to you.

    -Best Regards, Min-Ku

  • Min-Ku Yeo said:

    Whenever I disable the PWM module, the MEMs sensors worked fine though.

     

    That is an important note.  A couple of questions

    • Did you run the pwm on the previous board?
    • Did you run the motors on the previous board?
    • Is your micro power supply diode protected from the droop of the DC bus? (i.e. if the DC bus drops suddenly will the power to the regulators also drop or is there a diode so current only flows into the board not out of it.)
    • If you disconnect the PWM signal from the power drivers do you still have a problem?
    • If you disconnect the power drivers from the motors do you still have a problem?
    • Do you have a filter on the micro's main DC prower input?
    • Do you have a filter from the battery to the motor DC bus?
    • Do you have a large local capacitance on the DCbus for the motor?
    • Do you have high frequency capacitors on the DC bus for the motor?
    • Have you 'scoped the power supply for the micro and the sensors under failure conditions?
    • Do you have a good PCB for your power circuits?

    Note that filters are not always a good thing.

  • @Robert,

    First my early identification of likely "noise issue" - now joined/seconded by you - yet I fear that the playing field has moved bit afar from, normal/customary MCU issue.

    This is now (very likely) an MCU System Design issue - and may extend almost w/out limit.

    This vendor has a well-thought (imho) App Note covering such, MCU System Issues. 

    @Min-Ku,

    Sought only to alert you that we all must employ this rare/valued forum resource w/great care.  (no apology was asked - nice that you agree w/some forum rules/regs)   Search this vendor's (admittedly huge) site for System Issues when designing w/Stellaris and/or Tiva MCUs.  (can't recall the exact title - but the document is reasonably complete and deals w/"inside tech issues" unlikely to be known by "outsiders" such as Robert/myself. 

    When you locate that document - presenting doc's name & link here - would be useful to others... (excellent forum use!)

    I'll make one last - extra normal MCU issue - gasp/"swag."   Employ opto couplers for all critical digital signals routed from MCU to motor control (fast optos if PWM freq. is > ~10KHz) and isolate your motor power supply from the MCU power supply.  (may be simplest w/2 separate supplies - and separate & independent grounds!)  Once you're up/running - you can systematically "relax" certain of this design "excess" - and thus determine, "If, Where, and How" such isolation methods are best applied or discarded...

    Good luck...