Quantcast

Disable watchdog timer in crt0.S & BSS initialization

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Disable watchdog timer in crt0.S & BSS initialization

Olivier Girard
Hi all,

I am currently updating the verification environment of the openMSP430 to
support the new Redhat/TI GCC toolchain.

The first thing I noticed is that the *crt0* code by default assumes that
the watchdog WDTCTL register is mapped at 0x015c...
Does someone knows if there is a magic switch to change the default
behavior and map the register to 0x0120 ? (I hope to avoid a re-compile of
the crt0.S stuff)

Here is the snippet:
"...
Disassembly of section .text:

0000c010 <__start>:
    c010: 31 40 00 04 mov #1024, r1 ;#0x0400

0000c014 <.Loc.39.1>:
    c014: b2 40 80 5a mov #23168, &*0x015c* ;#0x5a80
    c018: 5c 01
..."


In addition, I am also experiencing problem with the initialization of
global variables.
For example I have a global variable initialized as following in my code:
"...
volatile char shift_direction = 0x01;  // Global variable
..."

Now, when the CPU enters the main(), I noticed that the memory location
where my variable is mapped to is not set 0x01...
I assume that this initialization is meant to be done by the
*__crt0_init_bss* procedure but it is somehow not working properly.

As I also use a linker script provided with the new toolchain, I was not
really expecting any problem on that side (note that everything worked
perfectly with the MSPGCC port from Peter).

I'm sorry for not being able to give you a better description (toolchains
are definitely not by speciality :-/) but I would be happy about any
suggestion... or maybe someone already experienced similar problems.

BTW, here are my GCC calls:
"...
msp430-elf-gcc -mcpu=msp430 -mhwmult=none -O2 -Wall -g   -c -o main.o main.c
msp430-elf-gcc -mcpu=msp430 -T linker.x -o sandbox.elf main.o
..."


Thanks a lot in advance,
Olivier

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Olivier Girard
Sorry for the confusion, I meant *.data* initialization... not *.bss*

Thanks,
Olivier

On Wed, Dec 3, 2014 at 10:54 PM, Olivier Girard <[hidden email]> wrote:

> Hi all,
>
> I am currently updating the verification environment of the openMSP430 to
> support the new Redhat/TI GCC toolchain.
>
> The first thing I noticed is that the *crt0* code by default assumes that
> the watchdog WDTCTL register is mapped at 0x015c...
> Does someone knows if there is a magic switch to change the default
> behavior and map the register to 0x0120 ? (I hope to avoid a re-compile of
> the crt0.S stuff)
>
> Here is the snippet:
> "...
> Disassembly of section .text:
>
> 0000c010 <__start>:
>     c010: 31 40 00 04 mov #1024, r1 ;#0x0400
>
> 0000c014 <.Loc.39.1>:
>     c014: b2 40 80 5a mov #23168, &*0x015c* ;#0x5a80
>     c018: 5c 01
> ..."
>
>
> In addition, I am also experiencing problem with the initialization of
> global variables.
> For example I have a global variable initialized as following in my code:
> "...
> volatile char shift_direction = 0x01;  // Global variable
> ..."
>
> Now, when the CPU enters the main(), I noticed that the memory location
> where my variable is mapped to is not set 0x01...
> I assume that this initialization is meant to be done by the
> *__crt0_init_bss* procedure but it is somehow not working properly.
>
> As I also use a linker script provided with the new toolchain, I was not
> really expecting any problem on that side (note that everything worked
> perfectly with the MSPGCC port from Peter).
>
> I'm sorry for not being able to give you a better description (toolchains
> are definitely not by speciality :-/) but I would be happy about any
> suggestion... or maybe someone already experienced similar problems.
>
> BTW, here are my GCC calls:
> "...
> msp430-elf-gcc -mcpu=msp430 -mhwmult=none -O2 -Wall -g   -c -o main.o
> main.c
> msp430-elf-gcc -mcpu=msp430 -T linker.x -o sandbox.elf main.o
> ..."
>
>
> Thanks a lot in advance,
> Olivier
>
>
>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Peter Bigot-4
In reply to this post by Olivier Girard
On Wed, Dec 3, 2014 at 3:54 PM, Olivier Girard <[hidden email]> wrote:

> Hi all,
>
> I am currently updating the verification environment of the openMSP430 to
> support the new Redhat/TI GCC toolchain.
>
> The first thing I noticed is that the *crt0* code by default assumes that
> the watchdog WDTCTL register is mapped at 0x015c...
> Does someone knows if there is a magic switch to change the default
> behavior and map the register to 0x0120 ? (I hope to avoid a re-compile of
> the crt0.S stuff)
>
> Here is the snippet:
> "...
> Disassembly of section .text:
>
> 0000c010 <__start>:
>     c010: 31 40 00 04 mov #1024, r1 ;#0x0400
>
> 0000c014 <.Loc.39.1>:
>     c014: b2 40 80 5a mov #23168, &*0x015c* ;#0x5a80
>     c018: 5c 01
> ..."
>
Interesting.

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), and second the reset value can't be hard-coded
because different clock rates are used on different MCUs, and the right bit
pattern for one will leave another misconfigured once the CRT code
completes.

mspgcc worked around the first issue by defining symbols for all the
registers, so they didn't have to be resolved until non-relocatable link
time.  Oddly, Code Composer Studio's linker files do this, but the ones
TI's providing for GCC don't.  (Absence of symbols also complicates
hardware multiply because if symbols were used instead of address values
some of the MPY32 variation points could be eliminated.)

The second issue can be resolved by creating a reset value based on reading
the power-up value.  The code sequence necessary is:

        mov.b   &__WDTCTL, r5
        bis     #0x5a08, r5
        mov     r5, &__wdt_clear_value

unless that doesn't work for the new FR2xx/4xx WDT peripheral.

(Not that this helps you, but somebody should probably file a bug report
against newlib, which is where those files live.)

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Peter Bigot-4
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 <
[hidden email]> wrote:

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