• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 79 subscribers
  • Views 1304 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.

msp430f5510 problems on floating Power supply and EMC

seb
Genius 4170 points
Other Parts Discussed in Thread: MSP430F5510, CODECOMPOSER

Hi everyone,

was a long time without problems, but now the time has come for an until yet not understood Problem, probably an interesting one , since a lot of people might stumble upon this, in one or another way, but maybe did not yet realize it.

I did use quite some MSP430 before, without expiriencing such problems, so maybe its the silicon or some mistake i did make in my PCB.

I do use a wall plug power supply, so AC to DC in Europe, 230V to 12 Vdc without connection to protection earth, so due to my XPpower topology i got around 60 V AC floating on my 12V output voltage, if you can imagine what I mean:

The 50 Hz "sinusodial" 2 channels are the + and - voltage, so the difference between those is the violett line ( the one on on the bottom) which is around 12V.

The red line is the interesting thing, this line is connected to an GPIO pin, right now P6.0 on my MSP430F5510, it produces an error signal, which actually does something in my C-code, it triggers an LED, which is an error, I do not want this behaviour.


What I found out additionally, my GPIO P6.0 had no inner pull down activated and externally I had an 1 MegOhm resistor attached, which obvisouly is too high impedance to "surge" the error EMC signals, that are produced due to "antennas" on that pin.

When I solder an 10kOhm instead of the 1MegOhm the behaviour is improving a lot but still is not perfect.

I now did try numerous things, looked through my code ( which is pretty long, includes USB and Modbus protocoll and pretty much the whole periphery of the chipset is used) so there is still a chance that I did write some bad code, but right now i would say my code is 99% :) correct.

So to state a clear problem description:

I want to trigger an LED thru the GPIO pin P6.0 or to be more correct I wanna start an PWM signal out of TimerA, when a signal is applied to P6.0.

In normal opreation, this should occure thruh an external switch that can be attached by a long cable ( >1m ) to that pin, the switch puts around 3V on P6.0, which is of course set as an input.

First error: When I put an unconnected piece of cable to that Pin P6.0 the LED starts going on and off, as you can see in the posted picture, it is because the Pin "sees" a 50Hz logical signal applied to itself, which of course is not the purpose of the pin.

I can better the problem a little bit by lowering its impedance, but that is not the end of the problem.

Second error, much more worse:

Sometimes my code freezes, that means the LED keeps on beeing on or off, but doesnt react anymore, I suggest that somekind of EMC problematic due to a floating device is causing havoc insice the silicon, but I honestly have no clue yet what can be done about that.

I read all the errata and couldnt find anything.

Due to the fact that a lot of people must be using floating power supplies, I guess a lot of people might have the same issues, of course they are sometimes statistically and easy to reset, so maybe some simply didnt pay attention.

To add one more thing: When the whole thing is grounded by USB or another means of protectino earth, no problems occure whatsoever; also when programming with JTAG of course the whole thing is grounded trhou my PC, so it is impossible for me to debug that irregular state.

Thanks for reading, thanks for interest, thanks for your help in advance.

seb

  • 0
    Guru 46710 points

    > switch puts around 3V on P6.0
    You shall consider shorting input. Locate VCC pull-up ~2K resistor close to microcontroller, run 2-wire cable to switch: ground and return signal. This will help >1m cable to NOT become antenna so much.

    >Sometimes my code freezes, that means the LED keeps on beeing on or off, but doesnt react anymore
    Most probably it's still your code. Rather than reading erratas, I would debug my code. "LED keeps on" gives virtually zero information about what actually happens in your code. You shall introduce additional debug indication - 2nd led or something like that. Make "heartbeat" for main application loop out of it.

    >JTAG of course the whole thing is grounded trhou my PC, so it is impossible for me to debug that irregular state
    There are PC's which can be operated without connection to mains/earth, they are called "laptops" :)

  • 0 in reply to Ilmars
    Genius 4170 points
    Thanks for response:

    OK I got thepull up already close to the µC, then the signals runs to the switch and returns into the PCB to the Pin, but now that i write it I do realise, would be far better if I simply pull the signal down, via the switch, that way I shouldnt have such an antenna, thanks for that input, I will try to "work" it into my PCB :) to test it.

    I consider the code frozen, since I am deep into the matter, so lets just assume for now code works reliable, ( although might not be so ) and concentrate on the floating input voltage thing, cause right now I consider this the main point of error.

    And well as a matter fo fact i am working on a laptop right now, I will consider working from the battery after lunchbreak, i did not thought of that, amybe I really am able to step into my error in debug mode,
    .

    I will keep it updated, right now I am trying my code on a olimex evalboard witht he msp5510 , working on an also floating USB powwer supply, I wanna know if I can reproduce the errors on other hardware.
    Oh and another point to consider:
    I did try the error on my PCB with minimal code, so only 4 working lines until a while(1) loop, and I am still able to freeze, without any interrupts or anything, so I am of the believe its something to do with EMC and not with code, since there is simply no possibility to get stuck in the minimal code.
  • 0 in reply to seb
    Guru 46710 points
    >so lets just assume for now code works reliable
    Well... You can search the forum to see loads of "chip does not work" claims which later usually appears to be just software bug/oversight of developer.
  • 0 in reply to Ilmars
    Genius 4170 points
    Update #1:

    Ok Ilmars, thanks for your tips, I did try all of them:
    First I did reprogram to internal pull up and do now pull down with an external switch, this workes better than the before thing, but I still get my Code to freeze.

    Next I tried to debug while floating with the JTAG, so laptop on battery, I had some high hopes for that :) but in the end it did not work as well, as soon as my device stops working, I hit the pause debug button, the MSP430 is also gone from the CodeComposer Studio with cryptic statement like:
    0xF3FFE
    0x0

    I dont know what those addresses or vercotrs are, so I assume the pointer just skips due to.... no clue

    Of course you are right about the LED on gives outsiders no information at all, so I wanted to check back with an heartbeat LED, I do use in an TimerA interrupt, now there are some strange things going on:
    I do see my heartbeat, but when the device stops working, freezes, also the heartbeat LED stops working, this I expected, since I am already convinces its an silicon error :) or something to do with EMC.

    But now the code is stuck, device doestn work, but after like 10seconds, the heartbeat LED goes off, with some very strange undefined state, I have an RGB signal LED, I use the red LED as heartbeat, and I see that is is partly on with the different colours, so I suggest the MSP430 hits some kind of reset level, it does switch some ports to an undefined state I have to assume.

    And very important, in that state I can not recover via the reset pins on the MSP430, I can only exit that unknown behaviour when disconnecting from the whole power supply, that I find truly disturbing.

    And right now not even an Power cycle does help, I think I have seen this before, maybe the Code isnt stored internally in the Flash, nominally i have the 2n2 and 47k pullup on the RST line of the JTAG I think i will alter the capacitor to 1n, just to test.



    Another thing I did wanted to test, I have the MSP430F5510 eval board from olimex here and did try to test my code on this device, I get no code freezing there, of course the hardware differs and the is nothing connected to it, but still. And also my floating AC voltage is about 130V and the one on the Olimex Wallpug USB PSU is 90 Vac, so maybe it has something to do with that, although I highly doubt that.


    Thanks for reading.
  • 0 in reply to seb
    Guru 46710 points
    > heartbeat LED, I do use in an TimerA interrupt
    Your whole application does not run in the interrupt service routines, right? - Then don't put heartbeat in the timer ISR which can live it's own life while everything else is long gone. Application health indicator shall run _in_ the application code.

    >And also my floating AC voltage is about 130V
    Most likely your supply have faulty isolation if you are able to measure such voltages using 1:10 scope probe.

    You shall continue to debug, strip your project down to part which proves either one or another: 1) code bug 2) silicon fault. While you have all the project and "it does not owork", it could be virtually anything.
  • 0 in reply to Ilmars
    Genius 4170 points

    Yep you are right, hearbeat of course runs through, since TimerA is a hardware module, but sometimes I do get the situation that even the heartbeat freezes, but then after 6sec the watchdog recatches and resets my code.

    130Vac is fairly normal, I mean I can measure that on various wall plugs, so I think it has something to do with switching topologies, all the USB wall plaugs should have 90Vac, at least that is what i am measuring, there is nothing wrong with that, at least in Europe it well lies in the specs. They  have currents to protection earth of under 0,1 mA so that is well in the limits, although you can sense, or I could, when wearing metal earplugs to listen to music :) but that is a whole other story.

    Since my Debug process is very not linear, because of the statistically occuring errors, I simply put on the most reliable code and hardware, and try it again wih a earthed output power supply, this gave the most stable results until now. I simply am not able to debug the states, nor to determine where the problem lies, I would say it has nothing to di with the silicon, but I would also say it has nothing to do with my code, maybe I do inflict some high voltage due to the switching button in some awkward switching moment, which causes the MSP to trip, those are just suggestions, as random errors are just a pain in the .. to debug, very frustrating indeed.

    But I got it fairly stable, I did just post here, maybe some others expirienced the same things with floating devices, maybe even TI does know a thing or two. We will see.

    thanks again.

    seb

**Attention** This is a public forum