Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » MSPGCC
  • » [Mspgcc-users] GitHub eZChronos okay to flash [RSS Feed]

#1 June 20, 2010 22:17:29

p.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] GitHub eZChronos okay to flash


It turns out there was never a problem with the build.
I discovered later that I had a Windows 7 problem that
prevented the BM Firmware Update Tool and also TI's
BSL_Scripter tool from accessing the the USB FET.

I've since rebooted my machine and have repeated flashed
the watch with mspgcc4 project with not problems.

Paul

Offline

#2 June 20, 2010 22:59:11

Peter B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] GitHub eZChronos okay to flash


While this may have been the problem, be aware that there is an undocumented
(AFAIK) chip erratum on the CC430. I had programmed some boards to
immediately enter LPM5 on boot; at that point, I could no longer use the FET
over JTAG. See the threads titled *Cannot access TI MSP Experimenters board
* from this mailing list about three weeks ago for potentially related
information. We were able to restore functionality using the BSL over a USB
port on our development boards. I have not tried to diagnose this further.

If you left the watch programmed and running and it put itself into LPM5
after some extended idle period, that may have been part of the problem.
It's possible that there's something about the code generated by mspgcc vice
IAR/CCS that makes it happen. Or it may have just been your Windows problem
all along.

Peter

On Sun, Jun 20, 2010 at 9:17 AM, <p***@*ehorne.org> wrote:

> It turns out there was never a problem with the build.
> I discovered later that I had a Windows 7 problem that
> prevented the BM Firmware Update Tool and also TI's
> BSL_Scripter tool from accessing the the USB FET.
>
> I've since rebooted my machine and have repeated flashed
> the watch with mspgcc4 project with not problems.
>
> Paul
>
>
>
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/mspgcc-users>

Offline

#3 June 21, 2010 11:07:24

Paul F.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] GitHub eZChronos okay to flash


On 6/20/2010 9:59 AM, Peter Bigot wrote:While this may have been the problem, be aware that there is an undocumented
(AFAIK) chip erratum on the CC430. I had programmed some boards to
immediately enter LPM5 on boot; at that point, I could no longer use the FET
over JTAG. See the threads titled *Cannot access TI MSP Experimenters board
* from this mailing list about three weeks ago for potentially related
information.Peter,Thanks for the info. I'll be watching things over the next few days.But I don't believe LPM was theproblem.... I've slept since then, but as I recall the watch wasfunctioning properly when I attemptedto flash. Today I flashed it with the ported code probably a dozentimes with no problem.However, maybe I should just let it sit for a couple of days againbefore coming to any conclusion. Idon't really want to do that because I am now writing my own code withthe same functionality as theprovided firmware. I need the watch for testing my new code.

Paul

Offline

#4 June 21, 2010 22:44:10

J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] GitHub eZChronos okay to flash


The main problem with the JTAG interface is its slowlyness.
Adter the JTAG has reset the device, the device starts running.
If the JTAG programmer does not take over control and stops execution
before the device enters LPM5 or configures the SVS to enter a
permanent reset condition, the interface won't be able to detect the device.

The key is to hodl the device in reset condition permanently from power-up to
the immediate beginning of the flash/detections process and
NEVER RELEASE IT unless reporgramming is finished.

unfortunately, none of the tools is able to do this. They all require the
device to be
already powered-up and running when they are started. Then a reset is applied
(or even not in case of some JTAG programmers) and between identifying
teh device and starting the programming, the device is also often released.

With the BSL, things are a bit better as the BSL kicks in before any user code
is executed. It is still possible to bring the device into a state where it
caoont be properly reset when it started once after power-up.
This includes reconfiguring the SVS (which isn't reset by a reset) or
reconfiguring
the reset pin to NMI.

The solution would be that the programming tool pulls down RST once started,
allows the device to be powered-up with RST low, and then immediately starts
the programming cycle, so the device does not have any time to ever execute
user code after a power-up.

Currently it's a race condition. You'll need to power-up the device after the
programming tool ahs been started and pulled RST, but before it continues
with the device detection. This is almost impossible to do, so you'll almost
always lose this race.

I'd consider it not a chip erratum but rather a design flaw in the programming
cycle/programming software.

If your device is powered from teh USB-FET, the Elprotronic software
allows powering down the device and it will switch power on immediately
before programming. If you're lucky (I didn't test it myself as I didn't have
this kind of problems since I got the USB FET), the timing is good
enough to enter JTAG mode before the 'bad' user code is executed.

The ATMega BSL works differently - it is active as long as RST is low.
So you can manually pull down RST, power-up the device and then
start programming with RST still low.
There are other things to permanently disable the ATMega device,
such as misconfiguring the oscillator fuses.


JMGross

----- Urspr√ľngliche Nachricht -----
Von: Peter Bigot
An: GCC for MSP430 -http://mspgcc.sf.netGesendet am: 20 Jun 2010 16:59:08
Betreff: Re: GitHub eZChronos okay to flash


While this may have been the problem, be aware that there is an undocumented
(AFAIK) chip erratum on the CC430. I had programmed some boards to
immediately enter LPM5 on boot; at that point, I could no longer use the FET
over JTAG. See the threads titled *Cannot access TI MSP Experimenters board
* from this mailing list about three weeks ago for potentially related
information. We were able to restore functionality using the BSL over a USB
port on our development boards. I have not tried to diagnose this further.

If you left the watch programmed and running and it put itself into LPM5
after some extended idle period, that may have been part of the problem.
It's possible that there's something about the code generated by mspgcc vice
IAR/CCS that makes it happen. Or it may have just been your Windows problem
all along.

Peter

Offline

  • Root
  • » MSPGCC
  • » [Mspgcc-users] GitHub eZChronos okay to flash [RSS Feed]

Board footer

Moderator control

Enjoy the 18th of October
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support