• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 637 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.

MSP430F4618: Sending data on P3.2. Digital interference?

David Hanney
Prodigy 30 points
Part Number: MSP430F4618
Other Parts Discussed in Thread: MSP-FET

Dear Embedded Community,

My application requires sending data on P3.2. This should appear on pin 69 of the CPU.
It does but this is also pulled high or low from time to time. I've seen it with a scope.
My code goes something like this:

    // Stop watchdog timer
    WDTCTL = WDTPW + WDTHOLD;
    // Light up CPU pin 69
    P3SEL = 0x00;
    P3DIR = 0x0f;
    P3OUT = 0x04;
    // Stop
    for (;;);

And the scope shows this:

These pulled-low events are on-going even after the CPU has hit the endless loop.

Pin 69 is described on the datasheet as "General-purpose digital I/O / slave out/master in of USCI_B0/SPI mode /I2C clock—USCI_B0/I2C mode".

I only want it for "General-purpose digital I/O". Am I getting "I2C clock" too? If so, how can I turn this off?

I'm going a bit mad so any insight would be very welcome! Slight smile

All the best,

David

  • 0
    TI__Genius 16030 points

    Hi David,

    Based on the description of your code, I am unsure why this is happening. It looks like you set the P3SELx and P3DIRx bits correctly. It is hard to see the numbers in your screenshot (the time frequency of the low pulse might shed some light on the issue), but if you do not initialize the I2C module it is unlikely that the pin is outputting the SCL data. Could you post your entire code? What, if anything, is the pin wired to? Is it possible that another device is pulling the line low?

    Looking at an example for this device, it does not take much code to drive an output pin high or low, leaving little room to make a mistake.

    If you wanted to be very sure that this isn't the I2C SCL data, you could try manually disabling the I2C and SPI modules.

  • 0 in reply to Dylan OBrien
    Guru 24625 points

    P3SEL has to be set to allow the I2C module any control over the pin. So it isn't I2C.

    Impossible to say what the problem is with so little to go on. The time axis on that plot has no scale factor. Seconds? Microseconds?

    Is something pulling that pin down or is it just floating? A modest (10K or so) pullup resistor  would clarify that. Are any other pins doing similarly timed odd things?

    Oh, I usually set a LPM mode in an endless loop when I want to stop operation. LPM0 (CPU off) at least. The C runtime usually provides an endless loop if main() returns since there isn't an OS to return to. Which makes the simple loop redundant.

  • 0
    Prodigy 30 points

    Hi Dylan, Hi David,

    This turned out to be a complex and stateful interaction with the custom hardware that embeds this TI CPU.
    Our working hypothesis is that said hardware does not like being powered twice (from MSP-FET and the mains).
    So we are making a custom cable for the MSP-FET as described in www.mouser.com/.../slau278af-1953391.pdf in section 2.1 and 2.2.

    Let's see.


    Thank you for your advice!

    David

  • 0 in reply to David Hanney
    TI__Genius 16030 points

    David,

    If you are comfortable sharing some details of your application, I would appreciate if you could explain the issue further so I can see what exactly the issue is, even if you've found a workaround that suits the needs of your project.

    I am going to add you as a friend so that if you prefer, we can exchange emails about this instead of posting about it in a public forum. Or of course if you'd rather not share at all that is ok too. 

  • 0 in reply to Dylan OBrien
    Prodigy 30 points

    Hi Dylan,

    Thank  you. Here is a scope image with the timestamps included....




    I have come to the conclusion that such pin69 glitching has to be started by a previous hardware writes that put something in "glitch mode". In other words you will not see it just from running the program in my original post above. Sorry about that. Once in "glitch mode" that program and any other program that one builds in Code Composer Studio and sends over the MSP-FET inherits this mode glitches on CPU pin69 as shown.

    Note that you only see this if you are using the MSP-FET. I think it should be classed as an MSP-FET issue (or at least the MSP-FET is one of the necessary conditions). I was using the MSP-FET all the time from CCS and never suspected it was interfering with normal execution until recently. Also "glitch mode" seems to persist almost indefinitely surviving hours without power.

    I know that sounds profoundly odd. I've only become convinced of these strange results over the last week.

    All the best,

    David

**Attention** This is a public forum