The new memmap macro draws FFFFFFFF areas--which are likely uninitialized flash--as black. '.word ????' code--which I find large expanses of in some ripped images--are grey. This coloring should only be apparent on code which has been dumped from a chip, as most compilers leave such expanses undefined. I also fixed the ragged edge and overlapping pixel bugs. A screenshot of the default programming of the MSP-EXP430FG4618 kit follows.
The shell directive is now default, so typing "m4s shell" can now be shortened to "m4s" if no parameters are necessary.
karen% svn update
At revision 50.
karen% m4s
msp430static r50
from Sat, 12 Apr 2008
Copyright (c) 2008, Travis Goodspeed <travis at utk.edu>
This program is free software. You can distribute it and/or modify it
under the terms of the GNU General Public License version 2.
m4s sql>
I'm interested in the BSL code of the various msp430 chips. If you use msp430static on a ROM image recovered from a physical device, please run the following script to send me the chip's BSL code:
m4s sql> .contribute.bsl
BSL found for chipid=f46f.
Please email ./bsl_f46f.txt.gz to <tmgoodspeed at gmail.com>
with 'CONTRIBUTE_BSL f46f' as the title.
m4s sql>
Cheers,
--Travis Goodspeed
<travis at utk.edu>
1 comment:
The black region, composed of repeating 0xFFFF, is easy enough to explain. Blanked flash ROM bits default to 1. The grey is less easily explained.
The grey region in the above is composed of little endian words such as 0x03d4, 0x0415, 0x042a, etc. The more significant byte is always 03 or 04, while the less significant byte seems to be random. (I've not checked its distribution to see how random.) Please email me or post a comment in reply if you can explain this.
--Travis
Post a Comment