Spy-By-Wire fails with external oscillator and XT1BYPASS

One thing I noticed in your code is that it does not only omit the crystal startup loop (which of course won't make much sense if the clock signal is from an oscillator) but also does not clear the OFIFG bit, so as soon as OFIE is set, the UNMI ISR is called once.

Also, it is possible that the oscillator, if powered up together with the MSP, has some startup time too, so the waiting loop might be still required.

You should toggle a port pin in the ISR too :)

Your Port_Mapping function disables interrupts at the beginning and re-enables them at the end. This is dangerous. In this case, you enter this function with interrupts already disabled (because this is the reset condition of the CPU) but leave it with interrupts unexpectedly enabled.
You should save current interrupt state before disabling them, and restore it at the end.
Not to mention that NMI is always active, __disable_interrupt() won't block it.

However, I don't see why SBW could be come unstable. Except if your oscillator is clocking the CPU with too-high clock speed. I see the oscillator is 24MHz? maybe you should raise the core voltage from default PMMCOREV_0 to PMMCOREV_1 before exposing the CPU core to 12MHz. (DIVM__2). In theory, 1.8V and PMMCOREV_0 should be enough for 12MHz, but it is at the edge.
Okay, you also tried 1 to 10MHz input, which shouldn't be a problem at all.
Also, what about the cap on VCORE? (470nF) and the blocking capacitors directly on Vcc (4,7µF min.)? On the target board, they should be okay, but better be sure.

Also, there could be a conflict with the target supply. Are the jumpers set correctly (external supply)? Else there might be a problem with voltage levels. In addition, SBW is very sensitive to crosstalk and line impedance/capacitance.

Note that teh debugge rmay halt the internal clocks, depending on configuration. So the ACLK output being off or on might be due to intentional (from debugger point of view) debugger influence.

You are correct, I assumed the startup loop unnecessary since neither oscillator nor DCO were being used.  I do recall observing the UNMI interrupt occurring and the ISR handling it by clearing the fault flags as if in the startup loop.

The 24MHz oscillator is powered-up and stable long (many seconds) before the MSP430 begins execution, but maybe the UCS logic needs a few writes to UCSCTL7 & SFRIFG1 to get it out of some wonky state?

Not MY Port_Mapping function!  That's untouched code from the TI Resource Explorer examples...  That said, it is only called once after POR so I would hazard a guess it's not a problem in this example.

The UCSCTL5 clock dividers are selected before the UCSCTL4 clock source is, so the core shouldn't see more than 12MHz.  I have observed this sequence on the ACLK output pin (I'm assuming MCLK/SMCLK are the same).  Vcore and Vcc capacitors are correct on both the evaluation board and our design.

We have observed SBW to be "brittle" - wish it didn't lock-up CCS.  Unfortunately on our design, the J-TAG pins have been re-purposed, leaving SBW the only way to in-system debug...

At this time I've pretty much given up using the external clock and instead relying on the MSP430's DCO and internal oscillator reference.  Right now I'm deep into another facet of the project (on a completely different processor)...  When I get back to the `51x2 I may look into using the 24MHz as a DCO/FLL reference (instead of using it directly for the internal clocks)

thanks,

 

-neil

Neil Fortney1 said:

You are correct, I assumed the startup loop unnecessary since neither oscillator nor DCO were being used.

Remember that DCOx=0 or DCOx=31 will set DCOOFG. And while DCOOFG is set, OFIFG cannot be cleared. If this happens before MCLK has been successfully switched to XT2, it wont switch and stay on DCO.

Neil Fortney1 said:

maybe the UCS logic needs a few writes to UCSCTL7 & SFRIFG1 to get it out of some wonky state?

If a clock is set to XT2 and XT2OFFG was set once, the clock will fallback to DCO. This fallback will only end after OFIFG has been cleared, for which all OFFG bits have to be clear. Clearing XT2OFFG alone won't be enough.
However, if you witch the clock to XT2 after XT2OFFG has been cleared, it will properly switch, even if OFIFG is still set due to other OFFG bits.
So the sequence of events is important.

Neil Fortney1 said:

Not MY Port_Mapping function!

Well, demo code isn't always perfect. In fact, it almost never is :) But you're right, in your case, it isn't a problem. Problems may arise later if multiple such functions are called when your program grows.
Unexpected behavior is always a source of nasty surprises, especially if it 'worked' (or rather: did not cause problems) in more simple versions of the project. You can spend lots of time for debugging then.

Neil Fortney1 said:

the core shouldn't see more than 12MHz.

Right. I was just suggesting a possible source of problems, since 12MHz is at the upper limit. Normally, there's a safety margin, but devices stray from 'nominal' behavior, and you can bet that not all possible combinations of control settings and operating conditions are tested on every die. better double-check than searching forever in the wrong direction.

Neil Fortney1 said:

We have observed SBW to be "brittle"

Doing ICE with only two signal pins is really a smart thing. Doing so at a still acceptable speed is even smarter. But of course reduction of signal lines and increase of speed increases sensitivity. Especially if the wiring is not a 'ideal' layout on a PCB but rather a wired connection with mechanical connectors and such. So there are limitations in reliability. One can only take it or leave it.

Neil Fortney1 said:

leaving SBW the only way to in-system debug...

There are so many ways to debug. Maybe less convenient, usually less intrusive. I have never used a debugger on an MSP myself. I use JTAG only for programming. It as historical reasons why I didn't start MSP development with a debugger - my first project required hard realtime and a debugger cannot stop the world turning. And I never had a reason to start with it later.

Neil Fortney1 said:

At this time I've pretty much given up using the external clock

I've used external crystals much and never had this kind of problem. Maybe you should try a crystal rather than an oscillator? A 12MHz or 24MHz (fundamental wave) crystal is much cheaper than an oscillator. And while being more sensitive itself (requiring a proper layout) it does not cause as much interference as an oscillator with square wave TTL output.

Of course, the DCO, FLL and REFO are good companions too. If you can accept the resulting clock jitter.

Hey Neil,

I'm guessing you are not using a 24MHz crystal, right? You are using an external clock source from a signal generator?

You might want to try using XT1DRIVE_2 instead of _0 in UCSCTL6 if your source needs to be driven.

 

Let me know if that helps, and I'll continue to look into other possibilities for your error.

 

Thanks,

Ian

Neil Fortney1 said:

maybe the UCS logic needs a few writes to UCSCTL7 & SFRIFG1 to get it out of some wonky state?

Not a number of writes, but after enabling the input, a certain number of oscillations is required to consider the oscillation as stable. IIRC, 1024 subsequent oscillations with a delay no longer than the fault detection time are required before the fault flag can be cleared. (and 8192 for LFXT1). Should be noted somewhere in the clock system chapter.
So you can't really spare the clearing loop.