MSP430F5659 debugging with CCS6 and MSP-TS430PZ100USB

Unknown device error on a device that was known before usually is a result of a bad user code.
It means the FEET can connect to the device (else you'd get a different error) but while the FET tries to identify the device, connection is lost.
A possible cause (besides a really physically damaged chip) is that in the meantime, the user code has caused the MSP to do a reset.
It happens if the MSP executes the boot code and starts executing the user code faster than the debugger can instruct the FET to attach and identify the device.
Sometimes, using a faster program (such as the Elprotronic software) is sufficient to get hold of the MSP and make a mass erase before the connection is sewered again. Or you can try attaching to the MSP through BSL and do a mass erase.
Of course, if you really damaged the MSP physically, then this doesn't help.

Hello,

thanks for your fast reply, btw. are you a native german, because of your name? Because then I could write in german ;)

since my first problem was resolved by replacing the chip, I have the fear that the chip is physically damaged, but I don't know how this could have happend..
I didn't change anything from my set up, and also the software was not changed and yesterday there was no problem in executing the software. I think i wil try the possibility with the Elptronic software first and then switch to the BSL. If this all doesn't help I think it's the chip, but that would be really bad, because I don't know where the MSP could have been damaged.

Is this also possible with the FlashPro430 Lite version?

I have checked the chip and replaced it again. It was broken. Now everything runs fine again, but I have to be very careful , because I didn't find the reason for it's damage.

Thanks again, for your help!

Yes, I'm German. But most others here aren't. So I keep the official post in English. :)

Indeed, if the software wasn't changed, it is not likely to be the cause.
Another possible problem could be GND level. Is your device powered by an external power supply? There is no isolation between PC and target board. So the target is connected to PC GND level. Typical (cheap) PC power supplies do not provide a 100% isolation to mains. Not harmful to humans but maybe to sensitive electronics. Turning the PC on or off while the target is connected and also connected to a different GND level (a cheap switching 'wall-wart', a scope with connection to earth or even an ESD-grounding plane), this may cause a destructive burst, even if there is no problem during operation. Not too common, but possible, and would fit your description.

For production and field-updating, we use a wireless FET. It is not only convenient, but also provides 100% isolation between the PC and the target. Of course it won't be good for debugging, but I never used a debugger on an MSP anyway (useless when dealing with realtime signals)

English is fine ;).

I have several peripherals connected to the MSP-TS430PZ100USB: The AD7490EVKIT which is powered externally by a 12V SMPS, which makes a very chep impression to me, and a MAX14502EVKIT which is also powered by my USB port. At the beginning I had some different ground levels on the boards but I connected them all together and they are now fine, so that oszilloscope, external supply and notebook are on the same ground level.

One thing that could have caused the destruction of the MSP430 is the fact that there are 5V levels on the AD7490EVKIT board. And I remember that one probe did disconnet itself, after i had to move my set up. So there could have been the problem that the GPIOs got some 5V Signals and that kills the MSP, consulting the datasheet.

But your hint with the realtime signals might solved another "srange thing" I witness: The serial communication with the AD7490 chip is done via USCI in SPI mode with 16MHz CLK and considerring the MSP430F5659 datasheet, i have some ~30ns until the next data can be processed. But i always read 820ns to almost 2µs on the scope and wonder what happens there, because an interrupt can not occur, since I am in an interreput routine and have no nested interreputs.
Might that be a problem because of the debugging mode? I will try a free run on monday and measure again. Thanks for the hint! :)

A little question off the topic: Do you know a good CCS code example in C on setting up the MSP430 with DMA? I started implemeting with the hope that I reduce execution time but have some trouble in getting the DMA channel to run. At the moment I am not sure if the problem lies in setting up the right trigger or writing the correct addresses to the source and destination Register pointers. Maybe you know a good post.

Thanks again for your help!

best regards 

Yes, applying 5V to an MSP input pin is probably deadly. The digital input pins (and analog pins if they have digital operations too) have clamp diodes which route over- or undervoltage to VCC/GND. But these diodes can only take up to 2mA rated current. A series resistor of >1k on the input pins will cause a voltage drop of >2V@2mA, limiting the current and protecting the pins against accidental 5V (or intended - at the expense of this additional current consumption, but for inputs, the series resistor may be as high as 47k or more). However, this clamping current will go to VCC, and if the total circuit current consumption is lower, it will raise VCC (up to Vin-0.3V) and is potentially dangerous too, e.g. if the MSP is in deep sleep mode at the event and doesn't draw more than a few µA from VCC.

Debugging mode shouldn't influence the timing as long as there are no breakpoints (intended, implicit - by single stepping, or internal ones - e.g. for updating a register view or memory view update). It does, however, influence the low power modes, including DCO wakeup times. Even without hitting a breakpoint.
When running SPI with 16MHz (something I have done too for SD card block transfer), one SPI clock cycle takes 62ns. But the USCI will handle a whole byte in one piece, so you have 500ns to put the next byte into TXBUF. However, when running the CPU on 16MHz too, this is only 8 CPU clock cycles, which doesn't let you do much more than just reading memory and putting it into TXBUF. Careful counting of clock cycles is required, since checking for TXIFG will take way too much time, writing too slow will waste bandwidth, writing too fast will result in skipped bates. The writing may have jitter, but the accumulated jitter must not result in less than 8 MCLK cycles per write.
I created a set of inline functions that handle SPI out, in or simultaneous in/out in assembly, to meet the minimum 8MCLK requirement and do things as fast as possible otherwise. But the outcome somewhat depends on the type of data source/destination.
The best method for maximum throughput would indeed be using DMA for the transfer. But the setup overhead makes this only reliable for larger transfers (above ~40-50 bytes).
I don't remember any demo code. In fact problems with setting-up the DMA were the reason why I joined this forum 5 years ago. The reason was an error in the users guide which has been corrected shortly after.
If you use the forum search, you'll find several threads regarding DMA usage, some with (eventually working) code snippets.
It is straightforward, except for a few pits:
- using a source or destination address above 64k requires a monolithic 20bit write operation (the compilers provide specific intrinsics for this)
- configuring the DMA trigger source needs to be done with a word access, so you always handle the triggers for two channels simultaneously (this was the said bug: the original description allowed byte access to only one channel's trigger setting)
- internal triggers have to be edge triggers, but in case of TXBUF you usually have TXIFG already set. You may either write the first byte manually to TXBUF and let the DMA handle only the remaining data, or you can set and clear SWRST after you have set-up the DMA.
- you can't do a transfer from a 16 bit source to an 8 bit destination or v.v. (e.g. a 16 bit ADC result to the x bit TXBUF). You can do the transfer, but then only the LSB is actually read/written, the MSB is discarded or written as 0.
- on some MSPs, you can't access the DMA registers by DMA. (erratum)
- on eUSCI, DMA has sometimes problems with the RXIFG trigger. (erratum)

Thank you for you detailed answers on both subjects! I really appreciate your efforts and help!

As you mentioned I use the DMA now in edge-trigger mode and initialize the first byte send via SPI manually and so the next byte is directly send after the first one via DMA. I improved service time for about 26,2% of the whole 16ch ADC sampling routine.
For the transceive function i used the fact, that previous DMA channels have a higher prioritx in servicing, so I triggered DMA0 for UCA1RXIFG and DMA1 for UCA1TXIFG. This works perfect! After the manual first byte send the DMA0 reads UCA1RXBUF and after servicing, DMA1 transmitts the second byte. After that I manually read UCARXBUF. It works perfect, without any interuption. Here two pictures of that:

First without DMA (polling the UCA1TXIFG and UCA1RXIFG):

and here the second image with DMA:

Thanks for posting your results.
It's good to see that a suggestion did lead to a significant improvement. :)