I'm trying to diagnose a failing board here at work, and I can't figure out what's going on. When we connect our pin programmer to the board, it takes a program just fine, communicating back and forth, verifying checksums, etc. When we disconnect the programmer and power up the board, it's completely unresponsive. None of the outputs that normally activate when it boots up become active, and it doesn't respond to any external inputs. I can't imagine what could be failing to cause every single i/o to fail, other than the chip simply not booting up at all.

I haven't found anything obviously wrong so far, but I just had a strange idea... could it be something wrong with the external oscillator? If the oscillator wasn't working, would it still take programming instructions from the pin programmer? The MCU is a MSP430F2416TPN. The programmer is a TI "MSP-FET Flash Emulation Tool." Power to the chip checks out just fine (3.3VDC,) and I've confirmed that the reset pin isn't being held low, which was my first thought originally.

Here's a partial schematic showing the power, reset, JTAG, and oscillator connections:

 

You don't need the IC oscillator to enable programming it. At least a Pic doesn't.
Only in run of course.
Max.

 

Have you checked your code?
Start with something simple such as toggle an output pin.

 

Have you checked your code?
Start with something simple such as toggle an output pin.

The code is fine. We've got thousands of these units working - it's just this one board that's a problem right now. Just in case the code in this particular board was somehow corrupted, I've tried reprogramming it several times with each of the two current firmware versions (two firmwares for two different models that share the same board.)

 

The code is fine. We've got thousands of these units working - it's just this one board that's a problem right now. Just in case the code in this particular board was somehow corrupted, I've tried reprogramming it several times with each of the two current firmware versions (two firmwares for two different models that share the same board.)

Well, one in a thousand is pretty good batting average. Scrap the board.

 

The controller has several clock options including an on-chip oscillator. In order for the to operate at least one of the clocks must be enabled and running. Can you tell whether the correct clock selection was made?

 

The controller has several clock options including an on-chip oscillator. In order for the to operate at least one of the clocks must be enabled and running. Can you tell whether the correct clock selection was made?

I'm not entirely sure - I tried scoping the oscillator, looking for a 16kHz sine wave at 0-3.3V p-p. The signal I found was much smaller and much faster, but there was a sine wave (somewhat noisy, but very recognizable.) The scope on the oscillator, while not what I expected, looked about the same for this board as it does on a working board.

Since then I did a little reading on scoping oscillators and learned that my scope may have altered oscillation more than I would have imagined. FWIW, I was using a 10x probe, which is apparently far better for this than a 1x probe. Any idea what sort of p-p voltage I should expect to find on the oscillator? I already suspect that this isn't the real problem, but I'm still interested in understanding this a little better for future use

 

Well, one in a thousand is pretty good batting average. Scrap the board.

It's probably more cost effective to do that than spend too, too many hours on this... still, I hate unsolved mysteries!

Assuming I don't have some major revelation in the next few hours, we'll probably send it back to the assembly house and have them replace the chip. If that still doesn't work, it really might be board scrapping time.

 

Maybe the .hex file your burned to chip was compiled for Debug mode and not release.

If you still have problem then zip and attach the project. I will have a look at it. Maybe it is software problem.

Maybe a problem with the reset circuit. Is the reset circuit working ?

 

Maybe the .hex file your burned to chip was compiled for Debug mode and not release.

The same hex file is working in hundreds of other boards, so it's not that.

Maybe a problem with the reset circuit. Is the reset circuit working ?

No way to tell since it never boots! How would I identify a reset on a board that never operates in the first place? I did check continuity, resistance, and pull up voltage readings related to the reset circuit, and they all appear to be in order.

I eventually gave up on the chip and sent the board back to have the mcu replaced. Hopefully that resolves the issue, because my diagnostic attempts all failed!

 

The same hex file is working in hundreds of other boards, so it's not that.

No way to tell since it never boots! How would I identify a reset on a board that never operates in the first place? I did check continuity, resistance, and pull up voltage readings related to the reset circuit, and they all appear to be in order.

I eventually gave up on the chip and sent the board back to have the mcu replaced. Hopefully that resolves the issue, because my diagnostic attempts all failed!

SMD MCU chip ? Maybe chip is faulty.

 

SMD MCU chip ? Maybe chip is faulty.

That's what I'm hoping. The board isn't back from repair at the assembly house yet, but it should be coming back with a new chip fairly soon. We'll see if that does the trick.