Am 12.03.2013 00:31, schrieb Nils Faerber: > Then I extended my testcode with some SPI init code, a ~1kbyte buffer in > RAM and a polling SPI write of that buffer to the SPI - BANG!
so without knowing details, two possible causes come to mind: - wrong pin init, creating a short - to much RAM used so that stack and data overlay and cause crashes (resets) > MSP430_Initialize: /dev/ttyACM3 > Firmware version is 30203015 > MSP430_VCC: 1800 mV this is probably not good. most development boards run at 3.0 or 3.3V. 1.8V is the minimum for typical MSP430's so its a possible value but suspicious. > MSP430_OpenDevice > tilib: MSP430_OpenDevice: Security Fuse has been blown (error = 30) > tilib: device initialization failed this can be caused by the low VCC when the signals of the JTAG and MSP430 are not matching and the communication gets faulty because of that. i've also seen MSP430 were somehow the JTAG got messed up and they needed a power cycle (make it powerless for 30 seconds or more). > So I now can not get any access to the CPU anymore. when it is the other case where a pin init causes a short circuit, which in turn makes VCC drop and disturb the JTAG communication or even reset the MSP430, there are two recovery methods: - try to remove the pin or connection that may cause the short. this may be possible on a development board but probably not on a soldered PCB. - use the serial BSL to erase the MSP430. as the BSL never releases the CPU to run user code (the JTAG does), it is possible to send the erase (and other commands) before the wrong pin configuration is applied, also to be sure, i'd reduce the buffer size or check the RAM usage (msp430-size tool) before trying it the next time. a few hundred bytes of free RAM are usually advised for larger programs, so that the stack has enough space. > Since this eval board is very valuable for me and I will most likely not > get another one I am almost in panic! > Did I brick my board!? it certainly not impossible to brick an MSP, it's unlikely. shorted pins usually do not damage the MSP430. bad things are certainly burning the fuse (which must be done by special commands and does not happen accidentally) or by overwriting the F5x/F6X BSL while not invalidating the BSL signature (also does not happen by accident as writing the BSL also needs extra switches on the programmer). chris ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
