Re: [Mspgcc-users] 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 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=164703151iu=/4140/ostg.clktrk___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Disable watchdog timer in crt0.S BSS initialization
Sorry for the confusion, I meant *.data* initialization... not *.bss* Thanks, Olivier On Wed, Dec 3, 2014 at 10:54 PM, Olivier Girard olgir...@gmail.com 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: c010 __start: c010: 31 40 00 04 mov #1024, r1 ;#0x0400 c014 .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=164703151iu=/4140/ostg.clktrk___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Re: [Mspgcc-users] Disable watchdog timer in crt0.S BSS initialization
On Wed, Dec 3, 2014 at 3:54 PM, Olivier Girard olgir...@gmail.com 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: c010 __start: c010: 31 40 00 04 mov #1024, r1 ;#0x0400 c014 .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=164703151iu=/4140/ostg.clktrk___ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
