[Mspgcc-users] Instruction reordering

[Wayne Uroda]

Hello,

I have a question about instruction reordering in the compiler.

In this blog
http://preshing.com/20120625/memory-ordering-at-compile-time/
It says that a compiler barrier should be used where writes to memory must not 
be reordered. 

My MSP430 code is all bare metal, foreground-background code and I am not using 
any type of RTOS, so it could be considered lock-free.

Anyway, a new employee at my work pointed out that the compiler is free to 
reorder my memory writes, even those marked volatile. I said that I had never 
actually seen mspgcc do this, but now I am curious: will mspgcc reorder memory 
writes, eg to global variables?
Is this dependent on the msp430 side of gcc (the backend), or more on the 
AST/RTL side?

Or to put it another way, should I be reviewing my shared (between background 
and ISR) variables and placing compiler barriers where variables must be stored 
in an exact order?

I am using a very old version of mspgcc, 3.2.3, I think it was the last stable 
Windows binary release before the CPUX instructions started making their way 
in, sorry I don't know the version, from 2008/2009 maybe?

Thanks
- Wayne

--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] while(flag)

[Wayne Uroda]

"flag" should be marked volatile, otherwise the optimiser may see it never 
changes inside the body of the loop and omit checking the flag entirely.

- Wayne

> On 9 Nov 2015, at 08:01, Ian Chapman  wrote:
> 
> Hi all,
>  I'm having difficulty understanding this situation.
> flag = 1;
> while ( 0 != flag )
> {
> code;
> }
>  generates strange assembly code till I commented out
> // flag = 1;
> it looked to me like the optimizer realized that from then on the code 
> would be planted in a " $  jmp  $; " situation.  I intended flag to be 
> cleared after an ADC interrupt.  ie set flag and wait for it to be cleared.
> Test code snippet and Makefile follow.
> 
> Any comment greatly appreciated.  Ian.
> 
> /*Test of while loop msp430 version of gnu c */
> 
> #include 
> void funct1(void);
> int flag, temp, temp2;
> 
> int main(void)
> {
> WDTCTL = WDTPW + WDTHOLD; // Disable watchdog timer
> //Internal clock to 8MHz
> DCOCTL = CALDCO_1MHZ;//Page 3 device specific data sheet.
> BCSCTL1 = CALBC1_1MHZ;// ---"""---
> BCSCTL2 = 0;
> BCSCTL3 = 0;
> //flag = 1;  //The optimization makes a mess till I commented this out.
> temp = 0;
> 
> while( 0 != flag )  //flag = 0 from Interrupt routine.
> {
> temp2 ++;  //This did not help
> }
> 
> funct1();
> temp2 = temp;
> return 1;
> }
> 
> void funct1(void) {
> temp ++;
> }
> 
> Makefile
> CC=msp430-gcc
> CFLAGS=-Os -Wall -g -mmcu=msp430g2553
> #CFLAGS=-Os -Wall -g -mmcu=msp430f5438a
> OBJ = while.o
> %.o: %.c $(DEPS)
> $(CC) -c -o $@ $< $(CFLAGS)
> while: $(OBJ)
> $(CC) -o $@.elf $^ $(CFLAGS)
> Dis assembly
> main:
> 0c03e: b2 40 80 5a 20 01 MOV #0x5a80, &0x0120
> 0c044: d2 42 fe 10 56 00 MOV.B   &0x10fe, &0x0056
> 0c04a: d2 42 ff 10 57 00 MOV.B   &0x10ff, &0x0057
> 0c050: c2 43 58 00   CLR.B   &0x0058
> 0c054: c2 43 53 00   CLR.B   &0x0053
> 0c058: 92 43 02 02   MOV #0x0001, 
> 0c05c: 82 43 04 02   CLR 
> 0c060: ff 3f JMP 0xc060 //Planted
> 0c062: 32 d0 f0 00   BIS #0x00f0, SR  //Clks/cpu off?
> 0c066: fd 3f JMP 0xc062
> 0c068: 30 40 72 c0   BR  #0xc072
> funct1:
> 0c06c: 92 53 04 02   INC 
> 0c070: 30 41 RET
> 0c072: 00 13 RETI
> 0c074: ff ff ff ff   AND.B   @R15+,  0x(R15)
> 0c078: ff ff
> (mspdebug)
> 
> 
> --
> ___
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Thingsquare Eclipse and GDB

[Wayne Uroda]

Hi Ben,

I've been using eclipse and MSPGCC for a long time now, and while my
configuration might not match exactly what you want (I tend to avoid cygwin
where possible because the DLL nightmares drive me mad), here are the
instructions I put together for myself to follow and they've always worked
for me. You might find them useful (attached PDF).

Thanks
- Wayne

On Fri, Feb 20, 2015 at 9:05 PM, BDD b...@avance-tech.com wrote:

 Hi All
 I need some help.
 I'm running Thingsquare mist1.0.0 on my machine in Eclipse Luna.  My
 project
 compiles nicely using Cygwin make. My project runs and I can flash my MSP
 with my new code and all is fine and work as it is suppose to.
 When I go into debug mode using TI's debugger agent and
 \bin\msp430-elf-gdb.exe the agent indicate that the server is connected.  I
 can step in the main loop of the code and Eclipse goes to the source code,
 I
 can only step over in the main loop , not step into.
 When I set a break point deeper in my code the agent indicates that the
 break point is hit but Eclipse does not goes to the source code.  If I
 navigate some of the traces I can see that the break point reach was at the
 correct place in the Dissambly code .  I can step the dissambly code but
 can
 not see the source code or any variables.

 Here's my setup
 Using Cygwin64 make to build
 MSP-GCC (msp430-toolchain-win-x86-3.0)
 my GDB debugger is msp430-elf-gdb.exe (from
 msp430-gcc-full-windows-installer-3.2.3.0)
 All under Windows8.1 (yes I know..)

 What am I doing wrong or where can I scratch?




 --
 View this message in context:
 http://msp430-gcc-users.1086195.n5.nabble.com/Thingsquare-Eclipse-and-GDB-tp7316.html
 Sent from the MSP430 gcc - Users mailing list archive at Nabble.com.


 --
 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=190641631iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
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=190641631iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Looking at a a core; reading the stack.

[Wayne Uroda]

Hi Mark,

I've never had luck with backtraces even when using GDB (perhaps due to 
excessive optimisation).

I have managed to do a manual backtrace. If you know the PC then that will give 
you the current function. You can then go back through each word of the stack 
and look for values which match addresses which immediately follow a call to 
this function, and so on. With this dumb approach there is a chance of error 
and you will need a disassembled listing to do it. Not the most convenient 
method but I did have some success with it once when I was in a bind.

- Wayne



On 08/08/2014, at 14:47, Mark Rages markra...@gmail.com wrote:

 I am debugging a rare intermittent problem.   When it happens, I want to
 record all of RAM into flash so i can look at it later.
 
 My problem is, given a block of memory that represents the program's state,
 how do I decode the stack to see what was executing when the event happened?
 
 I suppose gdb knows how to do this.  How can I get a binary image file to
 something gdb can read?  Is there a utility to convert it to the kinds of
 corefile gdb will read?
 
 Regards,
 Mark
 markrages@gmail
 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Producing TI text files

[Wayne Uroda]

Thank you I will look into both solutions :)

- Wayne

On 01/08/2014, at 22:25, Adam Ford aford...@gmail.com wrote:

 Check out this example Makefile
 
 https://github.com/uctools/msp430-template/blob/master/Makefile
 
 Using srec_cat to generate the txt file.  Specify -TITXT
 After than run unix2dos on the output file to use the proper CR/LF stuff.
 
 # TI TXT file
 $(OUTDIR)/%.txt: $(OUTDIR)/%.hex
$(MAKETXT) -O $@ -TITXT $ -I
$(UNIX2DOS) $(OUTDIR)/$(TARGET).txt
 
 
 
 
 
 On Thu, Jul 31, 2014 at 9:05 AM, Chris Liechti cliec...@gmx.net wrote:
 
 Am 31.07.2014 um 03:24 schrieb Wayne Uroda: Hello all,
 
 I need to produce a Ti .txt file to use with Ti USB BSL utility.
 
 Caveat - I already have ihex2titext.exe which came with some ancient
 version of MSPGCC. The exe file is dated November 2006.
 
 the current version is here
 https://pypi.python.org/pypi/python-msp430-tools (or here if you want to
 look at the source https://launchpad.net/python-msp430-tools/trunk)
 
 ihex2titext does not exist in that form anymore, instead there is
 msp430.memory.convert.
 
 running the tool from source (assuming a basic python 2.7 installation
 from python.org is installed on system):
 
 python -m msp430.memory.convert input.any -f titext -o output.txt
 
 (you could also omit -f as titext is the default)
 in case of a binary distribution, the call is slightly different:
 
 msp430-tool.exe convert ...
 
 
 The problem with
 this version is that it generates one contiguous listing for main code
 memory,
 [...]
 This seems to crash the Ti USB BSL utility (or crash the on chip
 code  which
 then causes the utility to crash). When I use a program like
 Elprotronic to
 program this file and then read it back off the chip I get a file
 which looks like the following:
 [...]
 Data blocks continue in groups of 256 bytes per block.
 
 my current tool still outputs one large blob. but it would be easy to
 change that.
 
 I've checked and it is definitely not the uppercase/lowercase
 difference between the two .txt files. I've also checked and it isn't
 the last block length/padding (all  blocks in
 the elprotronic file are 256 bytes long and start on a 256 byte
 boundary). I believe it is most likely a bug in Ti's USB BSL utility
 or in theUSB BSL
 code on chip which is avoided by breaking the data into 256 byte
 blocks.
 
 i do not use their tool, i've always used my own msp430-bsl (which is
 included in the project linked above)
 
 My question: Does there exist a more modern tool for creating Ti
 text  which
 might break up the blocks in this manner? My long-term fallback
 position is
 to get the python code from CVS, rework and rebuild it. I'd rather
 not since I've never worked with python and don't have a lot of time
 for this side project.
 
 
 
 
 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the future.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users
 
 --
 Want fast and easy access to all the code in your enterprise? Index and
 search up to 200,000 lines of code with a free copy of Black Duck
 Code Sight - the same software that powers the world's largest code
 search on Ohloh, the Black Duck Open Hub! Try it now.
 http://p.sf.net/sfu/bds
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] Producing TI text files

[Wayne Uroda]

Hello all,

I need to produce a Ti .txt file to use with Ti USB BSL utility.

Caveat - I already have ihex2titext.exe which came with some ancient
version of MSPGCC. The exe file is dated November 2006. The problem with
this version is that it generates one contiguous listing for main code
memory, eg:

@4400
55 42 5c 01 35 d0 08 5a 82 45 92 43 31 40 00 44
3f 40 ac 00 0f 93 08 24 92 42 92 43 5c 01 2f 83
9f 4f f4 c2 00 24 f8 23 3f 40 e6 1e 0f 93 07 24
92 42 92 43 5c 01 1f 83 cf 43 ac 24 f9 23 b2 40
80 5a 5c 01 b0 12 e6 61 b0 12 b0 5e f2 f0 df ff
62 02 f2 d0 20 00 64 02 5f 43 b0 12 e0 63 5f 43
b0 12 fe 63 5f 43 b0 12 1c 64 3e 40 65 00 05 3c
3f 40 07 00 1f 83 fe 23 03 43 3e 53 f9 23 b0 12
20 a2 b0 12 16 90 b0 12 dc a0 b0 12 b2 a7 03 12
03 12 30 12 e4 40 03 12 0c 43 3d 40 64 00 3e 40
f7 ba 3f 40 f6 a3 b0 12 ee 46 31 52 03 12 03 12
30 12 e2 40 03 12 0c 43 3d 40 64 00 3e 40 fe ba
3f 40 84 a1 b0 12 ee 46 31 52 4f 43 b0 12 06 8a
b0 12 46 62 4f 93 19 24 3f 40 06 bb b0 12 ea 58
b0 12 12 8a 3f 40 b0 93 b0 12 0c 8a 3f 40 d0 89
b0 12 e4 93 3f 40 f4 89 b0 12 ee 93 3f 40 fa 89
b0 12 f4 93 b0 12 fa 93 1c 3c 3f 40 1e bb b0 12
ea 58 b0 12 dc 92 4f 93 03 20 5f 43 b0 12 c6 92
3f 40 f2 8f b0 12 14 84 3f 40 ce 8f b0 12 0e 84
3f 40 00 84 b0 12 10 90 b0 12 a0 8f 1f 43 b0 12
ae 82 d2 43 08 24 b0 12 0c 4a 0f 43 32 d0 f0 00
fd 3f 30 40 dc ba 8f 4e 00 00 bf 42 fe ff bf 40
44 44 fc ff bf 40 55 55 fa ff bf 40 66 66 f8 ff
bf 40 77 77 f6 ff bf 40 88 88 f4 ff bf 40 99 99
f2 ff bf 40 aa aa f0 ff bf 40 bb bb ee ff bf 40
cc cc ec ff bf 40 dd dd ea ff bf 40 ee ee e8 ff
8f 4d e6 ff 8f 43 e4 ff 3f 50 e4 ff 30 41 b2 40
00 02 40 03 b2 40 10 00 42 03 82 43 50 03 b2 40
c0 5d 52 03 b2 d0 12 00 40 03 32 c2 03 43 1c 40
dc de 21 4c 3e 41 80 4e 28 de 3f 41 3e 41 3d 41
3c 41 3b 41 3a 41 39 41 38 41 37 41 36 41 35 41
...
Data block continues for total of 2042 lines.


This seems to crash the Ti USB BSL utility (or crash the on chip code which
then causes the utility to crash). When I use a program like Elprotronic to
program this file and then read it back off the chip I get a file which
looks like the following:

@4400
55 42 5C 01 35 D0 08 5A 82 45 92 43 31 40 00 44
3F 40 AC 00 0F 93 08 24 92 42 92 43 5C 01 2F 83
9F 4F F4 C2 00 24 F8 23 3F 40 E6 1E 0F 93 07 24
92 42 92 43 5C 01 1F 83 CF 43 AC 24 F9 23 B2 40
80 5A 5C 01 B0 12 E6 61 B0 12 B0 5E F2 F0 DF FF
62 02 F2 D0 20 00 64 02 5F 43 B0 12 E0 63 5F 43
B0 12 FE 63 5F 43 B0 12 1C 64 3E 40 65 00 05 3C
3F 40 07 00 1F 83 FE 23 03 43 3E 53 F9 23 B0 12
20 A2 B0 12 16 90 B0 12 DC A0 B0 12 B2 A7 03 12
03 12 30 12 E4 40 03 12 0C 43 3D 40 64 00 3E 40
F7 BA 3F 40 F6 A3 B0 12 EE 46 31 52 03 12 03 12
30 12 E2 40 03 12 0C 43 3D 40 64 00 3E 40 FE BA
3F 40 84 A1 B0 12 EE 46 31 52 4F 43 B0 12 06 8A
B0 12 46 62 4F 93 19 24 3F 40 06 BB B0 12 EA 58
B0 12 12 8A 3F 40 B0 93 B0 12 0C 8A 3F 40 D0 89
B0 12 E4 93 3F 40 F4 89 B0 12 EE 93 3F 40 FA 89
@4500
B0 12 F4 93 B0 12 FA 93 1C 3C 3F 40 1E BB B0 12
EA 58 B0 12 DC 92 4F 93 03 20 5F 43 B0 12 C6 92
3F 40 F2 8F B0 12 14 84 3F 40 CE 8F B0 12 0E 84
3F 40 00 84 B0 12 10 90 B0 12 A0 8F 1F 43 B0 12
AE 82 D2 43 08 24 B0 12 0C 4A 0F 43 32 D0 F0 00
FD 3F 30 40 DC BA 8F 4E 00 00 BF 42 FE FF BF 40
44 44 FC FF BF 40 55 55 FA FF BF 40 66 66 F8 FF
BF 40 77 77 F6 FF BF 40 88 88 F4 FF BF 40 99 99
F2 FF BF 40 AA AA F0 FF BF 40 BB BB EE FF BF 40
CC CC EC FF BF 40 DD DD EA FF BF 40 EE EE E8 FF
8F 4D E6 FF 8F 43 E4 FF 3F 50 E4 FF 30 41 B2 40
00 02 40 03 B2 40 10 00 42 03 82 43 50 03 B2 40
C0 5D 52 03 B2 D0 12 00 40 03 32 C2 03 43 1C 40
DC DE 21 4C 3E 41 80 4E 28 DE 3F 41 3E 41 3D 41
3C 41 3B 41 3A 41 39 41 38 41 37 41 36 41 35 41
34 41 00 13 1F 43 82 43 40 03 30 41 02 12 32 C2
...
Data blocks continue in groups of 256 bytes per block.

I've checked and it is definitely not the uppercase/lowercase difference
between the two .txt files.
I've also checked and it isn't the last block length/padding (all blocks in
the elprotronic file are 256 bytes long and start on a 256 byte boundary).
I believe it is most likely a bug in Ti's USB BSL utility or in the USB BSL
code on chip which is avoided by breaking the data into 256 byte blocks.

My question: Does there exist a more modern tool for creating Ti text which
might break up the blocks in this manner? My long-term fallback position is
to get the python code from CVS, rework and rebuild it. I'd rather not
since I've never worked with python and don't have a lot of time for this
side project.

Thanks for your advice

- Wayne
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] __delay_cycles() is not working with timerA interrupts

[Wayne Uroda]

I believe your problem is that in the timer A1 ISR, you need to read from
TA0IV in order to clear the interrupt (timer A1 isn't fired from an
interrupt flag but rather from the grouping of events which are then routed
through TA0IV, unless I am mistaken)

17.2.6 Timer_A Interrupts
Two interrupt vectors are associated with the 16-bit Timer_A module:
• TAxCCR0 interrupt vector for TAxCCR0 CCIFG
• TAxIV interrupt vector for all other CCIFG flags and TAIFG

17.2.6.1 TAxCCR0 Interrupt
... The TAxCCR0 CCIFG flag is automatically reset when the TAxCCR0 interrupt
request is serviced.

17.2.6.2 TAxIV, Interrupt Vector Generator
...
Any access, read or write, of the TAxIV register automatically resets the
highest-pending interrupt flag. If
another interrupt flag is set, another interrupt is immediately generated
after servicing the initial interrupt.
...

- Wayne


On Fri, Jul 4, 2014 at 4:22 PM, Kirill Popov kirill.s.po...@gmail.com
wrote:

 Hello!
 I've got an issue with using __delay_cycles() while also utilizing
 TimerA interrupts.
 It seems that __delay_cycles(); is not working if TimerA interrupts
 are enabled. Even if nothing is done in interrupt routine.
 Here is a sample code:
 == main.c 
 #include msp430g2553.h

 // Timer A0 interrupt service routine (at top value)
 #pragma vector=TIMER0_A0_VECTOR
 __interrupt void Timer_A0 (void) {
 TACCTL0 = ~(TAIFG); // clear interrupt  flag
 }

 // Timer A1 interrupt service routine (in the middle)
 #pragma vector=TIMER0_A1_VECTOR
 __interrupt void Timer_A1 (void) {
 if (TACCTL1  TAIFG) {
 TACCTL1 = ~(TAIFG); // clear interrupt  flag
 }
 }

 int main(void) {
 WDTCTL = WDTHOLD | WDTPW; //halt watchdog
 P1REN = ~(BIT6); // pull-ups are disabled on pins 0 and 6
 P1DIR |= BIT6; // pins 0 and 6 are outputs
 P1OUT = ~(BIT6); // pin 6 and pin 0 are LOW

 TACCR0 = 0x0fff; // set top value for timerA
 TACCR1 = 0x00ff; //set LED glow power
 TACCTL0 = (CCIE); // enable compare interrupt for TACCR0
 TACCTL1 = (CCIE); // enable compare interrupt for TACCR1
 TACTL = (TASSEL1 | MC0 | TACLR | TAIE); // SMCLK, cnt UP, clear,
 interrupt
 _BIS_SR(GIE); // enable blobal interrupts
 for (;;) {
 P1OUT ^= BIT6;
 __delay_cycles(100);
 }
 return 0;
 }
  end of main.c =

 I expect this code to blink with a LED on P1.6 with approximately 1
 second interval (no precise timing required). But all I see is the LED
 just lit all the time.
 If I comment out the line with _BIS_SR(GIE); the LED is blinking as
 expected.

 What could be the reason? My guess is interrupt routine is somehow
 spoiling registers used by __delay_cycles(). Is that true?
 Would be thankful for a workaround if there is such.

 I'm using msp430-gcc (GCC) 4.6.3 20120301 (mspgcc LTS 20120406
 unpatched) from Debian repository to build code for TI Launchpad
 MSP-EXP430G2 (M430G2553 chip).

 Thank you!
 --
 Best regards,
 Kirill Popov.

 
 Other ways to contact me:
 Gtalk: kirill.s.po...@gmail.com
 Cell phone: +79052062619
 LinkedIn: http://ru.linkedin.com/in/kspopov


 --
 Open source business process management suite built on Java and Eclipse
 Turn processes into business applications with Bonita BPM Community Edition
 Quickly connect people, data, and systems into organized workflows
 Winner of BOSSIE, CODIE, OW2 and Gartner awards
 http://p.sf.net/sfu/Bonitasoft
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] Minimum optimizations required to use inline functions

[Wayne Uroda]

Hi,

I make extensive use of inline functions in my code, as below:

extern inline void setClockLine(Bool value)
{ ... }

Sometimes I put these definitions in .c files, sometimes in .h files (I'm
not sure if that makes a difference, apart from scope).

The code builds and links at -O (or -O1, -O2) but does not link at -O0, I
get many linker errors like
   i2c.c:67: undefined reference to `setClockLine'

I wonder, what is/are the minimum flag(s) required to make inlining work?
If I use just these flags am I likely to get better debug experience? There
are no inline functions involved in the code I am trying to debug but I am
still having trouble stepping through the code.

I notice that newer versions of gcc have a -Og flag, does MSPGCC support
this?
I am running msp430-gcc (GCC) 4.6.3 20120301 (mspgcc LTS 20120406 unpatched)

I am using a combination of mspdebug, eclipse CDT, zylin embedded debug
native and msp430-gdb for debugging.

Thanks
Wayne
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Writing an ISR in pure assembly

[Wayne Uroda]

Even though I think it is sorted now, I still wonder (for my own knowledge and 
completeness) if there is a way to either override just one of the vector 
positions (or is there a magic name that given to the function accomplishes the 
same thing) or is there a way to override all of the vector table?

I did it with the aid of nostartfiles many years ago (had need to write my own 
boot loader anyway) but I wonder if there is a way to do it without losing the 
startup routines.

- Wayne



On 11/12/2013, at 22:23, Peter Bigot big...@acm.org wrote:

 See https://github.com/pabigot/freertos-mspgcc for FreeRTOS using MSPGCC as 
 of mid 2012.  The use of naked is in Source/portable/GCC/MSP430, but does not 
 apply to the timer ISR itself.  It was not necessary to use external assembly 
 sources.
 
 http://pabigot.github.io/bsp430/freertos_8h.html may also be useful.
 
 As I recall I did have FreeRTOS working under BSP430 and so supporting all 
 MCUs in the product line.  The freertos-bsp430 repository was intended to 
 supersede freertos-mspgcc; at this point there is no public difference, 
 though I seem to have some pending updates in my local workspace.  None of 
 that is actively supported but it could be if people find it useful. 
 
 Peter
 
 On Tue, Dec 10, 2013 at 9:48 PM, Wayne Uroda w.ur...@gmail.com wrote:
 Hello,
 
 I am trying to port FreeRTOS to the MSP430F5519.
 
 In order to write the context switching part, I need to write a timer
 interrupt service routine in pure assembly (the compiler right now is doing
 some extra push before I can do anything in the ISR, even with nothing in
 the body...)
 
 How can I place a function (defined in an assembly file) into the vector
 table?
 
 Thanks,
 
 - Wayne
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics 
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users
 
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] Writing an ISR in pure assembly

[Wayne Uroda]

Hello,

I am trying to port FreeRTOS to the MSP430F5519.

In order to write the context switching part, I need to write a timer
interrupt service routine in pure assembly (the compiler right now is doing
some extra push before I can do anything in the ISR, even with nothing in
the body...)

How can I place a function (defined in an assembly file) into the vector
table?

Thanks,

- Wayne
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Writing an ISR in pure assembly

[Wayne Uroda]

Yes I've tried it, however on an interrupt function it seems to only do half 
the job!

Found something that works, putting a single branch in the ISR to a naked 
function. At least it seems to work for now, who knows when the compiler will 
decide to insert a push before my branch and break it all.

- Wayne

On 11/12/2013, at 16:29, Hynek Sladky ec...@centrum.cz wrote:

 Hi Wayne,
 
 have You tried __attribute__ ((naked)) ? This makes function without any 
 push/pop... just return. Inside body use asm ( ... );
 
 Hynek
 
 
 Dne 11.12.2013 4:48, Wayne Uroda napsal(a):
 Hello,
 
 I am trying to port FreeRTOS to the MSP430F5519.
 
 In order to write the context switching part, I need to write a timer
 interrupt service routine in pure assembly (the compiler right now is doing
 some extra push before I can do anything in the ISR, even with nothing in
 the body...)
 
 How can I place a function (defined in an assembly file) into the vector
 table?
 
 Thanks,
 
 - Wayne
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] SR getting corrupted

[Wayne Uroda]

I don't think bt actually works correctly on mspgdb (at least it never has for 
me in the last 6 years). I recommend you check the sp directly with the info 
registers command (or simply i r). The sp is r1 if I recall correctly.

Then you can dump the memory in your stack and do something of a manual 
backtrace - if you know the current pc (again available through the registers) 
and you have a full assembly listing it should be possible to spot the return 
addresses in the stack (or simply check every word, if it corresponds to a 
location in code just following where you called a function then it is likely a 
return address - note I've only ever done this in my own software which I know 
back-to-front and it is all 16bit addressing, no msp430x).

Or, you could try mspdebug - I think it has many debugging features and 
probably has a working bt command (I am still use mspgdb though so I'm not 
sure).

- Wayne

On 05/09/2013, at 16:38, ravim ravi.mandl...@gmail.com wrote:

 I am working on a project which involves CC2500 and msp430f2274. I have been
 struggling with a bug for more than 4 weeks, and still unable to debug it.
 My code stops working after an hour (just time, however device keep
 receiving packets)
 
 During my debugging, I have checked stack which is fine. I checked globals
 too, which have legitimate values too.
 
 Whenever my code gets stuck, msp430-gdb bt  always always gives me just this
 
 0x8092 in main ()
 
 When I dissemble my code around that address, 
 
 08084: b0 12 72 86   CALL#wor_start
08088: b0 12 38 90   CALL#initializeRandomTimer
0808c: 32 d2 EINT
0808e: 32 d0 50 00   BIS #0x0050, SR
08092: 5f 42 0e 02   MOV.B   radioReady, R15
08096: 5f 93 CMP.B   #0x0001, R15
 
 
 I believe some how my SR is getting corrupted. I would really appreciate why
 it could be getting corrupted. I mean what could be possible reasons for
 getting SR corruption.
 
 Thanks and regards.
 Ravi 
 
 
 
 --
 View this message in context: 
 http://msp430-gcc-users.1086195.n5.nabble.com/SR-getting-corrupted-tp6864.html
 Sent from the MSP430 gcc - Users mailing list archive at Nabble.com.
 
 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Size of global variable

[Wayne Uroda]

Hi Daniel,

Yesterday I was looking at just this and to my surprise there was one extra 
word allocated to .noinit. I had never seen this before in all my years, and 
I was almost filling over it with a pattern to measure my stack usage. My point 
is that one should add the size of bss and data and noinit to find the 
statically allocated area, or is this incorrect?

At runtime you can find the address of the last of the static data by taking 
the address of _end, which is provided by the linker script, something like:

void *_end;
UInt16 endAddr = (UInt16)_end;

(Please let me know if there is a better/preferred way to do this).

You can also get the current stack pointer by doing something like this:
UInt16 sp;

__volatile__ __asm__ ( mov r1, %0 : =g (sp));

This tells the compiler to move the stack pointer into the variable sp using 
any method it chooses (register or memory).

Then you can simply loop from one address to the other and fill with a pattern 
like 0x55 or similar.

I used this only in a debug environment and wouldn't trust to have it run in a 
production environment because it was something I threw together real quick.

- Wayne

On 30/07/2013, at 6:22, Daniel Beer dlb...@gmail.com wrote:

 On Mon, Jul 29, 2013 at 12:56:31PM -0700, ravim wrote:
 My apologies if I am asking something irrelevant to this forum. We are using
 mspgcc and mspdebug for our project. We are facing some issues with what we
 assume might be stack overflow. The timer interrupts stops working after
 around 2 hours, however device still receives packets. Also, when we reset
 the device after timer gets stuck, they never turn back on unless we
 re-install the code.  We are trying to debug.
 
 I wanted to know if there is any possible way we can know the size of global
 variables in the binary? This will help us narrow down a few specifics. We
 know there is something in TinyOs when we make, it let us know size of
 global variables, we are looking for something similar in mspdebug.
 
 We would really appreciate any help.
 
 Try size filename.elf. Add data and bss to get the total size of
 statically allocated data. You can also use size on the individual
 object files if you want to narrow down your search, but remember to use
 --common if you need global (non-static) variables to be counted.
 
 Cheers,
 Daniel
 
 -- 
 Daniel Beer dlb...@gmail.comwww.dlbeer.co.nz
 IRC: inittab (Freenode)PGP key: 2048D/160A553B
 
 --
 Get your SQL database under version control now!
 Version control is standard for application code, but databases havent 
 caught up. So what steps can you take to put your SQL databases under 
 version control? Why should you start doing it? Read more to find out.
 http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] variable reusing

[Wayne Uroda]

Would either of these solutions work?:

- use a scheme like Malloc/free to allocate the buffers when you need them
- allocate the buffers on the stack (is there a practical limit to doing this?) 
and that way they can be recycled when not in use

The terrible downside with stack based allocation is the potential for silent 
and deadly stack overflow. At least a scheme like Malloc/free would give you an 
error, but you wouldn't be able to do anything useful with it at runtime!

It's an interesting idea and would be very useful for embedded development, 

How would the static analysis know when a certain buffer is no longer needed, 
would you need to insert some kind of static release statement/attribute 
somewhere?

- Wayne

On 15/05/2013, at 8:31, Paul Sokolovsky pmis...@gmail.com wrote:

 Hello,
 
 On Wed, 15 May 2013 09:35:14 +1200
 Daniel Beer dlb...@gmail.com wrote:
 
 On Tue, May 14, 2013 at 09:26:46PM +0300, Paul Sokolovsky wrote:
 More interesting question is such support for static (if not global)
 variables. When trying to do Elliptic Curve Cryptography on MSP430
 value line devices which top up at 0.5K RAM, you really wish that
 compiler could pack together static buffers of functions which
 cannot be active at the same time ;-). If anyone know of that to be
 done by gcc, would be nice to get some pointers.
 
 If you have static buffers which are never in use simultaneously, why
 not keep them together in a union { }?
 
 Yes, the talk was about offloading the work of proving
 non-simultaneous access constraints and creation of that union to the
 compiler ;-). Shouldn't be hard for the case of scalar static variables
 (function-local dataflow analysis and interprocedural control flow
 analysis), so I wondered if someone knows it to be implemented. To be
 really useful this should be applied to structural/array vars though,
 and that's much harder.
 
 
 - Daniel
 
 
 -- 
 Best regards,
 Paul  mailto:pmis...@gmail.com
 
 --
 AlienVault Unified Security Management (USM) platform delivers complete
 security visibility with the essential security capabilities. Easily and
 efficiently configure, manage, and operate all of your security controls
 from a single console and one unified framework. Download a free trial.
 http://p.sf.net/sfu/alienvault_d2d
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] Whole program optimization / Link time optimization

[Wayne Uroda]

Hi,

Can anybody comment on LTO or WPO’s effect on optimizing for space  - I have 
run out of flash memory and would rather not refactor my code at the moment. I 
only need 10 more bytes or so, for today at least... Yes it’s not ideal, such 
is life.

I am using mspgcc 20120406-p20120911 and when I pass `–flto` in both the 
compilation and link stages it compiles fine but the linker complains 
“unrecognized option '-plugin'”. I assume LTO isn’t supported at this time?

So then I skipped intermediate .o files altogether and used the following 
command:
msp430-gcc -mmcu=msp430f233 -Os -Wall -Werror -o Coyote.elf all c files

I get the expected message that my code does not fit.

Using –fwhole-program:
msp430-gcc -mmcu=msp430f233 -Os -Wall -Werror -fwhole-program -o Coyote.elf 
all c files

I get the following output:
C:\Users\WAYNEU~1\AppData\Local\Temp\cclYmoCC.o: In function `main':
main.c:(.init9+0x2): undefined reference to `systemDisableInterrupts'
main.c:(.init9+0x6): undefined reference to `PlatformInit'
main.c:(.init9+0xc): undefined reference to `systemEnableCrystalClock'
main.c:(.init9+0x2a): undefined reference to `delay'
main.c:(.init9+0x44): undefined reference to `delay'
main.c:(.init9+0x5e): undefined reference to `delay'
main.c:(.init9+0x78): undefined reference to `delay'
main.c:(.init9+0x80): undefined reference to `delay'
C:\Users\WAYNEU~1\AppData\Local\Temp\cclYmoCC.o:main.c:(.init9+0xa4): more 
undefined references to `delay' follow
C:\Users\WAYNEU~1\AppData\Local\Temp\cclYmoCC.o: In function `main':
main.c:(.init9+0xf8): undefined reference to `batteryGetStateOfCharge'
main.c:(.init9+0x104): undefined reference to `chargeIsPresent'
main.c:(.init9+0x118): undefined reference to `delay'
main.c:(.init9+0x134): undefined reference to `delay'
main.c:(.init9+0x138): undefined reference to `infomemValidate'
main.c:(.init9+0x13c): undefined reference to `logicMainLoop'
collect2: ld returned 1 exit status


I then created two files, test1.c and test2.c

test1.c:
---
void test2(void);

void test1(void)
{
test2();
}

int main()
{
test2();
return 0;
}

---

test2.c:
---
void test1(void);

void test2(void)
{
test1();
}

---

Compiling them:
msp430-gcc -mmcu=msp430f233 -Os -Wall -Werror -fwhole-program -o test.elf 
test1.c test2.c

C:\Users\WAYNEU~1\AppData\Local\Temp\ccs3TYlw.o: In function `main':
test1.c:(.init9+0x2): undefined reference to `test2'
collect2: ld returned 1 exit status

Have I done something wrong?

In the meantime, I will refactor. I don’t even expect WPO/LTO to give me much 
of a space saving anyway.

- Wayne
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Whole program optimization / Link time optimization

[Wayne Uroda]

Thanks, it works great!

- Wayne

From: Peter Bigot 
Sent: Monday, April 22, 2013 11:17 AM
To: Wayne Uroda 
Cc: MSPGCC list 
Subject: Re: [Mspgcc-users] Whole program optimization / Link time optimization

I've never tested mspgcc for any whole-program optimizations.  A common and 
supported way to reduce space by eliminating unused material is 
-ffunction-sections -fdata-sections during compilation and -Wl,-gc-sections 
during linking.

Peter




On Sun, Apr 21, 2013 at 8:13 PM, Wayne Uroda w.ur...@gmail.com wrote:

  Hi,

  Can anybody comment on LTO or WPO’s effect on optimizing for space  - I have 
run out of flash memory and would rather not refactor my code at the moment. I 
only need 10 more bytes or so, for today at least... Yes it’s not ideal, such 
is life.

  I am using mspgcc 20120406-p20120911 and when I pass `–flto` in both the 
compilation and link stages it compiles fine but the linker complains 
“unrecognized option '-plugin'”. I assume LTO isn’t supported at this time?

  So then I skipped intermediate .o files altogether and used the following 
command:
  msp430-gcc -mmcu=msp430f233 -Os -Wall -Werror -o Coyote.elf all c files

  I get the expected message that my code does not fit.

  Using –fwhole-program:
  msp430-gcc -mmcu=msp430f233 -Os -Wall -Werror -fwhole-program -o Coyote.elf 
all c files

  I get the following output:
  C:\Users\WAYNEU~1\AppData\Local\Temp\cclYmoCC.o: In function `main':
  main.c:(.init9+0x2): undefined reference to `systemDisableInterrupts'
  main.c:(.init9+0x6): undefined reference to `PlatformInit'
  main.c:(.init9+0xc): undefined reference to `systemEnableCrystalClock'
  main.c:(.init9+0x2a): undefined reference to `delay'
  main.c:(.init9+0x44): undefined reference to `delay'
  main.c:(.init9+0x5e): undefined reference to `delay'
  main.c:(.init9+0x78): undefined reference to `delay'
  main.c:(.init9+0x80): undefined reference to `delay'
  C:\Users\WAYNEU~1\AppData\Local\Temp\cclYmoCC.o:main.c:(.init9+0xa4): more 
undefined references to `delay' follow
  C:\Users\WAYNEU~1\AppData\Local\Temp\cclYmoCC.o: In function `main':
  main.c:(.init9+0xf8): undefined reference to `batteryGetStateOfCharge'
  main.c:(.init9+0x104): undefined reference to `chargeIsPresent'
  main.c:(.init9+0x118): undefined reference to `delay'
  main.c:(.init9+0x134): undefined reference to `delay'
  main.c:(.init9+0x138): undefined reference to `infomemValidate'
  main.c:(.init9+0x13c): undefined reference to `logicMainLoop'
  collect2: ld returned 1 exit status


  I then created two files, test1.c and test2.c

  test1.c:
  ---
  void test2(void);

  void test1(void)
  {
  test2();
  }

  int main()
  {
  test2();
  return 0;
  }

  ---

  test2.c:
  ---
  void test1(void);

  void test2(void)
  {
  test1();
  }

  ---

  Compiling them:
  msp430-gcc -mmcu=msp430f233 -Os -Wall -Werror -fwhole-program -o test.elf 
test1.c test2.c

  C:\Users\WAYNEU~1\AppData\Local\Temp\ccs3TYlw.o: In function `main':
  test1.c:(.init9+0x2): undefined reference to `test2'
  collect2: ld returned 1 exit status

  Have I done something wrong?

  In the meantime, I will refactor. I don’t even expect WPO/LTO to give me much 
of a space saving anyway.

  - Wayne

  --
  Precog is a next-generation analytics platform capable of advanced
  analytics on semi-structured data. The platform includes APIs for building
  apps and a phenomenal toolset for data science. Developers can use
  our toolset for easy data analysis  visualization. Get a free account!
  http://www2.precog.com/precogplatform/slashdotnewsletter
  ___
  Mspgcc-users mailing list
  Mspgcc-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Invalid Use of Void Expression

[Wayne Uroda]

LPM4 is a standalone macro which enters LPM4:

#define LPM4  _BIS_SR(LPM4_bits) /* Enter Low Power Mode 4 */

- Wayne

On Tue, Mar 19, 2013 at 8:44 PM, Dean Chester dean.g.ches...@gmail.com wrote:
 Hi,

 When I compile my source code I get the following error:

 main.c: In function ‘main’:
 main.c:113:3: error: invalid use of void expression

 The line of code that it is referring to is:

 __bis_SR_register(LPM4);

 This is defined in the header file in the compiler yet I can't work out why
 I am getting a compiler error.

 TIA,

 Dean

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_mar
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] Interrupt Syntax

[Wayne Uroda]

Hi,

I just want to double check, is the interrupt syntax described here:

http://mspgcc.sourceforge.net/manual/x918.html

still modern and current? I know many parts of MSPGCC have changed, and 
I may be getting confused with IAR or code composer because somewhere I 
recall the ISR syntax changed from one version to another.

Thanks,

- Wayne



--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Interrupt Syntax

[Wayne Uroda]

Thanks, so, is this syntax still current? I.e. hasn't been superseded?

On 19/03/2013 11:05 PM, Peter Bigot wrote:

That page suggests including signal.h and using the interrupt macro.

On Tue, Mar 19, 2013 at 7:56 AM, Wayne Uroda w.ur...@gmail.com 
mailto:w.ur...@gmail.com wrote:


Hi,

I just want to double check, is the interrupt syntax described here:

http://mspgcc.sourceforge.net/manual/x918.html

still modern and current? I know many parts of MSPGCC have
changed, and
I may be getting confused with IAR or code composer because
somewhere I
recall the ISR syntax changed from one version to another.

Thanks,

- Wayne




--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
mailto:Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users




--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Linker error

[Wayne Uroda]

This might be off base, but I've had similar issues when there was a space in 
my path to mspgcc in the newer versions.

- Wayne

On 16/03/2013, at 5:53, garyr ga...@fidalgo.net wrote:

 I've been using the mspgcc toolchain I downloaded in 2006. I'm now trying to 
 switch to the latest version, 4.6.3. I can compile but make returns an error:
 
 msp430-gcc -mmcu=msp430f1132 -o usb.elf main.o ../auart/auartc.o
 ../auart/auart.o ../uart/delay.o ../uart/dco.o ../utils/b2d.o
 ../utils/bin2hexS.o
 c:/program
 files/mspgcc_4.6/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld.exe:
 cannot open linker script file memory.x: No such file or directory
 collect2: ld returned 1 exit status
 mingw32-make: *** [usb.elf] Error 1
 
 It appears that I'm missing a file for the linker but I don't know what that 
 might be. The relevant (I think) portion of my makefile is:
 
 CPU  = msp430f1132
 CFLAGS   = -mmcu=${CPU} -Wall -O2 -g
 ASFLAGS  = -mmcu=${CPU} -x assembler-with-cpp -D_GNU_ASSEMBLER_ -c
 CC   = msp430-gcc
 AS   = msp430-gcc
 
 ${NAME}.elf: ${OBJECTS}
   ${CC} -mmcu=${CPU} -o $@ ${OBJECTS}
 
 Any suggestions?
 
 
 
 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_mar
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] port1.out.pin1 nomenclature

[Wayne Uroda]

I am not a compiler expert, but I have been writing embedded software for 8 
years now - most of that has been using the msp430 and all of that on mspgcc.

I certainly understand all the arguments being put forth, but I have to say 
that of the many problems I have encountered over the years, I have not 
encountered strange or unexpected behavior resulting from use of bitfields for 
gpio. Nor have I seen anybody access a special function register (such as 
TACTL) using bitfields - I don't see why you would want to either.

I am not saying I know what is best for anyone, but if using bitfields for 
gpios can make the code more readable and/or more maintainable then I say that 
is a very important factor.

That said, as the products I have worked on have spanned over many different 
generations and configurations, I find that inline functions can be a better 
way of providing control for single pins - inline functions such as 
platformSetLEDRed(...) can contain whatever flavor of code (= or bitfield) and 
can also be changed later to invert the input value, should the circuitry 
attached to the red led change in the future (driving an nfet and then a pfet 
for example).

I am also a firm believer that an embedded engineer should think of their c 
toolchain as a kind of super-assembler and should inspect the final linked file 
listing whenever changing things which may affect your code generation, such as 
CPU variant or even the version of mspgcc.

The difference between

Port =! Bit;
 and
Pin = 0;

Is large from a readability POV, but they do generate the same code (assigning 
arbitrary values to a single bit should always be done with caution unless you 
know what to expect).

The argument is similar to that of using macros or not, some may argue they are 
very powerful, some may argue they are very dangerous, but ultimately if the 
code works properly, is readable, maintainable and ships on time then everybody 
wins.

- Wayne



On 24/07/2012, at 6:24 AM, Peter Bigot big...@acm.org wrote:

 On Mon, Jul 23, 2012 at 2:49 PM, Paul Voith p...@voithconsulting.com wrote:
 Peter,
 
 I agree that bitfields are a pain. The standards guarantee almost nothing
 regarding their internal implementation and so there is really no obvious
 reason to implement what amounts to a hack using them.
 
 While use of the a |= b may generate a single instruction IF b is a
 constant, it is not guaranteed and in cases where b is an arbitrary
 expression typically does not. The left side value is read; the expression
 on the right calculated, the already read left side expression is OR'd in
 and the the result written. Entering the expression for the right side into
 a variable prior to ORing is likely to be removed by the compiler
 optimization so nothing to rely on.
 
 Yes.  I'm confused because, as you note in the previous paragraph,
 there's nothing guaranteed about the behavior of bitfields either.  So
 I'm not seeing what's changed here.  As I explain below, I see no
 evidence mspgcc ever did anything special here.
 
 Presently I notice that the 4.6.3 version of the compiler I am using accepts
 bitfield definitions without generating an error. For bitfields defined on a
 char or unsigned char base type it appears that bits so defined are packed
 into a 16 bit short word. This is a change from early versions but appears
 to have occurred well before 2008. This breaks the earlier include files
 which used to define these as bit fields within an unsigned char object. So
 legacy code compiles without error but generates an unexpected result. So
 even if TI provided such files the present bitfield implementation could not
 use them.
 
 I believe there are situations where you'd need to add the attribute
 packed to the structure declaration.  packed is a standard gcc
 attribute and is documented in the gcc manual.  In other situations
 that would not be necessary.
 
 Since the C/C++ standards (and most HLLs) generally presume that memory does
 not change value by itself and that reading from a memory location has no
 consequence, I/O register access is problematic. The volatile modifier
 allows handling of the first case of course by demanding that every explicit
 reference to an identifier in an expression forces an actual read of the
 associated memory location. [Aside: I wondered if it is allowed to read such
 a location MORE times than explicitly referenced?].
 
 With volatile?  No, it's not allowed.
 
 Rather than trying to hack up the compiler it is probably best to just
 generate an inline assembly instruction sequence which performs the needed
 functionality.
 
 I use msp430-gcc a lot in my work. I have actually been using an extremely
 old version of the compiler and discovered the change when I recompiled code
 (without error) which simply didn't work as before.
 
 Can you provide a concrete example?
 
 I can say that I
 consider this ability to fiddle bits without semaphore protection of every
 register a huge 

Re: [Mspgcc-users] port1.out.pin1 nomenclature

[Wayne Uroda]

Hi Paul,

Even though the official line is don't use iostructures, I am still
a big fan of this method.
I have attached the header file I wrote for use with some 2 family parts.
You should find it easy to adapt to 1 family or 5 family parts, also
you should double check that everything is in the correct place for
your chip (i.e. this comes with no guarantees, YMMV, etc).

- Wayne

#ifndef IOSTRUCTURES_H_
#define IOSTRUCTURES_H_

typedef union
{
volatile unsigned char _byte;
volatile struct
{
UInt8_bit0:1,
_bit1:1,
_bit2:1,
_bit3:1,
_bit4:1,
_bit5:1,
_bit6:1,
_bit7:1;
} _bits;
} __attribute__ ((packed)) bitfield8;

#define pin0_bits._bit0
#define pin1_bits._bit1
#define pin2_bits._bit2
#define pin3_bits._bit3
#define pin4_bits._bit4
#define pin5_bits._bit5
#define pin6_bits._bit6
#define pin7_bits._bit7

struct gpioPort1
{
bitfield8in;// addr 0x20
bitfield8out;// 0x21
bitfield8dir;// 0x22
bitfield8ifg;// 0x23
bitfield8ies;// 0x24
bitfield8ie;// 0x25
bitfield8sel; // 0x26
bitfield8ren; //0x27
UInt8pad0[25];
bitfield8sel2; //0x41
} __attribute__((__packed__));

struct gpioPort2
{
bitfield8in;// addr 0x28
bitfield8out;// 0x29
bitfield8dir;// 0x2A
bitfield8ifg;// 0x2B
bitfield8ies;// 0x2C
bitfield8ie;// 0x2D
bitfield8sel; // 0x2E
bitfield8ren; //0x2F
UInt8pad0[18];
bitfield8sel2; //0x42
} __attribute__((__packed__));

struct gpioPort3
{
bitfield8ren; // addr 0x10
UInt8pad0[7];
bitfield8in;//0x18
bitfield8out;// 0x19
bitfield8dir;// 0x1A
bitfield8sel; // 0x1B
UInt8pad1[39];
bitfield8sel2; //0x43
} __attribute__((__packed__));

struct gpioPort4
{
UInt8 pad0[1];// addr 0x10
bitfield8ren; //0x11
UInt8pad1[10];
bitfield8in;//0x1C
bitfield8out;// 0x1D
bitfield8dir;// 0x1E
bitfield8sel; // 0x1F
UInt8 pad2[36];
bitfield8sel2; //0x44
} __attribute__((__packed__));

struct gpioPort5
{
bitfield8ren; // addr 0x12
UInt8pad0[29];
bitfield8in;//0x30
bitfield8out;// 0x31
bitfield8dir;// 0x32
bitfield8sel; // 0x33
UInt8 pad1[17];
bitfield8sel2; //0x45
} __attribute__((__packed__));

struct gpioPort6
{
UInt8 pad0[1];// addr 0x12
bitfield8ren; //0x13
UInt8 pad1[32];
bitfield8in;//0x34
bitfield8out;// 0x35
bitfield8dir;// 0x36
bitfield8sel; // 0x37
UInt8 pad2[14];
bitfield8sel2; //0x46
} __attribute__((__packed__));

extern volatile struct gpioPort1 port1 asm(0x0020);
extern volatile struct gpioPort2 port2 asm(0x0028);
extern volatile struct gpioPort3 port3 asm(0x0010);
extern volatile struct gpioPort4 port4 asm(0x0010);
extern volatile struct gpioPort5 port5 asm(0x0012);
extern volatile struct gpioPort6 port6 asm(0x0012);


#endif /*IOSTRUCTURES_H_*/

On Mon, Jul 16, 2012 at 4:28 PM, Paul Voith p...@voithconsulting.com wrote:
 Hi all,

 I am trying to port code from an earlier release of msp430-gcc and
 having trouble.

 Specifically now that io.h is depreciated I don't know the expected
 mechanism to support the port1.out.pin0 nomenclature for referencing
 bit I/O.

 In the past there was an installation kit for the tool chain on windows.
 I see now that there is a built zip file for windows (Thanks Matthias!).
 Any info available on how to install this? Perhaps just unzip into a
 searchable directory is all?

 The have referred to the manual but it seems out of date for these aspects.

 Thanks
 -- Paul

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Slow execution with MSPDebug, using tilib driver (msp430.dll v3)

[Wayne Uroda]

Hi Rosty,

I am using MSP430F233. The read address is usually around E000 to E060 in the 
small test program I was running.

The issue isn't with slow memory reads - the issue is with slow execution after 
a call to MSP430_Run(RUN_TO_BREAKPOINT, 0); which follows a memory read using 
MSP430_Memory(...);

For example, when starting GDB, GDB will halt the target, read the target 
registers, then will read the word at the address of the program counter.
This read will be accomplished with MSP430_Memory(., READ); (using MSPDebug 
with the tilib driver).

Next in GDB if you enter the continue command, MSPDebug will call 
MSP430_Run(RUN_TO_BREAKPOINT, 0);
The target will free-run, however the execution speed is 10-12 times slower 
than normal (running from DCO, I didn't test running from a crystal - I am not 
sure if DCO is just running slow or if it is being stopped periodically, I 
didn't check).

I have confirmed that if the call to MSP430_Memory(., READ); is suppressed 
the target executes at the expected speed.
I don't recall exactly but I think the slow speed persists until the target is 
reset.

The problem can be easily seen with the latest GIT version of MSPDebug and 
msp430-gdb when used with the tilib driver and v3.2.3.15 of MSP430.dll.

Thanks for looking into it.

- Wayne

-Original Message-
From: Stolyar, Rostyslav [mailto:r-stol...@ti.com] 
Sent: Monday, 30 April 2012 5:18 PM
To: Wayne Uroda; Daniel Beer; Wayne Uroda
Cc: mspgcc-users@lists.sourceforge.net
Subject: RE: [Mspgcc-users] Slow execution with MSPDebug, using tilib driver 
(msp430.dll v3)

Hi Wayne,

Thank you for your investigations. We'll check if there is a speed difference 
of the MSP430_Memory(., READ) execution in the DLL v3.2.1.9 vs. v3.2.3.15.

Could you please tell me what the MSP430 device you have used? And memory range 
you have read out?

I'll come back in few days.

Regards,
Rosty



Texas Instruments Deutschland GmbH, Haggertystr. 1, D-85356 Freising. 
Amtsgericht M?nchen HRB 40960. Gesch?ftsf?hrer: Dr. Wolfram Tietscher. 
Vorsitzender des Aufsichtsrates: Edgar Frank

-Original Message-
From: Wayne Uroda [mailto:wayne.ur...@grabba.com]
Sent: Monday, April 30, 2012 1:52 AM
To: Daniel Beer; Wayne Uroda
Cc: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Slow execution with MSPDebug, using tilib driver 
(msp430.dll v3)

Hi,

I have updated to the latest GIT version of MSPDebug - it doesn't make any 
difference to the slow execution problem.

I have downgraded the MSP430.dll (and hil) to version 3.2.1.9 and the problem 
disappears, so by my reckoning the problem is definitely with v3.2.3.15 of 
MSP430.dll. (I have also replicated this on two machines and performed several 
firmware upgrades on the FET to confirm).

I hope this information is useful to somebody else when they are tearing their 
hair out in confusion.

- Wayne


-Original Message-
From: Daniel Beer [mailto:dlb...@gmail.com]
Sent: Monday, 30 April 2012 7:14 AM
To: Wayne Uroda
Cc: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Slow execution with MSPDebug, using tilib driver 
(msp430.dll v3)

At Sun, 29 Apr 2012 23:52:37 +1000, Wayne Uroda wrote:
 I have been doing a bit of work on MSPDebug over the weekend trying to
 figure out a few issues I've been having. The one problem I can't solve
 is when using msp430-gdb and mspdebug, the code executes about ten times
 slower than it should (when using the new tilib driver which makes use
 of TI's new MSP430.dll v3).

 During my testing I have determined that following a call to
 MSP430_Memory(., READ); the execution speed will be slow. The first
 thing GDB does when connecting to the target is read the memory at the
 PC, which means it will always run slow after that. MSPDebug will run
 slow after the first run, ctrl+c combination, as it will read and
 disassemble the current function when you press ctrl+c.

 I am on windows 7 32bit using version 3.2.3.15 of msp430.dll (from
 msp430.dll_developer_package_rev_3.02.003.015.zip).

 I was wondering if anybody had run into similar issues? I will try
 duplicating the issue on my work PC tomorrow before I start making noise
 in the E2E forums.

Hi Wayne,

I've just fixed the bug you found with breakpoint handling. It might
be worth retesting with the latest git version, because this may be
related.

I would try reflashing your firmware before retesting. It looks like
gdb may have fallen back on its own software breakpoint implementation
due to the bug introduced by the latest breakpoint handling changes.

Cheers,
Daniel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263

[Mspgcc-users] Slow execution with MSPDebug, using tilib driver (msp430.dll v3)

[Wayne Uroda]

Hi,

I have been doing a bit of work on MSPDebug over the weekend trying to 
figure out a few issues I've been having. The one problem I can't solve 
is when using msp430-gdb and mspdebug, the code executes about ten times 
slower than it should (when using the new tilib driver which makes use 
of TI's new MSP430.dll v3).

During my testing I have determined that following a call to 
MSP430_Memory(., READ); the execution speed will be slow. The first 
thing GDB does when connecting to the target is read the memory at the 
PC, which means it will always run slow after that. MSPDebug will run 
slow after the first run, ctrl+c combination, as it will read and 
disassemble the current function when you press ctrl+c.

I am on windows 7 32bit using version 3.2.3.15 of msp430.dll (from 
msp430.dll_developer_package_rev_3.02.003.015.zip).

I was wondering if anybody had run into similar issues? I will try 
duplicating the issue on my work PC tomorrow before I start making noise 
in the E2E forums.

Thanks,

- Wayne

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Slow execution with MSPDebug, using tilib driver (msp430.dll v3)

[Wayne Uroda]

Hi,

I have updated to the latest GIT version of MSPDebug - it doesn't make any 
difference to the slow execution problem.

I have downgraded the MSP430.dll (and hil) to version 3.2.1.9 and the problem 
disappears, so by my reckoning the problem is definitely with v3.2.3.15 of 
MSP430.dll. (I have also replicated this on two machines and performed several 
firmware upgrades on the FET to confirm).

I hope this information is useful to somebody else when they are tearing their 
hair out in confusion.

- Wayne


-Original Message-
From: Daniel Beer [mailto:dlb...@gmail.com] 
Sent: Monday, 30 April 2012 7:14 AM
To: Wayne Uroda
Cc: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Slow execution with MSPDebug, using tilib driver 
(msp430.dll v3)

At Sun, 29 Apr 2012 23:52:37 +1000, Wayne Uroda wrote:
 I have been doing a bit of work on MSPDebug over the weekend trying to 
 figure out a few issues I've been having. The one problem I can't solve 
 is when using msp430-gdb and mspdebug, the code executes about ten times 
 slower than it should (when using the new tilib driver which makes use 
 of TI's new MSP430.dll v3).
 
 During my testing I have determined that following a call to 
 MSP430_Memory(., READ); the execution speed will be slow. The first 
 thing GDB does when connecting to the target is read the memory at the 
 PC, which means it will always run slow after that. MSPDebug will run 
 slow after the first run, ctrl+c combination, as it will read and 
 disassemble the current function when you press ctrl+c.
 
 I am on windows 7 32bit using version 3.2.3.15 of msp430.dll (from 
 msp430.dll_developer_package_rev_3.02.003.015.zip).
 
 I was wondering if anybody had run into similar issues? I will try 
 duplicating the issue on my work PC tomorrow before I start making noise 
 in the E2E forums.

Hi Wayne,

I've just fixed the bug you found with breakpoint handling. It might
be worth retesting with the latest git version, because this may be
related.

I would try reflashing your firmware before retesting. It looks like
gdb may have fallen back on its own software breakpoint implementation
due to the bug introduced by the latest breakpoint handling changes.

Cheers,
Daniel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Draft 20-Bit Design/Interface Specification available for review

[Wayne Uroda]

Hi Peter,

This is amazing work. I am very excited for 20bit support in mspgcc.

After reading the document I want to ask what may be an extremely out-there 
question:

I gather that most people who require far code support should use the compiler 
options -mc20 and -msr20. I am not sure how wasteful the __sr20__ attribute on 
all functions will actually be, but it feels like a waste of RAM if say less 
than 5% of functions actually make use of 20bit registers (am I correct in 
saying, in general, only functions which perform pointer arithmetic on function 
pointers will generate 20bit register values? [ignoring far data pointers and 
explicit use of 20b integer types]).

Could it perhaps be more efficient (overall) for a function which makes use of 
20bit values in registers to save its own 20b registers before calling a 
function which could potentially overwrite them?

Eg.
uint16_t vals[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9,
0x8001, 0x8002, 0x8002, 0x8004, 0x8005,
0xf000 };
/* ... */
{
  uint20_t sv;
  sv = 0;
  for (i = 0; i  sizeof(vals)/sizeof(*vals); ++i) {
sv += vals[i];
// BEFORE CALLING PRINTF (OR ANY FUNCTION WHICH IS NOT KNOWN TO BE 
__sr20__) THE COMPILER/ASSEMBLER CAN LOCALLY SAVE ANY 20b REGISTERS HERE
printf(Add %04 PRIx16  produces %05 PRIx20 \n, vals[i], sv);
// ON RETURN FROM FUNCTION 20b REGISTERS ARE RESTORED
  }
}

I am not saying we should change the calling convention - all functions still 
save and restore 16b registers in their prologues and epilogues as required. I 
am just thinking that the compiler could automatically detect which registers 
are 20bit and need to be saved using pushx.a/pushm.a instructions and do the 
save/restore locally (before pushing and after popping any stack based function 
parameters). There is every chance that the registers themselves will not be 
modified, which means that the 4 bytes of storage are wasted for each register. 
If they *are* used by the called function (or one of its called functions) they 
will be saved twice (or more times), which uses slightly more storage than 
necessary. I wonder if overall this could be beneficial in a program where in 
the vast majority of the time 20bit registers are not used and thus the 
__sr20__ attribute on ALL functions could be wasteful. Also it means that an 
__sr20__ multilib would not be required.

Just an idea, I can only assume that this functionality would be possible to 
implement - whether it is a good idea or a bad idea I leave up to you.


- Wayne


-Original Message-
From: Peter Bigot [mailto:big...@acm.org] 
Sent: Friday, 27 April 2012 7:31 AM
To: GCC for MSP430 - http://mspgcc.sf.net
Subject: [Mspgcc-users] Draft 20-Bit Design/Interface Specification available 
for review

The first draft of the design specification for 20-bit support in
mspgcc has been added to the wiki at:

https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Design

Interested parties are invited to read the document on the wiki, and
comment on this mailing list.

The specification focuses on the atomic capabilities which combine to
form what's normally called a memory model.  They are highly
orthogonal, although some combinations are likely to result in
unexpected (i.e., buggy) behavior.

I specifically invite comment on exactly what memory models should be
supported by roll-up options that enable/disable the individual
features described on that page, and what compiler option will
identify them.  (It'd be something like -mmodel=large, but what
exactly should large mean?)  Preferably the naming and semantics of
these models should tie back to existing practice in other MSP430
toolchains or other GCC back-ends.

At this time, I believe what's described is technically possible, but
the management of the namespaces, correct specification of pointer
types based on code and options, and exactly how to get the linker to
assign data and function objects into the split address space are yet
to be implemented, and some showstopper issue might arise.  (As far as
I can tell nobody's ever made binutils support a split address space
before.  Getting 20-bit integers to work produced five bug reports
against upstream gcc so far, all of which have been fixed in mspgcc
with at least one already fixed upstream as well.)

Peter

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--

[Mspgcc-users] Stack push inside inline assembly

[Wayne Uroda]

Hi,

I feel quite foolish asking the following question... Please don't judge me too 
harshly...

In my MSPGCC based system I have got the following #defines which I use for 
critical (interrupts disabled) access around volatile memory which is modified 
by interrupt routines:

#define criticalStart() __asm__ __volatile__(push r2::); __asm__ 
__volatile__(dint::)
#define criticalEnd() __asm__ __volatile__(pop r2::)

Usually I use this code to write to a counter which is decremented by my timer 
ISR, eg

void setTimeout(UInt16 timeout)
{
// Other work before setting the volatile, ISR driven value
criticalStart();
busyTimeout = timeout;
criticalEnd();
}

Today I am using Code composer for a new project and I tried a similar trick. 
After several hours of debugging, it turns out that my little push r2 trick 
causes code composer to access local variables incorrectly, since these are 
accessed relative to the stack pointer.

For example, the following code does not function correctly because the 
localTimer variable is not written correctly (the memory access is one word 
off owing to the extra stack push).

while(true)
{
UInt32 localTimer;
criticalStart();
localTimer = globalTimer;
criticalEnd();
if (localTimer == 0)
{
break;
}
}


My question is, does GCC analyse the inline assembly code and notice that I 
have altered the stack, or have I just been *extremely* lucky for many years? 
Certainly code composer does not see that I have modified the stack.

I am going to change my critical macros like so (this is how I am now doing 
critical access in code composer, which, unless I am missing something, has no 
builtin way to do critical functions):

#define criticalStart() { UInt16 __oldInterruptStatus__ = READ_SR(); __asm__ 
__volatile__(dint::)
#define criticalEnd() WRITE_SR(__oldInterruptStatus__); }

Any major issues with doing this? Should I instead wrap all reads and writes to 
volatile memory/variables with critical functions? I usually only wrap one line 
of code with the critical macros.

Also if anybody knows code composer v3.1 and knows a better way, please let me 
know.
Thanks,


-  Wayne
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Stack push inside inline assembly

[Wayne Uroda]

Thanks everyone for the very interesting discussion, as always.

I will reform my ways and do something sensible like

void myFunction(void)
{
// non-atomic work here

{
UInt16 interruptState = startCriticalSection();
// critical/atomic statements here
endCriticalSection(interruptState);
}
}

I will also make use of intrinsics where I can and I will avoid using inline 
assembly in the future.

Thanks for the thorough schooling ;)

- Wayne

-Original Message-
From: William Chops Westfield [mailto:wes...@mac.com] 
Sent: Wednesday, 18 April 2012 8:48 AM
To: GCC for MSP430 - http://mspgcc.sf.net
Subject: Re: [Mspgcc-users] Stack push inside inline assembly


On Apr 17, 2012, at 3:02 AM, David Brown wrote:

 You've just been lucky.

In particular, gcc is pretty aggressive about optimizing away stack frames when 
it can (putting local variables in registers, rather than explicitly on the 
stack.)  (I *think* this is NOT target specific...)

BillW


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] iostructures

[Wayne Uroda]

I notice that iostructures.h hasn't been a part of the MSPGCC project for a 
while now...

I am wondering if there is a reason for this? I always found these structures 
were a very convenient way to access individual pins, and I can't recall ever 
suffering any strange problems from using the structures to read or write the 
in,out,dir,sel,ies,ie and ifg bits.

If there is a compelling technical reason to not access pins through structures 
such as these, does anybody have suggestions as to how they do it, and why?

Thanks

-  Wayne
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] mspdebug / FET v2 / 5528

[Wayne Uroda]

Hi Matthias,

I had a similar problem with an MSP430F5437 part (it failed C_IDENT3). Using 
the latest version of mspdebug and the new MSP430.dll v3 driver and firmware 
has fixed the problem.

I hope it also works for you.

 - Wayne

-Original Message-
From: Matthias Ringwald [mailto:matth...@ringwald.ch] 
Sent: Tuesday, 17 January 2012 8:18 AM
To: Daniel Beer
Cc: GCC for MSP430 - http://mspgcc.sf.net
Subject: [Mspgcc-users] mspdebug / FET v2 / 5528

Hi Daniel

I'm trying to flash an MSP430F5528 using the FET430-UIF and get this error:

$ mspdebug-uif 
MSPDebug version 0.18 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2011 Daniel Beer dlb...@gmail.com
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Trying to open UIF on /dev/tty.FET430UIFfd130...
Initializing FET...
FET protocol version is 20407001
Configured for JTAG (2)
Set Vcc: 3000 mV
Device ID: 0x5528
Device: MSP430F5528
Code memory starts at 0x4400
Number of breakpoints: 8
uif: read error: Operation timed out
fet: warning: message C_IDENT3 failed
uif: read error: Operation timed out
fet: message C_IDENT2 failed
fet: identify failed
Trying again...
Initializing FET...
FET protocol version is 20407001
Configured for JTAG (2)
Sending reset...
Set Vcc: 3000 mV
Device ID: 0x5528
Device: MSP430F5528
Code memory starts at 0x4400
Number of breakpoints: 8
uif: read error: Operation timed out
fet: warning: message C_IDENT3 failed
uif: read error: Operation timed out
fet: message C_IDENT2 failed
fet: identify failed

I can read/write this chip with the FET430Pro Lite using Windows (Parallels)


is there something I can  debug myself? would using v3 make any difference?

Best
 Matthias 

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] Static analysis stack tool

[Wayne Uroda]

Hello,

I am interested in starting an open source tool for msp430 development, 
specifically to perform static, whole elf analysis to investigate stack usage. 
Such a tool can identify maximum stack depth of each function and also find the 
maximum stack usage of an entire executable.

I have a tool which I wrote and use personally but it is limited and 
specifically coded for the custom link setup I use for my company's products, 
so I wish to start from scratch.

Before I begin I just wanted to check that I wasn't reinventing the wheel. How 
I have done it in the past was by parsing the output of the disassembler, 
building a graph of function calls and then analysing each function for 
instructions which modify the stack. Would I be better off trying to insert 
this functionality into the compiler/linker/disassembler itself? I have a 
feeling this would be a lot more complicated.

I plan on using C++. Any comments are welcome.

Thanks,
- Wayne Uroda

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Static analysis stack tool

[Wayne Uroda]

Hi Peter,

Regarding your first comment, are you saying that while I can put a definite 
lower bound on stack usage (stack uses at least X bytes), I cannot put a 
definite upper bound on stack use (stack never uses more than Y bytes)?

I agree that in a completely general case it is impossible to put a ceiling on 
stack size. In my last tool I made the following assumptions:

1. No recursion or cycles in the call graph
2. No nested interrupts
3. The program uses a simple foreground-background model and does not do any 
context switching, nor does it deliberately tamper with the stack during run 
time (i.e. the stack pointer is only modified by adding or subtracting fixed 
values).

I think the first assumption is fine as I am yet to meet anybody who thinks 
recursion in an embedded environment is good practice.

Assumption 2 is definitely a show stopper for some people. I have never used 
nested interrupts myself so I have some gaps in my understanding of how they 
work in practice and will have to do some research here to see what can be 
done. Still the tool should be able to compute stack usage of the background 
code just fine.

As for assumption 3, I believe if the user is writing a program with multiple 
threads perhaps they can invoke this tool several times, each time passing in 
the entry point to a particular thread, and thereby compute the stack usage of 
each thread (the tool also may be tailored to support one or more RTOS).

I am sure I am being too naive about it but for my own work I found even basic 
stack analysis to be quite helpful.
I am happy for you to point out anything obvious or not-so-obvious that I am 
overlooking :)

- Wayne

-Original Message-
From: pabi...@gmail.com [mailto:pabi...@gmail.com] On Behalf Of Peter Bigot
Sent: Thursday, 12 January 2012 11:19 PM
To: Wayne Uroda
Cc: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Static analysis stack tool

On Thu, Jan 12, 2012 at 6:49 AM, Wayne Uroda wayne.ur...@grabba.com wrote:
 Hello,

 I am interested in starting an open source tool for msp430 development, 
 specifically to perform static, whole elf analysis to investigate stack 
 usage. Such a tool can identify maximum stack depth of each function and also 
 find the maximum stack usage of an entire executable.

 I have a tool which I wrote and use personally but it is limited and 
 specifically coded for the custom link setup I use for my company's products, 
 so I wish to start from scratch.

 Before I begin I just wanted to check that I wasn't reinventing the wheel. 
 How I have done it in the past was by parsing the output of the disassembler, 
 building a graph of function calls and then analysing each function for 
 instructions which modify the stack. Would I be better off trying to insert 
 this functionality into the compiler/linker/disassembler itself? I have a 
 feeling this would be a lot more complicated.

 I plan on using C++. Any comments are welcome.

Three comments:

1) (you probably know this, but just in case somebody doesn't...)  Go
in recognizing that the halting problem reduces to this: at best
you'll be able to find situations where the stack exceeds a specific
size, but will not be able to prove it doesn't do so.

2) For analysis of stack space consumed by a function I would look at
http://gcc-melt.org/.  There may already be a solution; if not, it
would still provide a more effective analysis environment than
reconstructing control-flow graphs from assembly.

3) For call graph in linked programs, look into using libbfd from
binutils to extract data from elf files directly rather than
processing disassembly output.

Good luck, and if you need support for something in the compiler or
binutils (other than how about a stack space analyzer) let me know.

Peter

 Thanks,
 - Wayne Uroda

 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] register save on thread switch (was: Enter LPM4 without missing the wakeup interrupt)

[Wayne Uroda]

Hi Sergio,

For my work many years back I ran into the problem where my stack was 
overflowing (too much code in too little ram unfortunately) - I wrote a static 
analyser which took the ASM file listing of my entire project, built a big 
directed graph from all the functions and then analysed each function to 
discover how much stack it used (including the 2 bytes used for a call 
instruction) and then finally traversed the graph to discover the maximum stack 
depth seen by that function - in this way I can get an approximate upper bound 
of how big my stack will grow at run time (it isn't exact as it doesn't trace 
loops or conditionals so it might overestimate usage a little bit).

Unfortunately I wrote this tool on company time and thus I can't share or open 
source it. I am not sure if there are any free/open source static analysis 
tools for mspgcc. Mine isn't all that sophisticated - the code just parses the 
ASM listing (generated using mspgcc-objdump), parses out the functions, then 
inside each function it looks for instructions which modify the stack pointer. 
I made a lot of assumptions like no recursion, no stack pointer modification 
inside loops etc. but it does give a fairly good idea of stack usage, and was a 
fun exercise in graph algorithms too. 

Other than that approach, you could fill your stack with a repeating pattern at 
startup and then run your thread for a while, and then afterwards you can check 
to see how large the stack grew. Downside to this is that unless you get 100% 
code coverage while you are doing this test you can't be sure how large the 
stack will grow. You will have to do this test once for each thread so you 
can discover how large their stacks should be. Perhaps as part of your OS you 
should bake in this kind of stack watermarking and then you can collect real 
world statistics. Until you know exactly how big your stacks need to be, the 
rule is probably the bigger the better! Stack overflows usually corrupt your 
global variables and so your code will probably keep running although the data 
might be corrupt, so sometimes it is difficult to even tell for sure if you 
have had stack overflow (unless you have a known value in ram at the top of 
your globals etc which you can easily see has been incorrectly modified).

- Wayne

-Original Message-
From: Sergio Campamá [mailto:scamp...@ing.puc.cl] 
Sent: Friday, 9 December 2011 12:29 AM
To: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] register save on thread switch (was: Enter LPM4 
without missing the wakeup interrupt)

Wow JM, thanks a lot!

I'll try fidgeting with these concepts when I have the chance. My main worry 
about having multiple stacks is detecting if I have enough memory to allocate 
a new stack, and overflow/underflow problems. I tried to solve this by having a 
defined number of available threads, and allocate space for them on RAM 
statically in C structs. How can I dimension the required stack size for the 
thread? Just trial and error?

Best of luck...
---
Sergio Campamá
sergiocamp...@gmail.com




On Dec 8, 2011, at 10:19 AM, JMGross wrote:

 - Ursprüngliche Nachricht -
 Von: Sergio Campamá
 Gesendet am: 07 Dez 2011 03:33:31
 
 Hey, maybe I'm straying a bit from the conversation, but 
 
 Yes. A little bit. :)
 So I took the freedom to change the topic a little bit too :)
 
 1. Is there a way to obtain (and set) the registers? I want to try a feature 
 where I create preemptive threads, in which after 
 certain interrupts, I will save the current context (registers) and the 
 instruction line I was executing (which is already in the 
 registers, the PC), and start executing from another address.. And when I'm 
 done with that, reload the PC and all the other 
 registers and resume working on that thread. I'm guessing that  8 * 16 = 
 128 bytes would be the least memory I would need 
 for each context save. Is it not?
 
 You can use inline assembly to do so. The GCC inline assembler
 is very powerful and allows a tight integration of assembly code into C code.
 It isn't that easy to learn, as this C/ASM connection requires to learn about
 how to tell the compiler about used/altered/clobbered variables and registers.
 But without this, you'll run into problems about the current register states
 (used for temporary values, register variables, whatever)
 
 I wrote a multitasker myself some time ago (based on the RTC timer of the 
 MSP430F5438)
 I use a separate stack for each thread, because this is the only way to allow
 real task switching, sleeping tasks etc.
 Remember, the threads will have more than just the pushed register on its 
 stack when
 you switch. If you re-use the same stack, then when you swith from thread 2 
 to 1,
 thread 1 will have return addresses or local variables of thread 2 on top of 
 the stack,
 which surely isn't what anyone would expect or could handle.
 And saving the complete stack history onf one 

Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt

[Wayne Uroda]

As far as I know, you can't really play with the registers in C like that. Of 
course you could write asm functions to get and set the registers (or C 
functions with inline assembly) but I suspect the compiler would undo all your 
magic register work when you left the interrupt/function. I would really 
STRONGLY recommend against trying to modify registers like that from C code, as 
the C compiler is built around the assumption that it is in control of the 
registers - I feel like trying to work against the compiler would be a bad idea.

I don't really see much value to storing the registers to a struct/array rather 
than a stack, but you could do it. What you REALLY shouldn't do however is 
return to a new function/context using an old function/context's stack. The 
stack is used for local storage and as such may be arbitrarily modified during 
a function as the C compiler sees fit (to backup clobbered registers, for local 
functions, parameter passing etc). Returning into a new function/context with 
an old stack will give you strange behaviour at best, most likely will result 
in corrupted data and crash as soon as that function returns and the PC is set 
to a random value found on the stack.

So like I said, if you want to do context switching you will need one stack for 
each context. There is really no way around that. You should treat each context 
as a completely separate C program, and be very aware of strangeness like 
trying to share volatile global structures between the two contexts (make sure 
to write/read multiword types/structs from critical sections to avoid data 
corruption).

- Wayne


- Original Message -
From: Sergio Campamá [mailto:scamp...@ing.puc.cl]
Sent: Wednesday, December 07, 2011 08:56 PM
To: Wayne Uroda
Cc: Peter Bigot big...@acm.org; mspgcc-users@lists.sourceforge.net 
mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt

Thanks for the tips Wayne!

Talking about the context switch problem, could I obtain the registers in C 
code? What I was thinking was not doing the context save into other stacks, but 
into C structs, preallocated on compile time (this would limit the amount of 
simultaneous context switching). And use the same stack pointer for the new 
tasks…

Best regards,
---
Sergio Campamá
sergiocamp...@gmail.com




On Dec 7, 2011, at 12:13 AM, Wayne Uroda wrote:

 When an interrupt is generated, the hardware pushes the PC and then the SR 
 onto the stack. The hardware then clears the SR and loads PC with the 
 appropriate interrupt address.

 In MSPGCC, the first thing the compiler does on entry to an interrupt routine 
 is push any registers clobbered during the interrupt routine to the stack. 
 Then the interrupt work is done, then the registers are popped in the reverse 
 order, then the RETI instruction causes the machine to pop back the SR and 
 then the original PC is popped.

 So if you want to do a context switch in your interrupt routine, you should 
 push ALL the registers to the stack as you have indicated. You will have to 
 break out some assembly code to do this. You will also (I'm guessing) need to 
 stop GCC from generating the interrupt related pushes and pops. Probably best 
 to write this whole interrupt handler in assembly so you can be sure what is 
 going on.

 So, you will need to do the following (Note that R0 to R3 are PC, SP, SR, and 
 CG respectively) (this code surely doesn't work verbatim, it is just an 
 example)

 /* start of ISR */
 /* first save all the general purpose registers to the stack */
 push r15
 push r14
 ... repeat
 push r5
 push r4

 /* now we can do a context switch by swapping the SP with another VALID 
 context */
 /* first back up the old SP to some address, then load in the new SP */
 /* choosing the new context can be simple or complex, this depends on the 
 type of scheduler you wish to use */
 mov r1, oldSP
 mov newSP, r1

 /* should clear whatever interrupt flag got us to this ISR in the first place 
 */
 TODO

 /* now we are operating in the new context, we should restore all registers 
 and return from the interrupt */
 pop r4
 pop r5
 ... repeat
 pop r14
 pop r15
 reti
 /* end of ISR */

 This means that your new context has its own stack, so make sure that each 
 context (stack) is big enough for all the functions that they need to execute 
 between task switching.
 Note where I say VALID context - this must be a stack which already has 
 registers r4 to r15 as well as the SR and PC to return to - otherwise you 
 will get stack underrun when you execute the 12 pops and then the machine 
 executes the 2 pops (SR and PC).

 The smallest possible size a context could be is then 14 words or 28 bytes, 
 but this doesn't leave any room for the stack to grow during your actual 
 function.

 If you want to perform only one function in this other context, maybe looking 
 into nested interrupts would be better

Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt

[Wayne Uroda]

Thanks for the discussion - I apologise for my code sample having flaws, it 
isn't production code just something I threw together to illustrate the point. 
In my case I am only interested in the level of the pin (sleep when it is low, 
awake when it is high) and so I am not concerned with missing edges other than 
the critical edge which brings me out of LPM4. I am aware that I still need to 
be careful of the order in which I enable the interrupt/clear the ifg and 
disable interrupts before finally checking the level of the pin and entering 
LPM4 if appropriate.
 
One thing that I have never done is use the on_exit macro - I use the wakeup 
keyword instead - I'm guessing there are potential problems with the wakeup 
keyword?

- Wayne

-Original Message-
From: JMGross [mailto:msp...@grossibaer.de] 
Sent: Wednesday, 7 December 2011 12:47 AM
To: MSPGCC mailing list,
Subject: Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt


Hello Wayne,

you correctly detected a possible problem in your code, which from my 
experience really is an exception. Most 'coders' don't 
care for realtime influences and then wonder why the code doesn't work (or use 
a watchdog do reset the CPU when the code
unexpectedly 'hangs'.

A generic solution to your problem has already beenb pinted out. Set LPM and 
GIE in the same instruction.
Both, the LPM bits as well as GIE are located in the status register, so it 
comes down to an atomic operation:
BIS #(LPM4|GIE), R2

In this case, if an interrupt happened before GIE is set and LMP is entered, 
the following will happen:
GIE/LPM is set.
LMP is exited, since an ISR is pending. (I'm not sure whether the DCO/XT wakeup 
time does apply in this case)
the instruction after the BIS is executed (it aslready had been fetched before 
the BIS was executed, hence the usual NOP after an LPM entry)
the status register including the GIE and LPM bits is stored on the stack
GIE ans LPM bits are cleared
the ISR is executed.

If the ISR doesn't manipulate the stored status register copy on the stack, 
then when exiting the ISR, teh SR is restord and LPM/GIE are
in effect again.

So if you clear the LPM bits inside the ISR (using the proper 'on_exit' 
macro!), MSP won't return to LPM.

However, your code example has several more flaws.
- When your ISR does not clear the IFG bit for th einterrupt, the ISR will be 
re-entered as soon as it exits.
If it does, the port1.ifg.pin1=0 assignment will clear a possible next 
interrupt, and you'll miss it.
- you enable porti.ie.pin1 in every loop. It stays enabled (unless the ISR 
disables it) and interrupts may
happen all the time (or after this point) independently of LPM4. You should 
clear GIE on exit of the ISR too,
so when main is awakened, no further interrupts are handled unless you want 
them again.
- you check for port1.in-.pin1. But even if an interrupt happened, P1.1 might 
have gone low again in the meantime.
It's better to set a global flag inside the ISR (don't forget to mark it 
volatile) and check this.
- depending on the compiler capabilities, the use of bitfields may result in 
less efficient code.
That's one reason why bitfields for the many registers (especially ports) have 
been removed from the 'official'
header files. Especially since every bit operation is a RMW (read-modify-write) 
operation on the whole register 
(which may have side-effects that are easily missed when one jus tlooks on the 
bit oepration).
Also, since the registers are 'volatile', manipulation of multiple bits in the 
same register results in multiple
RMW operations. Due to the volatile nature of the registers, the compiler is 
not allowed to group them.
(the sequential access might be intentional).

If you want to implement a debounce feature, a typical way to do it is to start 
a timer inside the port ISR
and disable port interrupts (PxIE=0).
When the timer expires, the tiemr ISR will check for the current port pin 
state, re-enable port interrupts and
depending on the port pin state will set a global flag and end LPM.
It gets a bit more tricky if you have multiple interrupt pins, but there have 
been implementations discussed
and posted in the 'official' MSP forum: e2e.ti.com.

JMGross


- Ursprüngliche Nachricht -
Von: Wayne Uroda
An: mspgcc-users@lists.sourceforge.net
Gesendet am: 06 Dez 2011 00:40:59
Betreff: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt

I have a question which isn't technically related to MSPGCC (more of a msp430 
question) but I thought one of you smart people 
might know.

Imagine the following scenario:

/* 1*/  while (1)
/* 2*/  {
/* 3*/  if (!port1.in.pin1)
/* 4*/  {
/* 5*/  // Enable interrupt (rising edge) for pin 1.1
/* 6*/  port1.ies.pin1 = 0;
/* 7*/  port1.ifg.pin1 = 0;
/* 8*/  port1.ie.pin1 = 1;
/* 9*/
/*10*/  // Enter sleep mode, but only if the pin is still not 
high
/*11

Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt

[Wayne Uroda]

Thanks. That is what I expected the wakeup keyword did so I am happy with using 
it.

I personally only use the critical and wakeup keywords. Of course putting dint 
and eint calls at the start and end of the function is easy, but I prefer 
critical as it saves the current state of GIE on the stack and pops it on exit 
(whereas hand coding dint eint will always leave your function with interrupts 
enabled).

There is probably some easy macro I don't know about to push and then pop the 
status register but if you push and then forget to pop I imagine you might rip 
your hair out for a while trying to work out what is going on :)

Our platform is fully hand coded from the ground up (custom C startup, custom 
linker scripts, custom ELF based tools) to allow for custom bootloader / 
firmware loading. So the critical and wakeup keywords will be the least of 
somebody's worries should they ever need to port the code to IAR ;)

- Wayne

-Original Message-
From: pabi...@gmail.com [mailto:pabi...@gmail.com] On Behalf Of Peter Bigot
Sent: Wednesday, 7 December 2011 11:59 AM
To: Wayne Uroda
Cc: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt

On Tue, Dec 6, 2011 at 5:53 PM, Wayne Uroda wayne.ur...@grabba.com wrote:
 Thanks for the discussion - I apologise for my code sample having flaws, it 
 isn't production code just something I threw together to illustrate the 
 point. In my case I am only interested in the level of the pin (sleep when it 
 is low, awake when it is high) and so I am not concerned with missing edges 
 other than the critical edge which brings me out of LPM4. I am aware that I 
 still need to be careful of the order in which I enable the interrupt/clear 
 the ifg and disable interrupts before finally checking the level of the pin 
 and entering LPM4 if appropriate.

 One thing that I have never done is use the on_exit macro - I use the wakeup 
 keyword instead - I'm guessing there are potential problems with the wakeup 
 keyword?

The wakeup function attribute in mspgcc is equivalent to having
bic_status_register_on_exit(0xF0) in your interrupt handler (and
LPM4_bits is 0xF0).  There's nothing intrinsically wrong with it
except that it's opaque, and will only do exactly that operation, so
you couldn't (for example) clear GIE on exit using it.

Personally I never remember what signal, wakeup, reentrant, and
critical as function attributes mean exactly, and if I encounter
them I have to go read the compiler source to remind me what they do.
As far as I know they're also specific to mspgcc, so people who use
IAR or CCS won't understand what you're doing either.

Peter


 - Wayne

 -Original Message-
 From: JMGross [mailto:msp...@grossibaer.de]
 Sent: Wednesday, 7 December 2011 12:47 AM
 To: MSPGCC mailing list,
 Subject: Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt


 Hello Wayne,

 you correctly detected a possible problem in your code, which from my 
 experience really is an exception. Most 'coders' don't
 care for realtime influences and then wonder why the code doesn't work (or 
 use a watchdog do reset the CPU when the code
 unexpectedly 'hangs'.

 A generic solution to your problem has already beenb pinted out. Set LPM and 
 GIE in the same instruction.
 Both, the LPM bits as well as GIE are located in the status register, so it 
 comes down to an atomic operation:
 BIS #(LPM4|GIE), R2

 In this case, if an interrupt happened before GIE is set and LMP is entered, 
 the following will happen:
 GIE/LPM is set.
 LMP is exited, since an ISR is pending. (I'm not sure whether the DCO/XT 
 wakeup time does apply in this case)
 the instruction after the BIS is executed (it aslready had been fetched 
 before the BIS was executed, hence the usual NOP after an LPM entry)
 the status register including the GIE and LPM bits is stored on the stack
 GIE ans LPM bits are cleared
 the ISR is executed.

 If the ISR doesn't manipulate the stored status register copy on the stack, 
 then when exiting the ISR, teh SR is restord and LPM/GIE are
 in effect again.

 So if you clear the LPM bits inside the ISR (using the proper 'on_exit' 
 macro!), MSP won't return to LPM.

 However, your code example has several more flaws.
 - When your ISR does not clear the IFG bit for th einterrupt, the ISR will be 
 re-entered as soon as it exits.
 If it does, the port1.ifg.pin1=0 assignment will clear a possible next 
 interrupt, and you'll miss it.
 - you enable porti.ie.pin1 in every loop. It stays enabled (unless the ISR 
 disables it) and interrupts may
 happen all the time (or after this point) independently of LPM4. You should 
 clear GIE on exit of the ISR too,
 so when main is awakened, no further interrupts are handled unless you want 
 them again.
 - you check for port1.in-.pin1. But even if an interrupt happened, P1.1 might 
 have gone low again in the meantime.
 It's better to set a global flag inside the ISR (don't

Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt

[Wayne Uroda]

When an interrupt is generated, the hardware pushes the PC and then the SR onto 
the stack. The hardware then clears the SR and loads PC with the appropriate 
interrupt address.

In MSPGCC, the first thing the compiler does on entry to an interrupt routine 
is push any registers clobbered during the interrupt routine to the stack. Then 
the interrupt work is done, then the registers are popped in the reverse order, 
then the RETI instruction causes the machine to pop back the SR and then the 
original PC is popped.

So if you want to do a context switch in your interrupt routine, you should 
push ALL the registers to the stack as you have indicated. You will have to 
break out some assembly code to do this. You will also (I'm guessing) need to 
stop GCC from generating the interrupt related pushes and pops. Probably best 
to write this whole interrupt handler in assembly so you can be sure what is 
going on.

So, you will need to do the following (Note that R0 to R3 are PC, SP, SR, and 
CG respectively) (this code surely doesn't work verbatim, it is just an example)

/* start of ISR */
/* first save all the general purpose registers to the stack */
push r15
push r14
... repeat
push r5
push r4

/* now we can do a context switch by swapping the SP with another VALID context 
*/
/* first back up the old SP to some address, then load in the new SP */
/* choosing the new context can be simple or complex, this depends on the type 
of scheduler you wish to use */
mov r1, oldSP
mov newSP, r1

/* should clear whatever interrupt flag got us to this ISR in the first place */
TODO

/* now we are operating in the new context, we should restore all registers and 
return from the interrupt */
pop r4
pop r5
... repeat
pop r14
pop r15
reti
/* end of ISR */

This means that your new context has its own stack, so make sure that each 
context (stack) is big enough for all the functions that they need to execute 
between task switching.
Note where I say VALID context - this must be a stack which already has 
registers r4 to r15 as well as the SR and PC to return to - otherwise you will 
get stack underrun when you execute the 12 pops and then the machine executes 
the 2 pops (SR and PC).

The smallest possible size a context could be is then 14 words or 28 bytes, but 
this doesn't leave any room for the stack to grow during your actual function.

If you want to perform only one function in this other context, maybe looking 
into nested interrupts would be better, as this scheme above will probably take 
a fair bit of effort to get working.

There are plenty of free RTOS around on the internet, I have not used any on 
the MSP430 though, but they would have done this work already.

As for link scripts, start with the GNU LD manual. Also look at the existing 
link scripts under the 'ldscripts' directory in your mspgcc installation.

Your example of a system which uses a function which can be replaced on-the-fly 
(in flash I assume) could be archived by reserving a block of RAM (just a 
global array for example, word aligned), and at startup copy your function into 
this block. Then if the system receives a new function it can overwrite the old 
function in ram and execute it. The functions should share the same return type 
and parameters as you say, to make calling it from C easy (call it through a 
function pointer).

Of course if you want it to be stored through a reset then yes, you will need 
flash, and yes you probably will need to write your own linker script to put 
the function at a known address and keep other functions out of its area. Keep 
in mind the smallest memory you can erase is a segment so you probably will 
want to put a whole segment (or multiple segments) aside for your loadable 
module.

- Wayne

-Original Message-
From: Sergio Campamá [mailto:sergiocamp...@gmail.com] On Behalf Of Sergio 
Campamá
Sent: Wednesday, 7 December 2011 12:34 PM
To: Wayne Uroda
Cc: Peter Bigot; mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt

Hey, maybe I'm straying a bit from the conversation, but

1. Is there a way to obtain (and set) the registers? I want to try a feature 
where I create preemptive threads, in which after certain interrupts, I will 
save the current context (registers) and the instruction line I was executing 
(which is already in the registers, the PC), and start executing from another 
address.. And when I'm done with that, reload the PC and all the other 
registers and resume working on that thread... I'm guessing that  8 * 16 = 
128 bytes would be the least memory I would need for each context save. Is it 
not?

2. Where can I find tutorials or more info to read about custom linking 
scripts? I also want to try a feature where I have a base system setup and a 
special memory area reserved for a module, and when the base system receives a 
new module (with a flash memory proxy or whatever), it replaces the old one... 
I'm assuming

[Mspgcc-users] Enter LPM4 without missing the wakeup interrupt

[Wayne Uroda]

I have a question which isn't technically related to MSPGCC (more of a msp430 
question) but I thought one of you smart people might know.

Imagine the following scenario:

/* 1*/  while (1)
/* 2*/  {
/* 3*/  if (!port1.in.pin1)
/* 4*/  {
/* 5*/  // Enable interrupt (rising edge) for pin 1.1
/* 6*/  port1.ies.pin1 = 0;
/* 7*/  port1.ifg.pin1 = 0;
/* 8*/  port1.ie.pin1 = 1;
/* 9*/
/*10*/  // Enter sleep mode, but only if the pin is still not 
high
/*11*/  if (!port1.in.pin1)
/*12*/  {
/*13*/  LPM4();
/*14*/  }
/*15*/  }
/*16*/
/*17*/  // Awake
/*18*/  // Do real work here
/*19*/  }

The ISR for port1 interrupt just wakes up the processor from LPM4 and clears 
the IFG for pin 1.1.

The problem I see is that there is a small window (between the execution of 
line 11 and line 13) where pin1.1 can go high, have the ISR handled and the IFG 
cleared, and then the system can incorrectly go into LPM4 even though pin1.1 is 
high.

My thoughts are that the only way around this is to avoid using LPM4 and poll 
the state of pin 1.1, which is what I have done in previous designs. As far as 
I know there is no way to atomically enter LPM4 and enable interrupts so that 
the pending pin1.1 IFG can be handled AFTER entering LPM4, thus bringing the 
system out of LPM4.

Has anybody come up against this? Is using LPM3 the best/only workaround?

I am using 1 family chips, MSP430F148 in particular.

Thanks,

- Wayne

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt

[Wayne Uroda]

Thanks Peter - yesterday I was saying if only there was a way to enter LPM4 
and enable interrupts at the same time in an atomic way - stupidly I did not 
even think about the mechanism behind eint and LPM4 macros and that I can just 
combine them in one atomic operation. 

As for forums, in the future I will post there, but I do detest having to sign 
up for yet another forum.

Thanks,

- Wayne

-Original Message-
From: pabi...@gmail.com [mailto:pabi...@gmail.com] On Behalf Of Peter Bigot
Sent: Tuesday, 6 December 2011 10:29 AM
To: Eric Decker
Cc: Sergio Campamá; Wayne Uroda; mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Enter LPM4 without missing the wakeup interrupt

On Mon, Dec 5, 2011 at 6:22 PM, Eric Decker cire...@gmail.com wrote:
 On Mon, Dec 5, 2011 at 4:05 PM, Sergio Campamá scamp...@ing.puc.cl wrote:

 Hello Wayne,

 The only difference between LPM3 and LPM4 is that the ACLK is stopped in
 LPM4, so moving onto LPM3 won't solve your problem. What is the P1.1
 connected to? If you wanted to wake the system up from LPM4 when there is
 an interrupt on P1.1, you could do this: (I believe that you want to sleep
 only if the pin is down)

 void function(){
        P1IES = BIT1;
        P1IFG = BIT1;
        P1IE |= BIT1;


        while(1){
                sleep_if_down()
                //do work
        }
 }

 __attribute__((critical)) void sleep_if_down(){
        if(! P1IN  BIT1){
                LPM4();
        }
 }

 interrupt(PORT1_VECTOR) PORT1_ISR(){
        //wake up from LPM4
        P1IFG = BIT1;
        _BIC_SR_IRQ(LPM4_bits);
 }

 What this does is that it checks if the P1.1 is down, if it is, it enters
 LPM4. Now, the __attribute__((critical)) part tells the compiler (I learned
 this in this mailing-list) to disable interrupts while in the function. So
 you won't handle the interrupt until after the comparison is made.


 Have you looked explicitly at the code generated for the above?

 If I understand critical correctly, it basically disables interrupts
  during the routine.

I believe that's what it does.  It often saves one word by putting the
disable into the prolog where the compiler can skip generating the
nop that usually has to follow it, and another by using reti
instead of ret.  It's still more opaque than I prefer.

The pattern I use for this sort of thing is:

volatile int vflag;  // global variable, only modified when interrupts disabled
  // ...
  while (1) {
__disable_interrupt();
if (! vflag) {
  // Sleep in LPM4 until interrupt
  __bis_status_register(LPM4_bits | GIE);
  // interrupts are enabled at this point, so jump out of disable region
  continue;
}
// acknowledge the state by clearing it
vflag = 0;
// do atomic handling here
__enable_interrupt();
// do non-atomic handling here

One key point code feature is that by invoking the intrinsic with its
arguments explicitly rather than using syntactic sugar macros, you
(and whoever maintains your code after you) know that you're enabling
interrupts, which is kinda important, if whatever you're waiting for
is signalled by an interrupt.  From what I see (and consistent with
what Eric said), LPM4() will not touch the interrupt flag, leaving
you with that race condition you mentioned if you left interrupts
enabled, and leaving you locked out if you didn't.

__disable_interrupt, __enable_interrupt, and __bis_status_register are
intrinsics the spelling of which may be different depending on your
compiler.  You would also use:

// set vflag if condition holds
if (vflag) {
  __bic_SR_register_on_exit(LPM4_bits);
}

in your interrupt handler.

Finally, the 20111205 release supports:

  __istate_t istate = __get_interrupt_state();
  __disable_interrupt();
  // do stuff here
  __set_interrupt_state(istate);

so you can disable interrupts then restore them to whatever state they
were at on entry.

If anybody isn't aware of http://www.43oh.com/forum/, I recommend that
site for questions of this sort.

   Which means that when you go asleep (LPM4)
 interrupts will be disabled and the cpu goes away forever because it can't
 take the Port1 interrupt.

 I believe you have to have interrupts enabled when you do the LPM4.   Which
 gets back to Wayne's critical region/race condition issue.


 eric



 You don't have to setup the IE and IES all the time, just the first time,
 that's why I took it out of the while, and the IFG gets cleared in the
 interrupt vector, no need to do it again.

 I hope this helps. Best regards,
 ---
 Sergio Campamá
 sergiocamp...@gmail.com




 On Dec 5, 2011, at 8:40 PM, Wayne Uroda wrote:

  I have a question which isn't technically related to MSPGCC (more of a
 msp430 question) but I thought one of you smart people might know.
 
  Imagine the following scenario:
 
  /* 1*/        while (1)
  /* 2*/        {
  /* 3*/                if (!port1.in.pin1)
  /* 4*/                {
  /* 5

Re: [Mspgcc-users] Confused about MSPGCC / MSPDEBUG...

[Wayne Uroda]

I too didn't know anything about MinGW and always was a little afraid to try, 
but it isn't hard really. It is just a compiler which lets you make windows 
executables afaik.

Building mspgccdebug under windows really is quite easy if you follow the 
instructions linked in the previous email. The exe can then be used in windows, 
cygwin, etc.

You can try the windows exe I built, no guarantees though:

http://www.locusia.com/mspdebug/mspdebug.7z

- Wayne

-Original Message-
From: Peter Johansson [mailto:rockets4k...@gmail.com] 
Sent: Wednesday, 30 November 2011 8:54 AM
To: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Confused about MSPGCC / MSPDEBUG...

On Tue, Nov 29, 2011 at 4:44 PM, Daniel Beer dlb...@gmail.com wrote:

 For mspdebug, you'd be best to compile using MinGW.

I am a long-time Cygwin user but I know practically nothing about
MinGW.  Does MinGW provide a command-line shell and tools like Cygwin?
 Or is MinGW just a compilation environment?

I am aware of the MinGW binary build (which appears to track patches
within 24 hours) but are there any specific reasons to use MinGW over
an mspgcc binary compiled under Cygwin?  (aside from the availability
of the MinGW binary, that is.)  Are there any problems using
MinGW-compiled software in a Cygwin shell?

Many thanks to anyone who can provide a brief overview of these topics.

-p.

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] MSP430-insight

[Wayne Uroda]

I have a couple of stupid questions:

1. Is there any way to search the mspgcc-users mail archive on sourceforge? (I 
may not have needed to ask question 2).

2. How/where can I get MSP430-insight? Is it available in binary form for 
windows 7? Or is there now a better alternative?

Thanks,

- Wayne
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] MSP430-insight

[Wayne Uroda]

Thanks Eric.

I managed to find insight in the last mspgcc4 build - upon seeing how awful it 
looks I think I'll stick with gdb.

- Wayne

From: Eric Decker [cire...@gmail.com]
Sent: Tuesday, 11 October 2011 8:32 AM
To: Wayne Uroda
Cc: GCC for MSP430 - http://mspgcc.sf.net
Subject: Re: [Mspgcc-users] MSP430-insight

On Mon, Oct 10, 2011 at 3:12 PM, Wayne Uroda 
wayne.ur...@grabba.commailto:wayne.ur...@grabba.com wrote:
I have a couple of stupid questions:

1. Is there any way to search the mspgcc-users mail archive on sourceforge? (I 
may not have needed to ask question 2).

http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/


2. How/where can I get MSP430-insight? Is it available in binary form for 
windows 7? Or is there now a better alternative?

don't know, don't know, don't know.I don't do no stinkin windows.

Here is the search url...

http://www.mail-archive.com/search?q=msp430-insightl=mspgcc-users%40lists.sourceforge.net


Thanks,

- Wayne
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.netmailto:Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users



--
Eric B. Decker
Senior (over 50 :-) Researcher



--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] Critical keyword

[Wayne Uroda]

Hi Guys,

I am moving to the latest version of mspgcc and notice that the critical 
keyword no longer compiles.

Any tips on what supersedes the critical keyword or should I just put dint and 
eint around my critical functions?

Thanks,

- Wayne 
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] problem converting signed shortto abs unsigned long

[Wayne Uroda]

According to the C standard, when you apply the unary operator - to x, x
is first promoted to an integer.
I think the difference between the PC and the MSP430 is that on the
MSP430, the variable is promoted to 16bits which is the same size as the
short. On the PC, x is first promoted to 32bits.

This is a common annoyance of mine on the msp430 when dealing with 32bit
types. On any line giving a 32bit result, try casting all the operands
to long (or unsigned long) before you work on them:

short x = -32768;
unsigned long  y = -((long)x);

does this fix your problem?

- Wayne

-Original Message-
From: Carl [mailto:c...@turner.ca] 
Sent: Wednesday, 24 February 2010 10:01 AM
To: GCC for MSP430 - http://mspgcc.sf.net
Subject: Re: [Mspgcc-users] problem converting signed shortto abs
unsigned long

On Tue, 2010-02-23 at 23:37 +, Grant Edwards wrote:
 On 2010-02-23, Carl c...@turner.ca wrote:
  On Tue, 2010-02-23 at 23:08 +, Grant Edwards wrote:
  The values being passed to printf and then displayed are
  unsigned.  On the '430, that's 16 bits.  On the PC that's 32
  bits.
 
  A short on both my system and 430 is 16 bits. A long on both my
 system
  and the 430 are both 32 bits. I can inspect the memory with gdb. The
  problem is the upper 16 bits of y on the 430 are set. Why does it do
  this?
 
  On PC:
 
  (gdb) p sizeof(y)
  $1 = 4
  (gdb) p /x y
  $2 = 0x8000
 
  On 430:
 
  (gdb) p sizeof(y)
  $1 = 4
  (gdb) p /x y
  $2 = 0x8000
 
 Unless you provide the code that was run up to that point,
 there's no way to answer your question.
 
 But, I suspect that on the msp430, the value in question was an
 int at some point and then got converted to a long. 
 
 On the MSP430, that resulted in the value being sign-extended
 when it got converted from 16 to 32 bits.  On a PC, an int
 and long are both 32 bits, so there is no sign extension when
 a value is converted from an int to a long.


Sorry, here is the code for the msp430:

#include io.h
int main(void)
{
short x = -32768;
unsigned long  y = -x;
LPM0;
}

And same code as my previous posting for the PC:

#include stdio.h
int main()
{
short  x = -32768;
unsigned long  y = -x;
printf(sizeof short =%d, x=%d, y=%lu\n, sizeof(short), x, y);
}

As you can see there is no int type used.

Carl





--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] stack variable in flash?

[Wayne Uroda]

That certainly looks strange how it is adding to the stack. (First line is 
taking the __stack symbol, adding 4, and putting it in R1 (the stack pointer).
__stack is defined by the linker so the full linked listing may shed some light.

Can you use 
msp430-objdump -D output.elf
To dump the final, linked assembly and post it?
-D may not be the only option you need, I am away from the computer right now, 
it should be ok though iirc.

Does the problem occur if you use optimisations like -O2? Or if you don't use 
long variables?

- Wayne
Sent via BlackBerry from Vodafone

-Original Message-
From: Carl c...@turner.ca
Date: Mon, 22 Feb 2010 12:21:01 
To: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] stack variable in flash?

Here is another program to illustrate the problem I'm seeing. The
problem is evident independent of gdb.

#include io.h
int main()
{
unsigned long i;
P4DIR |= 0x0e;  /* set P4.1-3 to output direction */
P4OUT = 0;  /* set the three LEDs to off  */
i = 123;
if (i == 123)
P4OUT |= 0x04;  /* turn on P4.2 */
for(; i1; i++)
{
if ((i%1000)==0)
P4OUT ^= 0x02;  /* toggle P4.1 */
}
if (i == 1)
P4OUT |= 0x08;  /* turn on P4.3 */
LPM0;
}

What I would expect to see is that P4.1 LED toggles 10 times, and P4.2
and P4.3 LEDs turn and stay on. I would expect to see this behavior if i
is on the stack or in a register. I do see the expected behavior if I
declare i as a global variable. I don't see the expected behavior with
the above program. With the above program none of the LEDs turn on at
all.

Attached is the .lst file. I don't know assembler and I'm new to the
msp430 so I appreciate the help. I don't even understand the first line:

 31  3140   mov #(__stack+4), r1

What is at stack+4? Shouldn't the stack be growing 'down'?

(gdb) p i
$1 = (long unsigned int *) 0x3104
(gdb) p i
$2 = 1518354610
(gdb) x /x 0x3100
0x3100 _reset_vector__: 0x31004031
(gdb) x /x 0x3104
0x3104 __low_level_init: 0x5a8040b2
(gdb)

The command I used to generate the lst file is as follows:

msp430-gcc -c -g -O0 -W -Wa,-a,-ad -mmcu=msp430x2618
-I/opt/mspgcc4/msp430-gcc-4.4.2/include/ main.c  main.lst

Thanks for the comments so far.

Carl


On Mon, 2010-02-22 at 12:53 +0100, JMGross wrote:
 Chances are, that the optimizer has replaced the 'variable' by a register.
 There's no reason to reserve space on the stack, increase it there and then 
 clean up the stack if the return value needs to be in R15 for return anyway.
 Also, since the scope of the variable is limited to the function and the 
 address(!) of the variable is never forwarded anywhere, declaring it volatile 
 has no effect at all.
 I _think_ there is a compiler flag to disable register variables. But 
 normally, the compiler uses them, in any optimisation stage.

 My guess is that GDB gets the symbol, but cannot handle it properly and just 
 assumes it somewhere at the start of .text. Or the linker has put it at start 
 of .txt since it isn't used anywhere.
 A look into the .lst file should make things clear.
 This is always my reference if something goes wrong.
 My bet is that this address is never accessed anywhere and all is done 
 directly in a register.

 JMGross

 - Ursprüngliche Nachricht -
 Von: Carl
 An: GCC for MSP430 - http://mspgcc.sf.net
 Gesendet am: 20 Feb 2010 22:16:22
 Betreff: Re: [Mspgcc-users] stack variable in flash?

 If I declare it as a global it is where I expect at the beginning of RAM
 (0x1100). But if it is on the stack in the main function, even if I
 declare it volatile, use asm(); // __asm__ __volatile__ (); or pass
 it to a function, the variable address is in flash at 0x3102. It doesn't
 make sense.

 Now if I use the program:

 #include io.h

 int f1()
 {
 volatile int i = 5;
 i += 2;
 return i;
 }

 int main()
 {
 while(1)
 {
 f1();
 }
 }

 The variable i address is on the stack in RAM at 0x30f8 which makes
 sense. But if I change the compile option to use -02. Then the function
 stack variable, i, goes back to being located in flash at 0x3102. And
 it's value is not initialed to 5 nor is 2 added to it. The value of i is
 constant = 12544 (0x3100.)


 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 Mspgcc-users mailing list
 Mspgcc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] stack variable in flash?

[Wayne Uroda]

I have been using mspgcc for years and I've never seen gdb say a variable was 
optimised out, it usually displays freaky values and you should then read the 
assembly listing to work out what is going on. Even halfway through functions 
variables can go out of scope and get reused.

The bug here is probably that mspgcc is ignoring your -O0 and performing some 
optimisations anyway.

I think you will find that as soon as your program actually does something, i 
will be where you expect it to be.

- Wayne
Sent via BlackBerry from Vodafone

-Original Message-
From: c...@turner.ca
Date: Sat, 20 Feb 2010 15:08:15 
To: GCC for MSP430 - http://mspgcc.sf.netmspgcc-users@lists.sourceforge.net; 
N. Coeseln...@nctdev.nl
Subject: Re: [Mspgcc-users] stack variable in flash?

 I don't think the optimizer is not removing code or variables when -O0. When 
stepping through with gdb if you try to display a variable that is optimized 
out, it notifies you by displaying optimized out. This is not happening.

I've tried declaring a global variable it works as expected.

The problem I'm observing is when a variable is on the stack.

The code I'm posting is for example only in trying to illustrate a problem in 
my code where the stack variables are being used but do not have the expected 
values. When stepping through with gdb, the stack variables are is flash. I 
have assert statements in my code that catch this even when not using gdb.

I can post a bigger example if that will help.

Carl


On Sat, 20 Feb 2010 23:49:57 +0100
 N. Coesel n...@nctdev.nl wrote:
Try this first:

volatile int i;

int main()
{
while(1)
{
i++;
}
}


IMHO you are chasing a dead horse because the optimizer is removing code
that doesn't do anything. Inside main, the scope of the variable is limited
to main so volatile probably doesn't mean anything.


At 14:16 20-2-2010 -0700, Carl wrote:
If I declare it as a global it is where I expect at the beginning of RAM
(0x1100). But if it is on the stack in the main function, even if I
declare it volatile, use asm(); // __asm__ __volatile__ (); or pass
it to a function, the variable address is in flash at 0x3102. It doesn't
make sense.

Now if I use the program:

#include io.h

int f1()
{
volatile int i = 5;
i += 2;
return i;
}

int main()
{
while(1)
{
f1();
}
}

The variable i address is on the stack in RAM at 0x30f8 which makes
sense. But if I change the compile option to use -02. Then the function
stack variable, i, goes back to being located in flash at 0x3102. And
it's value is not initialed to 5 nor is 2 added to it. The value of i is
constant = 12544 (0x3100.)

I noticed at new version of mspgcc4 is out as of Feb 18, 2010. I've
tried to install it on both a Fedora 9 and a Ubuntu machine but get the
same error:

Failed to execute sh do-gcc.sh /opt/msp430-gcc-4.4.3 4.4.3
http://ftp.uni-kl.de; build gcc-4.x 4.3.1 2.4.1
at ./buildgcc.pl line 237, STDIN line 9.


Carl



On Sat, 2010-02-20 at 09:08 +0100, N. Coesel wrote:
 Carl,

 Try to declare it outside the function (as a global).

 At 19:43 19-2-2010 -0800, you wrote:
 I tried declaring as volatile and it is at the exact same address.
 
 Carl
 
 On Sat, 20 Feb 2010 01:35:03 +
  Wayne Uroda wayne.ur...@grabba.com wrote:
 try declaring i as volatile, or the compiler will probably get rid of it
 since it has no effect or side-effect.
 Sent via BlackBerry from Vodafone
 
 -Original Message-
 From: Carl c...@turner.ca
 Date: Fri, 19 Feb 2010 18:29:03
 To: mspgcc-users@lists.sourceforge.net
 Subject: [Mspgcc-users] stack variable in flash?
 
 I'm sure that I'm missing some basic here but I'm not sure what. The
 first variable on the stack is in an unexpected location. I would expect
 it to be located somewhere on the stack in RAM (0x30ff-0x1100) but it is
 located in flash memory and it does not get set or incremented.
 
 
 #include io.h
 
 int main()
 {
 int i=0;
 while(1)
 i++;
 }
 
 



---
---
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users



--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists

Re: [Mspgcc-users] stack variable in flash?

[Wayne Uroda]

try declaring i as volatile, or the compiler will probably get rid of it since 
it has no effect or side-effect.
Sent via BlackBerry from Vodafone

-Original Message-
From: Carl c...@turner.ca
Date: Fri, 19 Feb 2010 18:29:03 
To: mspgcc-users@lists.sourceforge.net
Subject: [Mspgcc-users] stack variable in flash?

I'm sure that I'm missing some basic here but I'm not sure what. The
first variable on the stack is in an unexpected location. I would expect
it to be located somewhere on the stack in RAM (0x30ff-0x1100) but it is
located in flash memory and it does not get set or incremented.


#include io.h

int main()
{
int i=0;
while(1)
i++;
}

msp430-gcc -g -O0 -mmcu=msp430x2618 -I/opt/msp430/4.4.2/include main.c

(gdb) load a.out
Loading section .text, size 0x46 lma 0x3100
Loading section .vectors, size 0x40 lma 0xffc0
Start address 0x3100, load size 134
Transfer rate: 1 KB/sec, 33 bytes/write.
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
main () at main.c:7
7   i++;
(gdb) p i
$1 = (int *) 0x3102




--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] source code stepping and backtrace

[Wayne Uroda]

Hi Carl,

I suffer the same problems. I work around them in awful ways - set
breakpoints for single stepping, manually examine the stack to perform a
backtrace (which takes a long time as you can imagine - I just look for
values which look like addresses and then look for them in my code
listing. My stack is rarely that deep when I need a BT though).

I believe somebody may have fixed these issues in just a few months ago.
I haven't been motivated to try it out - please let me know if it is
workable.

== Begin Quote (26/10/2009) ==
Hi, All,
 
Please  be  informed  that  the GDB 6.8 port has been fixed to support
'next',  'finish'  and  'bt' instructions correctly, as well as target
function  execution.  The  updated  sources  and  binary  packages are
available at the http://sf.net/projects/mspgcc4/files page.

--
Best Regards,
 Ivan Shcherbakov mailto:shcherba...@eit.uni-kl.de
 TU Kaiserslautern, Germany
 Department of Real-Time Systems

== End Quote ==

Good luck!

- Wayne Uroda

Re: [Mspgcc-users] Announcement: MSP430-GCC 4.3.4

[Wayne Uroda]

What is MSP430X support like on this new port? Stable enough for real world 
production use?

- Wayne 
Sent via BlackBerry® from Vodafone

-Original Message-
From: Peter Jansen pwjan...@yahoo.com
Date: Wed, 9 Sep 2009 02:30:41 
To: GCC for MSP430 - http://mspgcc.sf.netmspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Announcement: MSP430-GCC 4.3.4

Hi Ivan,



 The  bigger  code problem in your case is caused by GCC4 inlining some
 functions by default. For example, an non-static inline function, that
 is  used  only  a  single  time  (such  as  init_SPI in your case), is
 included  in the object file twice (the function itself and its inline
 call).  If  you specify the -ffunction-sections attribute (and use the
 -gc-sections linker switch), the code size will be less than using GCC
 v3.

 If  you  don't want to use the -ffunction-sections, you either need to
 disable  inlining  completely  (-fno-inline),  or  tweak  the  maximum
 inlined  function  size  (-finline-limit=x),  that  is  more  precise.

Thanks, the fno-inline works and reduces the code.

The bigger project I have, the code size is about the same.

There is some movement of things from the data section to the bss section with 
gcc-4.3.4 (I assume variables initialized with 0 or something).

I did have to add the section .debug_ranges to the linker script as it was 
going into the data section by default and using extra space (similar problem 
here)

http://osdir.com/ml/lib.newlib/2005-05/msg00011.html

Regards,

Peter Jansen



  
__
Find local businesses and services in your area with Yahoo!7 Local.
Get started: http://local.yahoo.com.au

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] changes of the memory mapping for family x5xx

[Wayne Uroda]

I don't see any reason not to simply keep resetting the WDT as part of the C 
startup routine. Sure it probably means the startup time is increased by some 
percentage (20%? 30%?) but it seems more logical to match the behaviour with 
what the datasheet says.

Having to turn off or reset the watchdog timer is just another quirk of using 
an MCU. I don't think it is mspgcc's job to make the MSP430 behave like an x86 
environment running C code, since code written for MCU tends to be very 
hardware oriented anyway (uarts, spi, pins, timers, interrupts, etc).

Personally I think that the startup code should be compiled and linked in by 
the user - simply provide some startup C code in the getting started guide. 
This would teach programmers more about how the memory init is done, and the 
implications on flash and ram of const and non-const arrays, etc.

It isn't like mspgcc is user friendly right now, it doesn't even support the 
430X architecture from a binary installer yet (just had to get that dig in - if 
it does now please let me know!)

-Wayne
Sent via BlackBerry® from Vodafone

-Original Message-
From: JMGross msp...@grossibaer.de

Date: Fri, 3 Apr 2009 15:49:18 
To: MSPGCC mailing list,mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] changes of the memory mapping for family x5xx


There are always some hardware-dependent things you cannot leave unaddressed.

Unfortunately, clearing the RAM and copying the variable initialisation can 
take longer than the WDT will allow with its PUC settings.
So it is absolutely necessary to somehow address this.

When MSPs did have only 256 bytes of RAM, the WDT was not a problem, but when 
devices with up to 16KB were introduced, it proved impossible to 'just do the C 
stuff and ignore the hardware' in the startup code.
'other GCC flavors' usually don't have a WDT. And some have a WDT PUC-default 
of several hundred to thousands of milliseconds.

Currently the WDT is disabled, but that's a bad thing too (see my other post).

JMGross

- Ursprüngliche Nachricht -
Von: N. Coesel
An: GCC for MSP430 - http://mspgcc.sf.net
Gesendet am: 03 Apr 2009 10:21:12
Betreff: Re: [Mspgcc-users] changes of the memory mapping for family x5xx

I've typed this before and I'll repeat it again: this issue again proves
that the close integration between processor families and the MSPGCC 
toolchain is a
bad idea. Most questions on this mailing list are about problems due to this
close integration. IMHO the toolchain should have modes for architectural 
differences like
other GCC flavors have. This forces developers to 'tailor' the
toolchain to the controller they are using and eliminates questions about
'unsupported' controllers. Also, initialisation of microcontroller 
pheripherals
shouldn't be done inside a C library at all. The low level initialisation 
should setup the stack, clear the RAM and jump to main. Have the developer 
choose what gets initialized and how. That's how its done on other 
architectures and probably for a good reason.


--
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] # defines in Header Files

[Wayne Uroda]

I believe it is to do with the pull-up resistors available in the 2 family 
chips. The 1 family didn't have pull-ups.

- Wayne
Sent via BlackBerry® from Vodafone

-Original Message-
From: Anthony L blueshockz...@hotmail.com

Date: Mon, 30 Mar 2009 07:43:18 
To: mspgcc-users@lists.sourceforge.net
Subject: [Mspgcc-users] # defines in Header Files


--

Re: [Mspgcc-users] Interrupt vectors are ignored with asm rountines(MSP430F4783)

[Wayne Uroda]

Are you compiling with the -nostartfiles flag? If so, you can define the 
vectors yourself (maybe you need to, I am not sure...)

Make an array which is the size of your vectors, and initialise it manually

Something like
__attribute__ ((section(.vectors))) unsigned short loadVectors[] = {(unsigned 
short)unexpected, (unsigned short)unexpected, (unsigned short)someISR, ... };

Make sure that it has the correct number of entries.

Apologies if this code is incorrect as I don't have mspgcc here to check.  I 
use something similar except my ISR routines are fixed stubs which branch to 
other locations, so I am not sure if the function will work correctly at 
compile/link time.

If you are not using -nostartfiles, then sorry I don't think I can help!

Good luck!

- Wayne
Sent via BlackBerry® from Vodafone

-Original Message-
From: thln th...@ap3.fr

Date: Wed, 18 Mar 2009 11:23:07 
To: GCC for MSP430 - http://mspgcc.sf.netmspgcc-users@lists.sourceforge.net
Subject: [Mspgcc-users] Interrupt vectors are ignored with asm rountines
(MSP430F4783)


project with MSP430F4783

first problem solved here :
http://sourceforge.net/mailarchive/forum.php?thread_name=49BF8544.7090708%40ap3.frforum_name=mspgcc-users
Thanks 'Sergey A. Borshch'

In my projects, I use my own startup routine (in assembler) ! I use
several interrupts :
NMI_VECTOR, WDT_VECTOR, BASICTIMER_VECTOR, PORT1_VECTOR
but all of theses are ignored (see below) only _reset_vector__ is correct

8008 __ctors_end:
8008: 30 40 0c 80 br #0x800c

800c _unexpected_:
800c: 00 13 reti

800e _reset_vector__:
800e: 31 40 ee 05 mov #1518, r1 ;#0x05ee
8012: d2 c3 31 00 bic.b #1, 0x0031 ;r3 As==01
8016: d2 d3 32 00 bis.b #1, 0x0032 ;r3 As==01
...
8144 vector_60:
8144: d2 d3 32 00 bis.b #1, 0x0032 ;r3 As==01
...
8314 vector_40:
8314: f2 c0 40 00 bic.b #64, 0x0023 ;#0x0040
8318: 23 00
...
832a vector_32:
832a: 00 13 reti
...
832c vector_52:
832c: 12 12 70 01 push 0x0170

part of HEX file :
*:10FFE8800880088008800880088008800880D1*
*:10FFF8800880088008800880088008800E80BB*

reset vector : good (0x800E) !
all others vectors are wrong : point to 0x8008 !!!

Thanks for reply!




--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Re: [Mspgcc-users] Interrupt issues

[Wayne Uroda]

I know this is again off topic, but, what does the OS/scheduler do if there are 
no threads? :)

Why not just make your own defines for the LPM modes the way you like?
Sent via BlackBerry® from Vodafone

-Original Message-
From: Bernard Mentink bment...@gmail.com

Date: Tue, 3 Mar 2009 07:36:52 
To: msp...@grossibaer.de; GCC for MSP430 - 
http://mspgcc.sf.netmspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] Interrupt issues


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

Re: [Mspgcc-users] Interrupt issues

[Wayne Uroda]

Are interrupts enabled? Is the timer interrupt enabled? The timer's clock 
source is still active in LPM1?
Don't know what else it could be! I've not used an RTOS on 430 though.

- Wayne
Sent via BlackBerry® from Vodafone

-Original Message-
From: Bernard Mentink bment...@gmail.com

Date: Mon, 2 Mar 2009 10:29:59 
To: GCC for MSP430 - http://mspgcc.sf.netmspgcc-users@lists.sourceforge.net
Subject: [Mspgcc-users] Interrupt issues


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

Re: [Mspgcc-users] multiple definition of ...

[Wayne Uroda]

If the header file is included in multiple C files, this is why you are seeing 
the multiple definition error. It is more correct to put the definition in one 
C file only, then put a declaration in the header file:

Strings.c:
const char AverageCurrentDisp[]   = Bat Avg Current;

Strings.h:
extern const char AverageCurrentDisp[];

This will ensure there is only one definition of the string, but it can be used 
in any file if you include strings.h.

I don't quite understand your other question, .text is ROM (.data and .bss are 
RAM). Hopefully if you define your strings this way the problem will vanish? If 
not, try removing code until your project compiles, it may be possible that you 
have simply run out of code space. Try turning optimisation on with -O2 cflag.

Good luck! Let us know if you have more troubles.

- Wayne

Sent via BlackBerry® from Vodafone

-Original Message-
From: Flugeldorph la...@pinnacleengraving.com

Date: Fri, 13 Feb 2009 10:54:22 
To: mspgcc-users@lists.sourceforge.net
Subject: [Mspgcc-users]  multiple definition of ...



Hello,

   I have been using the IAR compiler for my work with an msp430F135 mcu.
The client that I am working for was going to purchase a license to IAR, but
thought the price too high. So, a few days ago, I began the task of setting
up a gcc environment (including CodeBlocks), and adjusting my code to work
with the new environment. I had definde all of my strings that I displayed
on an LCD using #defines  like:

#define AverageCurrentDisp   Bat Avg Current

I soon discovered that when I used these precompiler directives in gcc, the
string was given an address which began at 0xfc00, and quickly over running
the .text section. So, I looked in the manual, and found out that if I
defined the strings as constants, they would be allocated in the main ROM
space... SO, I created a module 'Constants.h' like

const char AverageCurrentDisp[]   = Bat Avg Current;

Now I have a new problem. In spite of the fact that I use a

#ifndef __Constant__h
#define __Constant__h
#endif

around my new .h file, I am getting an error message:

obj\Debug\Display.o:(.text+0x30): multiple definition of
`AverageCurrentDisp'

What am I doing wrong, and why does it seem as though the string is still
being placed in the .text section?

--
View this message in context: 
http://www.nabble.com/multiple-definition-of-...-tp22002722p22002722.html
Sent from the MSP430 gcc - Users mailing list archive at Nabble.com.


--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mspgcc-users] Help with building MSP430X gcc please!

[Wayne Uroda]

.o emsp430xG437.o emsp430xG438.o emsp430xG439.o 
emsp430x435.o emsp430
   x436.o emsp430x437.o emsp430x447.o emsp430x448.o emsp430x449.o 
emsp430xG4616.o e
   msp430xG4617.o emsp430xG4618.o emsp430xG4619.o  
../bfd/.libs/libbfd.a ../libiber
   ty/libiberty.a 
./../intl/libintl.a  
   gcc: emsp430x1471.o: No such file or 
directory  
   gcc: emsp430x1481.o: No such file or 
directory  
   gcc: emsp430x1491.o: No such file or 
directory  
   gcc: emsp430x2001.o: No such file or 
directory  
   gcc: emsp430x2011.o: No such file or 
directory  
   gcc: emsp430x2002.o: No such file or 
directory  
   gcc: emsp430x2012.o: No such file or 
directory  
   gcc: emsp430x2003.o: No such file or 
directory  
   gcc: emsp430x2013.o: No such file or 
directory  
   gcc: emsp430x2234.o: No such file or 
directory  
   gcc: emsp430x2254.o: No such file or 
directory  
   gcc: emsp430x2274.o: No such file or 
directory  
   gcc: emsp430x423.o: No such file or 
directory   
   gcc: emsp430x425.o: No such file or 
directory   
   gcc: emsp430x427.o: No such file or 
directory   
   gcc: emsp430x4250.o: No such file or 
directory  
   gcc: emsp430x4260.o: No such file or 
directory  
   gcc: emsp430x4270.o: No such file or 
directory  
   gcc: emsp430xG4616.o: No such file or 
directory 
   gcc: emsp430xG4617.o: No such file or 
directory 
   gcc: emsp430xG4618.o: No such file or 
directory 
   gcc: emsp430xG4619.o: No such file or 
directory 
   make[4]: *** [ld-new.exe] Error 
1   
   make[4]: Leaving directory 
`/home/Wolf/binutils-2.19/ld'
   make[3]: *** [all-recursive] Error 
1
   make[3]: Leaving directory 
`/home/Wolf/binutils-2.19/ld'
   make[2]: *** [all] Error 
2  
   make[2]: Leaving directory 
`/home/Wolf/binutils-2.19/ld'
   make[1]: *** [all-ld] Error 
2   
   make[1]: Leaving directory 
`/home/Wolf/binutils-2.19'   
   make: *** [all] Error 2 



Any ideas? Can somebody please outline some simple build steps for me? I 
see others are building it ok so I am obviously missing something.


Perhaps the build steps could be put on the wiki too? That would be 
great. (Also a link to the wiki from the mspgcc website would be good 
but I am not going to hold my breath).


Thanks!

- Wayne Uroda

[Mspgcc-users] Beginners guide to contributing to MSPGCC please?

[Wayne Uroda]

Hi everyone,

I work at a company where one of our products uses an MSP430F147. We
have been using MSPGCC since the start of that particular project and
are very happy with how it works.

Recently we have started a new project around the MSP430F2418. We have
since learned that MSPGCC doesn't support the extended memory above
64kB.
I have a little bit of time to try and fix MSPGCC, because we want to
provide it to customers so that they can develop custom firmware for
the device.

I need a bit of a push in the right direction so I can help to get this
support into msp430-gcc.

Firstly, I have built binutils-2.18.50 with the following patches
applied, in this order: (from /packaging/patches)

binutils-2.18-14x1-20x1-20x2-20x3-22x4-42x-42x0-461x.patch
binutils-2.18-msp430x24x-msp430x26x.patch
binutils-ld_scripts.patch
binutils-2.18-430X.patch

binutils builds and as far as I can tell the assembler contains some
kind of support for calla and other extended opcodes.
If I create a file test.asm and write in it:

calla #0x12345

and assemble it with no arguments, I get the following:
$ ./msp430-as test.asm
test.asm: Assembler messages:
test.asm:1: Error: Extended instruction (calla) not allowed with
msp430x11 mcu

This leads me to think that there is some support for calla (msp430-as
knows about it at least).

When I try with the mcu set to msp430x2418 I get the following:
$ ./msp430-as -mmcu=msp430x2418 test.asm
test.asm: Assembler messages:
test.asm:1: Error: Illegal instruction or not implemented opcode.

it works fine though if my assembly file reads "call #0x1234" so I
think it doesn't know about calla somehow.

I have also built msp430-gcc according to the build instructions in the
mspgcc manual, against the patched version of binutils. I get the same
assembler error when I try to use inline assembly with the "calla"
instruction.

Is it just the calla instruction that doesn't work? can somebody
provide me with some instructions on how to get started with getting
the inline assembler working, so I can look at patching gcc to allow it
to call functions above 64kB?

Many thanks,
- Wayne Uroda