From richard at imagecraft.com Thu Apr 2 03:22:01 2009
From: richard at imagecraft.com (Richard Man)
Date: Thu Apr 2 03:29:05 2009
Subject: [Icc-430] V7.10 beta3
Message-ID: <200904021129.n32BT4uU069221@mail.imagecraft.com>
http://www.imagecraft.com/pub/iccv7430_v710_beta3.exe
V7.10
[ ADV/PRO only: Added basic 430X support for > 64K addressing. If you
enable the "Enable 430X" checkbox under Project->Options->Target, the
compiler will use CALLA/RETA for function calls. Literals and constants
and interrupt handlers must reside in the lower 64K page, and this is
the default unless you have large amount of such items and they
overflow to the upper 64K page. There is currently no check when this
happens. We will add the support later. You can check by doing
View->MapFile to see where things are allocated.
Currently, neither the ICC430IDE's flash downloader nor NoICE-430 can
download to the upper 64K. To flash the full address range, you will need
to use another flash downloader. We have good luck with the free LITE
downloader from Elprotronic (http://www.elprotronic.com) ]
TI header files, HIL.DLL and MSP430.DLL
- Version 2.4.0.0.1 of the DLL and latest (Mar 2009) header file release
from TI.
Listing File Generator (ilst430)
- Enhancements:
== better display of global data references, e.g.
(0021) x.i = 5;
05E40 40B0 0005 BDC6 mov #5,x+10
== Use 5 hex digits to display the address
// richard blog:
On-line orders,
support, and listservers available on web site.
[ For technical support on ImageCraft products, please include all
previous replies in your msgs. ]
From mojaveg at iwvisp.com Sat Apr 4 08:31:59 2009
From: mojaveg at iwvisp.com (Everett Greene)
Date: Sat Apr 4 09:39:39 2009
Subject: [Icc-430] RIP: Everett Greene, ICC Consultant
In-Reply-To: <200903230405.n2N45MuX038093@mail.imagecraft.com>
Message-ID:
Richard,
Thank you for being a good friend to Everett as well as an employer.
Everett enjoyed solving problems.
Receiving the 1099 from you made it possible for our son, Stephen, to
complete taxes before returning
to Iraq. Everett referred to me as the Chief Financial Officer, but I just
gathered the info.
The current project that Everett was working on for you including the number
of hours billed are all locked up in his computer. These new billing hours
would fall into 2009 taxes with a 1099 correct?
I am hoping you have been keeping track.
I gave us being a Petroglyph guide this year due to a leg problem. Ev had
been scheduled to go out
the following Sunday of his death. Nobody wants to be taken out of the
canyon by medivac!
Thank you for your condolences.
Jeanne Greene
From: icc-430-bounces@imagecraft.com
[mailto:icc-430-bounces@imagecraft.com]On Behalf Of Richard Man
Sent: Sunday, March 22, 2009 8:58 AM
To: icc-announce@imagecraft.com; icc-avr@imagecraft.com;
icc-mot@imagecraft.com; icc-430@imagecraft.com; icc-arm@imagecraft.com;
icc-prop@imagecraft.com
Subject: [Icc-430] RIP: Everett Greene, ICC Consultant
It's with a heavy heart that I am reporting the passing of a friend
and a consultant to ImageCraft. Besides being a personal friend,
Everett wrote all the command line simulators for the ImageCraft
products, allowing fast testing of the compilers and he wrote all
products' low level floating point libraries except for ARM and the
Propeller. He will be missed.
If you wish to send his family (addressing Ms. Greene is fine) a
card, you can send it to me and I will forward it to the family.
Richard Man
ImageCraft
706 Colorado Ave
Palo Alto, CA 94303
// richard blog:
On-line orders,
support, and listservers available on web site.
[ For technical support on ImageCraft products, please include all
previous replies in your msgs. ]
_______________________________________________
Icc-430 mailing list
Icc-430@imagecraft.com
http://dragonsgate.net/mailman/listinfo/icc-430
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3953 (20090321) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
From jdurand at interstellar.com Sun Apr 5 11:32:26 2009
From: jdurand at interstellar.com (Jerry Durand)
Date: Sun Apr 5 12:41:48 2009
Subject: [Icc-430] Flash failure
Message-ID: <49D8F93A.4060905@interstellar.com>
I had a recent failure that I've been discussing with TI (I'm impressed,
it's a serious discussion and not a denial) and thought I'd check to see
if anyone else has seen this.
We have some products that are in use 24/7 in fairly mild environments.
We've been building these for 10 years now and switched to the
MSP430F2417 last summer (Richard, that board you're testing on is what
I'm talking about).
A couple of weeks ago a customer said his unit switched operating mode
(went to idle) and wouldn't switch back, but the USB and RS-232
interfaces still worked fine. His unit had been running since last
July. We sent him a new unit and in testing the failed one found that
part of the internal FLASH had been erased or changed (couldn't tell
exactly, the security fuse is blown and BSL readback is disabled).
There's no reason the code should be writing to the FLASH except during
firmware updates and we haven't issued any. The FLASH is only unlocked
after the update has been fully loaded into external EEPROM and
verified. The SVS was enabled as well as the watchdog, so any funny
power glitches should have just rebooted the processor.
Anyway, I tried loading a firmware update over the USB connection and it
seems to be working fine now. I hope this isn't a bad batch, I've got
units in several countries and would hate to have to replace all of them.
--
Jerry Durand, Durand Interstellar, Inc. www.interstellar.com
tel: +1 408 356-3886, USA toll free: 1 866 356-3886
Skype: jerrydurand
From gcalin at metrolog.net Sun Apr 5 12:27:59 2009
From: gcalin at metrolog.net (Gabriel Calin)
Date: Sun Apr 5 13:37:31 2009
Subject: [Icc-430] Flash failure
In-Reply-To: <49D8F93A.4060905@interstellar.com>
References: <49D8F93A.4060905@interstellar.com>
Message-ID: <49D9063F.3030809@metrolog.net>
Hello Jerry,
We use MSP430F149 in many of our equipments. Your email got my
attention since almost the same situation happened with us. Our
equipments have industrial grade construction and are used in
floor-shops (somewhat aggressive environments). In many cases they also
run 24/7.
A couple time a customer complained about sudden failures and we
detected that some pages were erased (we usually do not blow the MSP
fuse, so I managed to load all software back for analysis). The pages
were erased at random locations.
Since our equipments are often connected nearby heavy machinery we
believed that heavy power line transients could do that. Some additional
precautions were taken (power supply mainly) and that was it. We
actually never found out the real cause of these failures.
I wonder if the same situation you described happened to us. Let me
know if you find anything.
Regards,
Gabriel Calin
----------------------------------
Metrolog Controles de Medi??o Ltda
Rua Sete de Setembro, 2671 - Centro
13560-181 S?o Carlos - SP - Brasil
Fone +55 (16) 3371-0112
Fax +55 (16) 3372-7800
Website: http://www.metrolog.net
Email: gcalin@metrolog.net
Jerry Durand wrote:
> I had a recent failure that I've been discussing with TI (I'm impressed,
> it's a serious discussion and not a denial) and thought I'd check to see
> if anyone else has seen this.
>
> We have some products that are in use 24/7 in fairly mild environments.
> We've been building these for 10 years now and switched to the
> MSP430F2417 last summer (Richard, that board you're testing on is what
> I'm talking about).
>
> A couple of weeks ago a customer said his unit switched operating mode
> (went to idle) and wouldn't switch back, but the USB and RS-232
> interfaces still worked fine. His unit had been running since last
> July. We sent him a new unit and in testing the failed one found that
> part of the internal FLASH had been erased or changed (couldn't tell
> exactly, the security fuse is blown and BSL readback is disabled).
> There's no reason the code should be writing to the FLASH except during
> firmware updates and we haven't issued any. The FLASH is only unlocked
> after the update has been fully loaded into external EEPROM and
> verified. The SVS was enabled as well as the watchdog, so any funny
> power glitches should have just rebooted the processor.
>
> Anyway, I tried loading a firmware update over the USB connection and it
> seems to be working fine now. I hope this isn't a bad batch, I've got
> units in several countries and would hate to have to replace all of them.
>
From jdurand at interstellar.com Sun Apr 5 12:42:35 2009
From: jdurand at interstellar.com (Jerry Durand)
Date: Sun Apr 5 13:51:42 2009
Subject: [Icc-430] Flash failure
In-Reply-To: <49D9063F.3030809@metrolog.net>
References: <49D8F93A.4060905@interstellar.com> <49D9063F.3030809@metrolog.net>
Message-ID: <49D909AB.9070105@interstellar.com>
I added your message to my TI case.
Gabriel Calin wrote:
> Hello Jerry,
>
> We use MSP430F149 in many of our equipments. Your email got my
> attention since almost the same situation happened with us. Our
> equipments have industrial grade construction and are used in
> floor-shops (somewhat aggressive environments). In many cases they also
> run 24/7.
>
--
Jerry Durand, Durand Interstellar, Inc. www.interstellar.com
tel: +1 408 356-3886, USA toll free: 1 866 356-3886
Skype: jerrydurand
From richard at imagecraft.com Tue Apr 7 00:36:54 2009
From: richard at imagecraft.com (Richard Man)
Date: Tue Apr 7 01:44:23 2009
Subject: [Icc-430] ICC430 V7.10 released
Message-ID: <200904070844.n378iLAm077799@mail.imagecraft.com>
V7.10 - April 6th 2009
[ ADV/PRO only: Added basic 430X support for > 64K addressing. If you
enable the "Enable 430X" checkbox under Project->Options->Target, the
compiler will use CALLA/RETA for function calls. Literals and constants
and interrupt handlers must reside in the lower 64K page, and this is
the default unless you have large amount of such items and they
overflow to the upper 64K page. There is currently no check when this
happens. We will add the support later. You can check by doing
View->MapFile to see where things are allocated.
Currently, neither the ICC430IDE's flash downloader nor NoICE-430 can
download to the upper 64K. To flash the full address range, you will need
to use another flash downloader. We have good luck with the free LITE
downloader from Elprotronic (http://www.elprotronic.com) ]
TI header files, HIL.DLL and MSP430.DLL
- Version 2.4.0.0.1 of the DLL and latest (Mar 2009) header file release
from TI.
Listing File Generator (ilst430)
- Enhancements:
== better display of global data references, e.g.
(0021) x.i = 5;
05E40 40B0 0005 BDC6 mov #5,x+10
== Use 5 hex digits to display the address
// richard blog:
On-line orders,
support, and listservers available on web site.
[ For technical support on ImageCraft products, please include all
previous replies in your msgs. ]
From llchisho at paradise.net.nz Tue Apr 7 23:23:59 2009
From: llchisho at paradise.net.nz (llchisho@paradise.net.nz)
Date: Wed Apr 8 00:31:43 2009
Subject: [Icc-430] ICC430 V7.10
Message-ID: <1239171839.49dc42ff4ec28@www.paradise.net.nz>
V7.10 fails to link one of our existing projects, and I have identified 2 issues :
a)
Interrupt vectors are at the wrong addresses in the .s files from the compiler -
reset is correct, but all other vectors seem to be offset from 0xFFC0 rather
than 0xFFE0.
Tested by creating a new project, selecting 430F1611, creating one file as follows:
-------
#include "msp430x16x.h"
#pragma interrupt_handler fred:NMI_VECTOR
void fred(void) {
asm("nop");
}
void main(void) {
asm("nop");
}
-------
b)
I have several ISRs which I use on the same vector at different times, with a
single-instruction handler branching indirectly to the selected routine. This
requires all the alternate routines to be compiled with #pragma interrupt rather
than making an indirect call from the core handler which needlessly saves
registers for trivial handlers. In previous versions I could simply assign them
all to the same vector and the last one would win at link time. This now seems
to raise a linker error:
!E main.o(5534): Code address 2:0xffc2 already contains a value
This may also defeat my scheme for providing default interrupt catchers by
filling in the vector table early with stub addresses which are replaced later
if real handlers are defined.
Is it possible to provide an option to allow overwriting of (abs,ovr) areas ?
Alternatively, a way to define an anonymous interrupt handler in C would be good.
Len Chisholm.
From richard-lists at imagecraft.com Wed Apr 8 00:51:17 2009
From: richard-lists at imagecraft.com (Richard Man)
Date: Wed Apr 8 01:58:51 2009
Subject: [Icc-430] ICC430 V7.10
In-Reply-To: <1239171839.49dc42ff4ec28@www.paradise.net.nz>
References: <1239171839.49dc42ff4ec28@www.paradise.net.nz>
Message-ID: <200904080858.n388wogr003967@mail.imagecraft.com>
Ooops, a) is due to a source merge that wasn't done correctly. Sorry
about that. It should be easy fix, but for now I have re-uploaded 7.09.
b) has been put in place for quite a while now. What version were you
using before?
I will email you off-list to test the vector fix.
Apologize all for the inconvenience...
At 11:23 PM 4/7/2009, llchisho@paradise.net.nz wrote:
>V7.10 fails to link one of our existing projects, and I have
>identified 2 issues :
>a)
>Interrupt vectors are at the wrong addresses in the .s files from
>the compiler -
>reset is correct, but all other vectors seem to be offset from 0xFFC0 rather
>than 0xFFE0.
>Tested by creating a new project, selecting 430F1611, creating one
>file as follows:
>-------
>#include "msp430x16x.h"
>#pragma interrupt_handler fred:NMI_VECTOR
>void fred(void) {
>asm("nop");
>}
>void main(void) {
>asm("nop");
>}
>-------
>
>b)
>I have several ISRs which I use on the same vector at different times, with a
>single-instruction handler branching indirectly to the selected routine. This
>requires all the alternate routines to be compiled with #pragma
>interrupt rather
>than making an indirect call from the core handler which needlessly saves
>registers for trivial handlers. In previous versions I could simply
>assign them
>all to the same vector and the last one would win at link time. This now seems
>to raise a linker error:
>!E main.o(5534): Code address 2:0xffc2 already contains a value
>This may also defeat my scheme for providing default interrupt catchers by
>filling in the vector table early with stub addresses which are replaced later
>if real handlers are defined.
>Is it possible to provide an option to allow overwriting of (abs,ovr) areas ?
>Alternatively, a way to define an anonymous interrupt handler in C
>would be good.
>
>Len Chisholm.
// richard
From nzbackpackers at yahoo.com Fri Apr 10 10:57:13 2009
From: nzbackpackers at yahoo.com (Hugh Molesworth)
Date: Fri Apr 10 12:04:48 2009
Subject: [Icc-430] Flash failure
In-Reply-To: <49D9063F.3030809@metrolog.net>
References: <49D8F93A.4060905@interstellar.com> <49D9063F.3030809@metrolog.net>
Message-ID: <613899.10204.bm@omp409.mail.mud.yahoo.com>
Do you have code in place to handle every
interrupt vector location in the table, whether
you intend to use those interrupts or not? There
are 16 possible vectors, 15 of which are used on
the MSP430F149. These are vectors at address
locations 0xFFE0 to 0xFFFF, corresponding to
interrupt priorities 0-15, and 0 is the vector not used in the '149.
Why do I ask this question? Because there is a
potential problem with the MSP430 in that you are
allowed to execute register addresses and data
areas as though they were program code, great
under some circumstances but not in others.
Suppose you have a firmware bug, and some part of
the code incorrectly uses a null pointer to write
some data; this has been covered before on the
MSP430 group since it has happened in the field.
Typically a null pointer might occur by a
malloc() fail, or simply by using a pointer
before it has been initialised. What happens then
is that flash address location 0x0000 get written
to, and this just happens to be IE0 (0x0000) and
IE1 (0x0001), the interrupt-enable registers.
Addresses 0x0002 and 0x0003 are the interrupt
flags, and other interrupt enables are close by,
so if your pointer writes a sequence of data to
these locations the interrupts may be
unexpectedly enabled and of course they then fire
and take whatever vector is in place in the
table. This can cause weird results if those
vectors are valid, but if the vectors weren't
defined (because the design wasn't using those
interrupts) then the code is vectored to the
erased flash contents (0xFFFF) which the MSP430
will interpret as address 0xFFFE and start
executing from there. This wraps around to 0x0000
and the code then calmly executes instructions
from the register area and absolutely anything
can happen - including hitting a flash erase
function - before a watchdog can rescue the situation.
Trap this latter problem by defining isrs for all
vectors, not just those used in the design, and
cause the unused vectors to just disable the
appropriate interrupt enable (and possibly
increment a counter for diagnostics) before
returning. This will at least stop the MSP430
from executing registers and data as code.
Any function that can erase flash (boot, main or
asm) should preferably have some protection in
that perhaps an additional dummy keyword
parameter passed to the function must be valid,
otherwise the erase is denied. That would
potentially protect against some catastrophic
occurrence such as described above, and again
this has been described before on the MSP430 group.
Hugh
At 12:27 PM 4/5/2009, you wrote:
>Hello Jerry,
>
> We use MSP430F149 in many of our equipments. Your email got my
>attention since almost the same situation happened with us. Our
>equipments have industrial grade construction and are used in
>floor-shops (somewhat aggressive environments). In many cases they also
>run 24/7.
>
> A couple time a customer complained about sudden failures and we
>detected that some pages were erased (we usually do not blow the MSP
>fuse, so I managed to load all software back for analysis). The pages
>were erased at random locations.
>
> Since our equipments are often connected nearby heavy machinery we
>believed that heavy power line transients could do that. Some additional
>precautions were taken (power supply mainly) and that was it. We
>actually never found out the real cause of these failures.
>
> I wonder if the same situation you described happened to us. Let me
>know if you find anything.
>
> Regards,
>
>Gabriel Calin
>----------------------------------
>Metrolog Controles de Medi??o Ltda
>Rua Sete de Setembro, 2671 - Centro
>13560-181 S?o Carlos - SP - Brasil
>Fone +55 (16) 3371-0112
>Fax +55 (16) 3372-7800
>Website: http://www.metrolog.net
>Email: gcalin@metrolog.net
>
>Jerry Durand wrote:
> > I had a recent failure that I've been discussing with TI (I'm impressed,
> > it's a serious discussion and not a denial) and thought I'd check to see
> > if anyone else has seen this.
> >
> > We have some products that are in use 24/7 in fairly mild environments.
> > We've been building these for 10 years now and switched to the
> > MSP430F2417 last summer (Richard, that board you're testing on is what
> > I'm talking about).
> >
> > A couple of weeks ago a customer said his unit switched operating mode
> > (went to idle) and wouldn't switch back, but the USB and RS-232
> > interfaces still worked fine. His unit had been running since last
> > July. We sent him a new unit and in testing the failed one found that
> > part of the internal FLASH had been erased or changed (couldn't tell
> > exactly, the security fuse is blown and BSL readback is disabled).
> > There's no reason the code should be writing to the FLASH except during
> > firmware updates and we haven't issued any. The FLASH is only unlocked
> > after the update has been fully loaded into external EEPROM and
> > verified. The SVS was enabled as well as the watchdog, so any funny
> > power glitches should have just rebooted the processor.
> >
> > Anyway, I tried loading a firmware update over the USB connection and it
> > seems to be working fine now. I hope this isn't a bad batch, I've got
> > units in several countries and would hate to have to replace all of them.
> >
>_______________________________________________
>Icc-430 mailing list
>Icc-430@imagecraft.com
>http://dragonsgate.net/mailman/listinfo/icc-430
From jdurand at interstellar.com Fri Apr 10 11:28:59 2009
From: jdurand at interstellar.com (Jerry Durand)
Date: Fri Apr 10 12:39:04 2009
Subject: [Icc-430] Flash failure
In-Reply-To: <613899.10204.bm@omp409.mail.mud.yahoo.com>
References: <49D8F93A.4060905@interstellar.com> <49D9063F.3030809@metrolog.net>
<613899.10204.bm@omp409.mail.mud.yahoo.com>
Message-ID: <49DF8FEB.1040703@interstellar.com>
Hugh Molesworth wrote:
> Do you have code in place to handle every interrupt vector location in
> the table, whether you intend to use those interrupts or not? There
> are 16 possible vectors, 15 of which are used on the MSP430F149. These
> are vectors at address locations 0xFFE0 to 0xFFFF, corresponding to
> interrupt priorities 0-15, and 0 is the vector not used in the '149.
>
No, just the ones I've enabled and ICC puts in by default.
> Why do I ask this question? Because there is a potential problem with
> the MSP430 in that you are allowed to execute register addresses and
> data areas as though they were program code, great under some
> circumstances but not in others. Suppose you have a firmware bug, and
> some part of the code incorrectly uses a null pointer to write some
> data; this has been covered before on the MSP430 group since it has
> happened in the field. Typically a null pointer might occur by a
> malloc() fail, or simply by using a pointer before it has been
> initialised. What happens then is that flash address location 0x0000
> get written to, and this just happens to be IE0 (0x0000) and IE1
> (0x0001), the interrupt-enable registers. Addresses 0x0002 and 0x0003
> are the interrupt flags, and other interrupt enables are close by, so
> if your pointer writes a sequence of data to these locations the
> interrupts may be unexpectedly enabled and of course they then fire
> and take whatever vector is in place in the table. This can cause
> weird results if those vectors are valid, but if the vectors weren't
> defined (because the design wasn't using those interrupts) then the
> code is vectored to the erased flash contents (0xFFFF) which the
> MSP430 will interpret as address 0xFFFE and start executing from
> there. This wraps around to 0x0000 and the code then calmly executes
> instructions from the register area and absolutely anything can happen
> - including hitting a flash erase function - before a watchdog can
> rescue the situation.
I never use malloc() and try really hard to initialize pointers before
use (35 years of writing embedded code does that to you). But, mainly I
have the FLASH lock on at all times except in the rare case that a
firmware update has been loaded into external memory (EEPROM/FLASH) and
verified. Then the code is in-line from enable FLASH to performing the
actual update. At the end of an update I close the FLASH and then cause
an exception reboot (mov #0, &0x0120) and even put THAT in a loop in so
pre-fetches don't do anything funny.
> Trap this latter problem by defining isrs for all vectors, not just
> those used in the design, and cause the unused vectors to just disable
> the appropriate interrupt enable (and possibly increment a counter for
> diagnostics) before returning. This will at least stop the MSP430 from
> executing registers and data as code.
Richard, a suggestion for future version: An option to fill all unused
ISRs on a part with a reboot (force a cold restart, not just vector to
RESET as that won't reset registers).
>
> Any function that can erase flash (boot, main or asm) should
> preferably have some protection in that perhaps an additional dummy
> keyword parameter passed to the function must be valid, otherwise the
> erase is denied. That would potentially protect against some
> catastrophic occurrence such as described above, and again this has
> been described before on the MSP430 group.
That's a thought, of course if the erroneous jump lands on the call for
the erase function, the keyword will be passed anyway. Landing on or
just before an erase call is actually more likely than landing at the
beginning of the tiny erase function itself.
--
Jerry Durand, Durand Interstellar, Inc. www.interstellar.com
tel: +1 408 356-3886, USA toll free: 1 866 356-3886
Skype: jerrydurand
From t.jaspers at cpseurope.com Tue Apr 14 00:10:26 2009
From: t.jaspers at cpseurope.com (Jaspers, Ton)
Date: Tue Apr 14 01:18:16 2009
Subject: [Icc-430] Flash failure
In-Reply-To: <49DF8FEB.1040703@interstellar.com>
Message-ID: <7B0EB27CF1CC93439B5CFB7526E5D74C8239EB@mickey.PBNV.local>
> -----Original Message-----
> From: Jerry Durand
>
>
> Richard, a suggestion for future version: An option to fill
> all unused ISRs on a part with a reboot (force a cold
> restart, not just vector to RESET as that won't reset registers).
>
Why not use the watchdog to generate a true hardware reset?
It is pretty difficult to set all bits of all registers and
SFR's to their POR values. A watchdog reset is effectively a POR.
Cheers,
Ton Jaspers
From jdurand at interstellar.com Tue Apr 14 08:56:16 2009
From: jdurand at interstellar.com (Jerry Durand)
Date: Tue Apr 14 10:05:30 2009
Subject: [Icc-430] Flash failure
In-Reply-To: <7B0EB27CF1CC93439B5CFB7526E5D74C8239EB@mickey.PBNV.local>
References: <7B0EB27CF1CC93439B5CFB7526E5D74C8239EB@mickey.PBNV.local>
Message-ID: <49E4B220.40904@interstellar.com>
Jaspers, Ton wrote:
> Why not use the watchdog to generate a true hardware reset?
> It is pretty difficult to set all bits of all registers and
> SFR's to their POR values. A watchdog reset is effectively a POR.
>
That's why I mentioned I use
mov #0, &0x0120
to force a cold reset. I also put it in a loop so any prefetches past it don't hurt anything.
--
Jerry Durand, Durand Interstellar, Inc. www.interstellar.com
tel: +1 408 356-3886, USA toll free: 1 866 356-3886
Skype: jerrydurand
From llchisho at paradise.net.nz Tue Apr 14 15:49:27 2009
From: llchisho at paradise.net.nz (llchisho@paradise.net.nz)
Date: Tue Apr 14 16:57:21 2009
Subject: [Icc-430] Flash failure
In-Reply-To: <49E4B220.40904@interstellar.com>
References: <7B0EB27CF1CC93439B5CFB7526E5D74C8239EB@mickey.PBNV.local>
<49E4B220.40904@interstellar.com>
Message-ID: <1239749367.49e512f7c0df6@www.paradise.net.nz>
Quoting Jerry Durand :
> Jaspers, Ton wrote:
> > Why not use the watchdog to generate a true hardware reset?
> > It is pretty difficult to set all bits of all registers and
> > SFR's to their POR values. A watchdog reset is effectively a POR.
>
> That's why I mentioned I use
> mov #0, &0x0120
>
> to force a cold reset. I also put it in a loop so any prefetches past it
> don't hurt anything.
Note that although this is as close as you can get, it doesn't actually put the
chip in a power-up state (for the MSP430s I've worked with at least). There is a
distinction between a Power-Up-Clear and a Power-On-Reset (which cannot be
user-generated on-chip). Some peripheral registers are only cleared on a POR so
that the hardware keeps going by itself if the watchdog restarts the CPU due to
software problems.
For example, the ADC10 subsystem's registers are reset with POR but not PUC. If
it's converting it'll keep on trucking (and writing to memory with the DTC), and
its interrupt will still be enabled if previously enabled. This caught me out
while testing in-system self-reprogramming when I unknowingly changed the
firmware from a version using the ADC to one that didn't (and didn't have an
interrupt vector assigned). After a PUC at the end of programming, it crashed as
soon as interrupts were enabled.
Also see the DMA controller...
Len Chisholm.
From ds at hobbyrobotik.de Thu Apr 16 02:25:13 2009
From: ds at hobbyrobotik.de (ds@hobbyrobotik.de)
Date: Thu Apr 16 03:33:09 2009
Subject: [Icc-430] FW: Selection of MSP-type in IDE Project options has no
effect to code location
Message-ID: <577418.4608601239873913383.JavaMail.servlet@kundenserver>
Hello everybody,
I have problems with changing the code start adress of my appl. I'm
programming a F1232 type.
In IDE I select any MSP Type, but the "-blit" parameter in the comand
line remains unchanged on 0xF000 and thus the code is constantly compiled to
this mem. location. I tried new installation of the ICC7430 with no success. I
am working with the limited (4K evaluation ) version. Is this the reason for
that malfunction? Can anybody help please?
From richard-lists at imagecraft.com Thu Apr 16 12:30:02 2009
From: richard-lists at imagecraft.com (Richard Man)
Date: Thu Apr 16 13:37:43 2009
Subject: [Icc-430] FW: Selection of MSP-type in IDE Project options
has no effect to code location
In-Reply-To: <577418.4608601239873913383.JavaMail.servlet@kundenserver>
References: <577418.4608601239873913383.JavaMail.servlet@kundenserver>
Message-ID: <200904162037.n3GKbfob059761@mail.imagecraft.com>
Yes, it's working exactly as designed. Since you are using the demo,
it's limiting you to 4K of code.
At 02:25 AM 4/16/2009, ds@hobbyrobotik.de wrote:
>Hello everybody,
>I have problems with changing the code start adress of my appl. I'm
>programming a F1232 type.
>In IDE I select any MSP Type, but the "-blit" parameter in the comand
>line remains unchanged on 0xF000 and thus the code is constantly compiled to
>this mem. location. I tried new installation of the ICC7430 with no
>success. I
>am working with the limited (4K evaluation ) version. Is this the reason for
>that malfunction? Can anybody help please?
// richard
From ds at hobbyrobotik.de Thu Apr 16 14:10:49 2009
From: ds at hobbyrobotik.de (ds@hobbyrobotik.de)
Date: Thu Apr 16 15:18:44 2009
Subject: [Icc-430] FW: Selection of MSP-type in IDE Project optionshas
no effect to code location
Message-ID: <30316713.2342381239916249096.JavaMail.servlet@kundenserver>
Thank you Richard,
but in this case I cannot try out your ICC for my project, because on my target is already (unrelocateable) code in the area above 0xf000. My patch program has aprox. 2.5 K of size and should be located at 0xE000...
Do I have any chance to realize that anyhow with the Demoversion?
regards
Yes, it's working exactly as designed. Since you are using the demo,
it's limiting you to 4K of code.
From peter at sensair.com Mon Apr 27 01:21:57 2009
From: peter at sensair.com (Peter Lissenburg)
Date: Mon Apr 27 02:30:20 2009
Subject: [Icc-430] reading status register?
In-Reply-To: <30316713.2342381239916249096.JavaMail.servlet@kundenserver>
References: <30316713.2342381239916249096.JavaMail.servlet@kundenserver>
Message-ID: <49F56B25.3080502@sensair.com>
Hi All,
sorry, but I have a probably silly question.
I need to check the state of the status register.
Doing...
unsigned char SR;
asm("mov %SR, R2");
ICC430 doesn't work, any suggestions?
Thanks for your help.
Peter L.
From richard-lists at imagecraft.com Mon Apr 27 01:31:40 2009
From: richard-lists at imagecraft.com (Richard Man)
Date: Mon Apr 27 02:39:59 2009
Subject: [Icc-430] reading status register?
In-Reply-To: <49F56B25.3080502@sensair.com>
References: <30316713.2342381239916249096.JavaMail.servlet@kundenserver>
<49F56B25.3080502@sensair.com>
Message-ID: <200904270939.n3R9dwDY040574@mail.imagecraft.com>
SHould work, but try
unsigned int SR;
...
At 01:21 AM 4/27/2009, you wrote:
>Hi All,
> sorry, but I have a probably silly question.
>I need to check the state of the status register.
>Doing...
>unsigned char SR;
> asm("mov %SR, R2");
>ICC430 doesn't work, any suggestions?
>
>Thanks for your help.
>Peter L.
>
// richard
From bailey at peak.org Mon Apr 27 01:32:12 2009
From: bailey at peak.org (bailey@peak.org)
Date: Mon Apr 27 02:40:31 2009
Subject: [Icc-430] reading status register?
In-Reply-To: <49F56B25.3080502@sensair.com>
References: <30316713.2342381239916249096.JavaMail.servlet@kundenserver>
<49F56B25.3080502@sensair.com>
Message-ID: <3076.69.59.200.77.1240821132.squirrel@webmail.peak.org>
Peter,
Take a look at the msp430def.h file in newer versions of the compiler.
I added a bunch of predefined macros to access the SR (among other things),
and Richard should be distributing my modified version. In particular,
look at GET_SR, but there are others that may be of interest also...
Kirk Bailey
bailey@peak.org
> Hi All,
> sorry, but I have a probably silly question.
> I need to check the state of the status register.
> Doing...
> unsigned char SR;
> asm("mov %SR, R2");
> ICC430 doesn't work, any suggestions?
>
> Thanks for your help.
> Peter L.
>
>
> _______________________________________________
> Icc-430 mailing list
> Icc-430@imagecraft.com
> http://dragonsgate.net/mailman/listinfo/icc-430
>