I think the point is that, if you already know the device, you can find the
address map (from the datasheet, from the msp430mcu package's devices.csv
file provided by TI that's used to generate the linker scripts for the
toolchain, or from information in the debug DLL package). What's missing
is how to figure out what device you have by looking at the MCU boot memory
through JTAG/SpyBiWire or at runtime, or some other automated inspection
method.
I believe mspdebug has performed the MCU identification task by matching
FET byte sequences against a database collected from known chips. Perhaps
some constants in mspdebug's drivers/fet_db.c are the same as in the 0x0FF0
region.
I've wanted to have a routine that could identify the MCU at runtime for a
while myself, but the information isn't readily available.
Peter
On Thu, Dec 1, 2011 at 10:05 AM, Mitnacht, Thomas <t-mitna...@ti.com> wrote:
> MSP430G2231 datasheet page 11 should give you what you need
> http://www.ti.com/lit/ds/symlink/msp430g2231.pdf
>
> Thanks,
> Thomas Mitnacht
>
>
> -----Original Message-----
> From: Bob von Knobloch [mailto:b...@vknobloch.de]
> Sent: Thursday, December 01, 2011 4:59 PM
> To: mspgcc-users@lists.sourceforge.net
> Cc: mspgcc-users@lists.sourceforge.net
> Subject: Re: [Mspgcc-users] MSP430 Device ID Bytes
>
> On 01/12/11 16:33, Mitnacht, Thomas wrote:
> > Bob,
> > You are right, SLAU320 already talks about how to identify a derivative.
> The related memory configuration needs to read from the device datasheet.
> We are working on a machine readable database as part of our debug stack,
> but this will not be available until m/o next year.
> >
> > Thanks,
> > Thomas Mitnacht
>
> Hmm, I could not find any relevant information in the device datasheets (I
> have studied: MSP430G2231, 2232 & 2332), or are you building your database
> from other sources?
>
> Thanks to you too,
>
> Bob
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security threats,
> fraudulent activity, and more. Splunk takes this data and makes sense of
> it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
