JMGross writes:
> Von: dan...@tortek.co.nz
> Gesendet am: 12 Jul 2010 03:28:06
>
> > If you have a newer version of the firmware and MSPDebug doesn't
> > support your chip, sometimes you can get away with forcing the use of
> > a record for a chip which is close enough. You just need to ensure
> > that the memory extent of the chip you select is a superset of the one
> > you're actually using, because the FET will perform range checks on
> > flash writes.
>
> Superset? Subset, I'd say. The FET needs to find everything it expects.
> If the target device has more ram or more flash, fine (as long as you don't
> need to write to this additional flash). But it needs to find everything that
> is told to be there by the device config.
> Especially the ram. The target may have more, but not less and it has to
> be at the expected location.
> This is why you can flash a 169 and a 1611 with the 168 setup. As the
> 168 has the same amount of ram as the 169 and the same amount of
> flash as the 1611, yet the 169 has more flash (but all of the flash the
> 168 has) and the 1611 has more ram than the others, but has 2kb of it
> mirrored to the same place where it is on the others.
> But if the expected device has mor eram than the existing one, the
> FET will possibly try to use it for faster flashing (larger chunks) and fail.
Well, that's definitely useful to know. If the only thing standing in
your way to a workable database record is the memory ranges, you can
always try hacking up a record for a similar chip. Some information on
the format of these records is here:
http://mspdebug.sourceforge.net/fet.html
- Daniel
