On Mon, Mar 11, 2013 at 6:58 PM, Chris Liechti <cliec...@gmx.net> wrote:
> 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.
>
The 5438a can run at 1.8V. And the MSP-EXP430F5438 Experimenter Board can
run at different voltages depending on the configuration of the board so
the mspdebug via the FET JTag pod may be suppling 1.8V.
I run my set up using the FET using local voltage sensing and run the board
using battery. The FET in this configuration doesn't supply power. I'm
running at 1.8V.
> > 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).
>
I would start with the schematic, take a look so make sure how the JTAG and
voltage settings are wired.
Go back to basics and see if you can program a simple program at 3.0 V or
3.3V.
Do you have another CPU (different instance of the 5438a)? If you do make
sure you can tell them apart and
swap out for a different CPU.
>
> > 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
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
------------------------------------------------------------------------------
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
