• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 627 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.

Running the MSP430F2013 WITHOUT the USB Stick, on a different power supply

Matthew Wasko
Intellectual 1670 points
Other Parts Discussed in Thread: MSP430F2013

Hi all, 

I have just recently finished a preliminary design for a MCU to be connected to a buck converter chip, which will eventually turn the various bucks on and off in various sequences based on the situation. For now, I have an initialization function that does among other things, immediately turns off all of the bucks, and turns each one of them on in order (B1, B2, B3, B4, B5) with a one second delay in between each, followed by a long delay of three seconds, followed by turning off B5. Now, some background information on my setup before I explain the issue in detail:

I2C Master: MSP430F2013 (the one with the little USB stick for debugging) - for simple programs like blinking LEDs, the USB stick powers the device unless an external voltage source is applied, in which case it doesn't need to be connected to the USB stick. With the USB stick connected to the MCU, the voltage is about 3.3V.

I2C Slave: Buck Converter Chip - On its own, the chip can be turned on by plugging it into it's own USB cable which connects to the computer. There is a jumper that can change the voltage to either 3.3V or 5V, both of which work for the chip (HOWEVER, I do not think this jumper matters, as it doesn't seem to affect the voltage of the MCU as I will explain later). Immediately when plugged in, all five of the bucks turn on - B5 specifically turns on to 1.9V.

Overall setup: At this point, I have connected the MSP430F2013 MCU to the buck converter chip. I still need to plug in the USB cable to the buck converter chip, but the MCU is connected to this chip's VI/O pin, which turns it on as well. I reconnect the USB stick to the MCU in order to reload or change the program on the MCU. With just the USB STICK plugged in, the MCU can still do simple things like blink its LED, but it cannot properly communicate with the buck converter chip without the USB cable plugged in...

Here is the problem: I need the MCU to properly do its initialization function RIGHT WHEN the buck converter is powered on, without the USB STICK. However, with the USB STICK OFF and the USB CABLE ON, this only works some of the time. Some observations:

1. When the USB CABLE is plugged in, I get the proper init sequence all the time when I run the program with the USB STICK also plugged in. Also when I remove the USB STICK and simply plug it back in, the program runs correctly all the time. One interesting thing is that sometimes when i REMOVE the stick, it works properly, and sometimes, I can reconnect the stick for a split second and remove it, and sometimes that will work as well. My assumptions are that whatever is loaded on the MCU will restart from the beginning (or at least its supposed to) when it gets some kind of power. Could someone verify that with me? Could someone also explain the semi-randomness when I remove or plug-in-and-back-out-immediately the USB STICK?

2. The real problem occurs when I only want the USB CABLE and NOT the USB STICK, which is my end goal. In this case, sometimes the init sequence will work properly, but other times it won't. It fails by either not immediately turning off all the bucks (and B5 stays at 1.9V the entire time), or the bucks turn off but B5 goes back too 1.9V too soon, or at the very end B5 doesn't get turned off again (staying at 1.9V). Another observation is that in this scenario (USB CABLE but NO USB STICK), it will continue to work when I unplug-plugin the USB CABLE for a certain number of tries (although it may not even work once), followed by not working again no matter how many times I try - I have reset everything with the USB STICK in hopes that it can work again with the USB STICK removed (It will be successful, successful, successful, failure, failure... NOT alternating between working and not working). It works completely fine about less than 50% of the time, and I need it to work 100% of the time. I haven't observed much differences when I switch the jumper from the 3.3V version to the 5V version so I do not think that is an issue. Also, in the case for just USB STICK plugged in and the case for just USB CABLE plugged in, it seems like the Vcc level for my MCU (the 1st pin on MSP430F2013) reads 3.3V on the multimeter for BOTH scenarios, which makes it seem like in both cases it should work perfectly. However, this is not the case and I need some insight as to why that is, and why there seems to be so much randomness in so many different scenarios. Any help would be greatly appreciated!

Thanks,

Matt

P.S. How fast do common multimeters react to changes in voltages? Sometimes, the multimeter seems to change slower than expected, even though I am sure that the sequence properly ran. If someone could explain this as well, it would help me understand how reliable my multimeter probably is, as that is essentially what I am using for debugging at this point.

  • 0
    Guru 46710 points

    It seems like you don't have proper reset circuit for MSP430F2013. USB stick reset your chip correctly byt your chip alone fail to start properly.

  • 0 in reply to Ilmars
    TI__Intellectual 1670 points

    Hi Ilmars,

    That seems very plausible. Can anyone here verify this, and/or explain to me how to add a reset for my MSP430F2013? Example code would be very helpful.

    Matt

  • 0 in reply to Matthew Wasko
    Guru 227245 points

    Without extenal reset logic, manyMSPs have problems when the supply voltage rises slowly. Which is the case for many switching power supplies. THe MSP then starts after the brownout voltage is reached, but VCC still isn't high enough for proper operation after the reset delay, and crashes. Some MSPs don't have a brownout detection at all.

    The solution is to apply a pullup resistor and a pulldown capacitro at the reset pin. This makes the reset pin rising slower than VCC, keeping the MSP in reset state until VCC has stopped rising (hopefully at the correct level :) )

  • 0 in reply to Jens-Michael Gross
    TI__Intellectual 1670 points

    Throughout the course of the day I was able to get it working:

    1. Part of the problem was the chip I was using for the slave device. Sometimes (today it seemed like most of the time), the chip would do some kind of reset that would raise the buck voltage back up to its original level, even though my MSP430 told it to turn off. Strange, but I just switched the chip and that problem went away.

    2. I also added a function that would continue writing to the register on the chip until it knew that it was successfully written, which was done by reading that register right after attempting to write to it, to see if the data in the register now matched what we were trying to write into it. I am not entirely sure if this helped with the functionality of my MSP430 to function independently on the chip without the USB STICK, but I did it anyways. Is this a reasonable thing to do when doing writes - to continuously write to them until they read the correct value, in case of random NACKs/failed writes???

    3. Just an observation here, but now I have the MSP430 AND slave device chip functioning just on the USB CABLE. However, when I try to run everything with the USB STICK also connected as well, it doesn't always work as I would expect. However, I am lazy and now have what I was aiming for, which is good enough for me for now, but I just wanted to point that out in case anyone had anything to say about that.

    Thanks,

    Matt

  • 0 in reply to Matthew Wasko
    Guru 227245 points

    Matthew Wasko said:
    Is this a reasonable thing to do when doing writes - to continuously write to them until they read the correct value, in case of random NACKs/failed writes???

    Normally, if properly performed, a write should always succeed (except if the slave datasheet tells that it might fail and you have to check or perhaps get a result message that signals failure).
    For high-safety systems, such a loop might be mandatory, just to detect any failure, as unlikely as it might be. (e.g. medical appplications). But normally, is hould be superfluous.
    So likely, something else is still wrong. Maybe you do not obey certain timing requirements (see the slave datasheet)

    Matthew Wasko said:
    the chip would do some kind of reset that would raise the buck voltage back up to its original level, even though my MSP430 told it to turn off.

    Maybe bad soldering? Or a crack in the signal line? Things like this can lead to unreliable data transfer and even bogus transfers (like receiving somehting that nobody sent)

  • 0 in reply to Jens-Michael Gross
    TI__Intellectual 1670 points

    Thanks for the input. I found that make a continuous write function was unnecessary. It appears as though all of my writes are working the first time. I just assumed that failed writes were somewhat common.

    I don't know what it is about the other chip, but I never really observed the behavior of the chip on a larger time scale. Previously I just looked at one write and checked to see if the multimeter showed a drop in voltage. But then again, eventually I would have seen the voltage go back up, but there's a chance I just didn't catch it.

    Anyways thanks for all the help everyone,

    Matt

**Attention** This is a public forum