Re: Disable watchdog timer in crt0.S & BSS initialization

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 <
[email protected]> wrote:

> On Wed, Dec 3, 2014 at 7:47 PM, Peter Bigot <[email protected]> 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/[email protected]/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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users