Von: Peter Bigot
Gesendet am: 30 Dez 1899 00:00:00
> Re errata: to whatever extent binutils or mspgcc{3,4} already supports
> chip-specific errata I'll have to retain that. To whatever extent I can
> come up with a way to add support, I'll do so. But I expect this'll be an
> on-demand sort of thing: having gotten away from the need to read every data
> sheet to figure out where the flash sections start, I'm not going to start
> reading every errata document to figure out what's broken on which revision
> of which chip.
Understandable.
It is mostly the CPUx bugs which are compiler-specific.
Some others (EEMx) may be of interest for the debugger or the
JTAG connection.
I think it is vital for mspgcc to take care of this or the (IMHO worse)
IAR and CCS will make it vanish from the (new) users horizon.
Once a product has the stigma of not supporting this or that, people
tend to ignore it completely, even if it is a feature they don't need.
> Names are TBD, but yes, I foresee something like:
> -msp430=cpu (cpux, cpuxv2)
> -mpy=none (mpy, mpy32)
That will mostly do the trick. Yet there is some mechanism needed to ensure
you don't mix incompatible object files. At least with a default warning you can
deactivate manually by another compiler/linker option.
Imagine ewhat happens if you mix MSP and MSPX code. Everything from
fully functional to occasionally or always crashing can result.
Same for the MPY.
This can be left to the user, but then newbies (or those not aware of it) will
start complaining too.
> I'm going to do what I can to delay resolving peripheral addresses to the
> final link phase. Having control of the standard header files should make
> that easier.
There should be a separate set of 'generic' header files which do not define
any address, just extern volatile unsigned char variables.
There are only a few registers needed for the libraries. MPY, WD, maybe
a few more for certain types of processors.
> I'm very sympathetic to your views on watchdogs, and would like to make it
> easier to control that function. However, a large portion of the MSPGCC
> user community is completely ignorant of the presence of WDT because it's
> always been automatically turned off for them. I'm just not willing to deal
> with the fallout from changing the existing default behavior.
There could be a weak generic version which simply turns off the watchdog.
But I won't recommend it.
Every example from TI contains deactivating the watchdog as the first line.
So almost every piece of code I've ever seen from users on e2e.ti.com
deactivated the WD.
Using a default startup sequence that triggers the WD instead of deactivating it
will do no harm. Yes, it would be a bit slower, but who cares about few
microseconds startup time.
Those who do will program a DMA for copying :)
Actually, it took quite some time until I discovered that the WD was deactivated
in all of the projects I took over.
The code was triggering the WD all the time, but nobody (before me) ever noticed
that the WD was actually off (a HUGE security violation) from the beginning.
All TI datasheets told that it is on after a PUC, yet it wasn't.
Finally I discovered the startup sequence as the violator and wrote my own.
I guess there are MANY people out there, who constantly trigger the WD and
rely on it, not knowing that it is off all the time.
JMGross
On Tue, Aug 10, 2010 at 5:48 AM, JMGross <msp...@grossibaer.de> wrote:
>
> ----- Urspr=FCngliche Nachricht -----
> Von: Peter Bigot
> Gesendet am: 10 Aug 2010 01:17:03
>
> > What I propose to do instead is reduce the machines to those required
> > reflect the chip CPU architecture (MSP430, MSP430X, MSP430XV2), and not
> try
> > to indicate things like available peripherals and the like as distinct
> > machine types. The only other feature that affects generated code is
> > presence/absence of hardware multiply support (none, MPY, MPY32), and I
> > think that can be done without having to add another axis to the
> > architecture matrix.
>
> This is AFAIK the only part that needs care, besides the X/XV2 thing.
> Of course there are the errata which should be taken care of, or the
> compiler
> will possibly create code that will simply crash. This is mostly X/XV2
> related
> stuff (forbidden sequences of instruction, necessary NOPs, not doing some
> PC/SP manipulations etc.
> Unfortunately, this is machine dependent. SOmetimes it applies to whole
> families or groups of processors, sometimes only single ones are affected=
.
>
> I fear this could break the 'slim' concept you want to introduce.
>
> There can be, however, basic support for yet unsupported machines by
> supporting the base architecture and MPY through parameters or
> generic machine types. This allows compiler/assembler support for new
> processors. (of course, linker scripts and include files are necessary, b=
ut
> these can be written by 'normal' people)
>
> I propose that an unknown mmcu will recognize a -core and -mpy parameter
> and use the generic machines if given (or throw an error or assume non-X =
no
> MPY if not set). This way it would be compatible to the current mechanism=
s
> of forking inside header files etc.
>
> > If this works, the guts of binutils (the assembler and linker) becomes
> > independent of specific chip details, except for the location of ld
> sections
> > (RAM, ROM, etc) and the base address of a few peripherals. Since TI's
> now
> > providing me with a table containing, for each chip, the necessary
> addresses
> > all the way down to individual info sections, it should be much easier =
to
> do
> > this; plus, I believe it can be done in a way that allows new chips to =
be
> > targeted without having to rebuild the toolchain.
>
> Because of the silicon errata this can prove difficult to impossible.
> Except there is a way to manually set errata flags.
> But I don't know whether TI has a 'global' errata naming. I fear the
> errata names are independent for each group of processors and same name
> may mean different things for different processors.
>
> > Some of the questions that arise include:
>
> > *) Is it necessary to retain support for the existing machine definitio=
ns
> in
> > binutils, at least to allow linking to legacy libraries that can't b=
e
> > rebuilt?
>
> I don't think existing libraries are a problem.
> If they cannot be rebuilt, they'll work or not.
> machine-dependent defines are already resolved during compilation.
> All that's left is resolving the symbols and this is a
> machine-independent process. Either they are provided in the
> (properly) compiled project object files or they are missing and
> linking is impossible.
> Some special code (like the startup) depends on machine-dependent
> information, but this is usually part of the linker scripts.
>
> > *) Can critical values like the address of the watchdog reset or multip=
ly
> > peripheral registers be correctly resolved using separate compilatio=
n,
> in
> > such a way that attempts to link object files built for incompatible
> > platforms fail with an understandable error message?
>
> I know that the compiler-generated MPY16 inline code linked fine on
> machines with MPY32. Only the libraries didn't work as they were built
> with different register addresses. If global, unresolved symbols were use=
d
> in these functions instead of static addresses, this should be doable.
>
> I can imagine a compiler attribute that forces a variable to be extern ev=
en
> if
> it has been defined with a 'fixed' location in the header files.
> So the linker can clean up things.
>
> Also, the functions using the MPY (or not) can be named differently, so t=
he
> compiler will generate different function calls depending on whether MPY1=
6
> is used or MPY32 or none (it already does so for none and MPY16).
> If they are in different compilation units, the linker will only link the
> required
> ones.
> This unfortunately won't work for precompiled library functions which use
> the MPY.
> Another approach would be to add different libraries which are selected
> depending on the MPY usage.
>
> There is, however, a problem with the watchdog register, which is
> differently
> for different MSPs.
>
> There I propose removing it completely from the init code.
> It should be documented that the user must provide a proper
> code snippet if he needs the WDT disabled at startup.
> Personally, I strongly discourage stopping the WTD at startup, as this
> renders the WDT practically useless. Either it is on all the time without
> exception, or you do not really need it at all.
>
> On newer MSPs, the default times are long enough so the WDR won't
> trigger even if you copy 18k of data (which is the maximum ram in any
> MSP so far). The timeout is long enough for even copying hundreds of
> kB.
>
> > *) What else am I not thinking of?
>
> Most problems are encountered during project progress.
> That's an inevitable rule.
>
> JMGross
>
