Assuming this was meant to be cc'd to the list. TI: Please take note of
this thread.
On Wed, Dec 3, 2014 at 9:11 PM, Przemek Klosowski <
przemek.klosow...@gmail.com> wrote:
> On Wed, Dec 3, 2014 at 7:47 PM, Peter Bigot <big...@acm.org> wrote:
> > The existing solution is wrong in a couple ways: first the address of
> > WDTCTL should not be hard-coded (there are three possible locations
> across
> > the current set of MCUs, with 0x15c being wrong for non-5xx MCUS
> including
> > the new FR2xx/FR4xx ones),
>
> I see only two addresses: 0x15C and 0x120.
> I loaded the peripheral register data from thje linker script files
> into a sqlite database to have a good overview of the peripherals
> across the MSP430 line:
>
> perl -lane '($f)=($ARGV=~m#s/(.*)/per#); ($p,$l)=/__(.*) = (.*);/;
> warn "$ARGV $_" if $f eq ""; print "$f $p $l"'
> /usr/msp430/lib/ldscripts/*/periph.x > x
>
> sqlite3 msp430.db
> create table c (chip, dev, adr);
> .mode list
> .separator ‘ ‘
> .import x c
>
Yes, I did something like this with the analysis subdirectory of msp430mcu,
but text-file based:
https://sourceforge.net/p/mspgcc/msp430mcu/ci/master/tree/analysis/
I haven't bothered to replicate that for the new headers; grep | sort |
uniq handles most of my needs.
>
> The WDTCTL addresses can be extracted by:
> select distinct adr from c where dev like 'wdtctl';
>
> and it shows 15c and 120 (the former tends to be in 4/5/6xxx series
> but not universally so)
>
llc[83]$ grep WDTCTL msp430fr4133.h
#define WDTCTL_ 0x01CC /* Watchdog Timer Control */
> The database turns out to be useful to find stuff like 'what OTHER
> devices are at 0x120 (it turns out that it's PMMCTL0)
>
> select distinct dev from c where dev not like 'wdtctl%' and adr like
> '0x0120';
>
> whereas 0x15c sometimes holds ADC12MEM14 and MPY32CTL0
>
llc[86]$ grep -h 015C *.h | sort | uniq
#define ADC12MEM14_ 0x015C /* ADC12 Conversion Memory 14 */
#define MPY32CTL0_ 0x015C /* MPY32 Control Register 0 */
#define SYSSNIV_ 0x015C /* System NMI vector generator */
#define UCA0IFG_ 0x015C /* USCI A0 Interrupt Flags Register
*/
#define WDTCTL_ 0x015C /* Watchdog Timer Control */
TI: you really need to fix the infrastructure so the Red Hat folks can
refer to peripheral registers symbolically in infrastructure code instead
of hard-coding addresses as integer constants.
DO NOT use names in the user namespace like WDTCTL, as in the CCS cmd files:
llc[215]$ grep WDTCTL msp430f5438a.cmd
WDTCTL = 0x015C;
WDTCTL_L = 0x015C;
WDTCTL_H = 0x015D;
Use a double-underscore prefix (__WDTCTL) or negotiate with the GNU folks
to come up with something that will conflict with neither the GNU toolchain
nor intrude on the user namespace. See
http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg12212.html
if you missed the start of this. You'll need to change iomacros.h to use
something like this:
#define sfrb_(x,x_) volatile __MSPGCC_PERIPHERAL__ unsigned char x
__asm__("__" #x)
#define sfrb(x,x_) extern sfrb_(x,x_)
so that object files referring to peripheral registers reference the
symbolic name instead of embedding a constant that might be wrong if the
code's in a library linked into applications for multiple MCUs.
Peter
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
