Hi, We have the following program:

// function is called by
// function(11);

void function(u16 number)
[...]
    ae18:	04 41       	mov	r1,	r4	
    ae1a:	34 50 0e 00 	add	#14,	r4	;#0x000e
    ae1e:	31 50 ae fb 	add	#-1106,	r1	;#0xfbae
    ae22:	84 4f f8 fb 	mov	r15,	-1032(r4);0xfbf8(r4)

[ r15 contains the function parameter '11' ]
[ r4 points to 0x05b8, with preincrement it points to 0x01b0 ]
[ but that's the peripheral's area! (0x000 .. 0x1ff) ]
[ with minidebug you can see that nothing is written to this address ]

	BEGIN_BASIC_BLOCK( ((95) - number) ); 
    ae26:	3f 40 5f 00 	mov	#95,	r15	;#0x005f
    ae2a:	1f 84 f8 fb 	sub	-1032(r4),r15	;0xfbf8(r4)

[ this sub should write the result from '95 - 11' into r15, however the result of '95 - 0' is written to r15 ]

we have configured the openMSP430 to look like the msp430f147 (1k RAM, 32k ROM). We provide ROM and RAM which is generated by Xilinx coregen 13.3. Mapping this block memory causes following Warnings:

WARNING:PhysDesignRules:812 - Dangling pin DOA2 on
   block: ram_8x512_lo_0/U0/xst_blk_mem_generator/gnativebmg.native_blk_mem_gen/
   valid.cstr/ramloop[0].ram.r/s3_noinit.ram/dpram.dp36x36.ram.A : RAMB16_RAMB16
   A.

And this for DOA2 .. DOA31 on ram_8x512_lo and ram_8x512_hi. Xilinx answer to this would suggest to ignore the Warnings. However, I still think we did something wrong. Has anyone an idea? Thank you in advance.

Hi Simeon,

If the "mov r15, -1032(r4)" writes to the peripheral area, it sounds quite normal that you read back 0. Therefore, I don't think the Xilinx RAM is the problem.

For me, it looks like a kind of stack underflow... which you could try to overcome by increasing the size of your stack (with GCC you can do that with either with a linker script or with the "-minit-stack" switch.

Hope this helps.

Olivier

Actually, re-reading your post, it sounds really weird to me that with only 1024 Bytes of data memory, GCC will generate an instruction targeting a "-1032(r4)" address... which will alway lay outside the data memory space even if R4=1024-1 :-/

Maybe you should double check the MSPGCC setup.

Olivier

My msp430-gcc's version:

msp430-gcc --version
msp430-gcc (GCC) 4.5.3

I recompiled it with a friend's setup:

msp430-gcc --version
msp430-gcc (Gentoo 4.6.1_p20111205 p1.0) 4.6.1

The resulting builds vary a little, however the output for the problematic function is completely identical ("sub -1032(r4),r15 ;0xfbf8(r4)").

A symbol tables excerpt:

msp430-gcc-4.6:

main.elf:     file format elf32-msp430

SYMBOL TABLE:
00008000 l    d  .text	00000000 .text
00000200 l    d  .data	00000000 .data
00000414 l    d  .bss	00000000 .bss
0000ffe0 l    d  .vectors	00000000 .vectors

msp430-gcc-4.5:

main.elf:     file format elf32-msp430

SYMBOL TABLE:
00008000 l    d  .text	00000000 .text
0000f496 l    d  .rodata	00000000 .rodata
00000200 l    d  .data	00000000 .data
00000414 l    d  .bss	00000000 .bss
0000046c l    d  .noinit	00000000 .noinit
0000ffe0 l    d  .vectors	00000000 .vectors

I like your idea of the stack underflow. However shouldn't the compiler complain about the access to this area, because, as you said, the target address with a preincrement of -1032 will always be out of range?

Providing an own map file never worked for us. It looks like the compiler constructs its map file on the fly.

If we can rule out the openmsp430 as cause for this error, I can start bugging the msp430-gcc project ;)

We can rule out the openmsp430 as cause for this error. CodeComposer 4 did report about size problems:

'Building target: simeon_test.out'
'Invoking: Linker'
"C:/Program Files (x86)/Texas Instruments/ccsv4/tools/compiler/msp430/bin/cl430" --silicon_version=msp -g -O0 --define=__MSP430F147__ --define=msp430 --diag_warning=225 --printf_support=minimal -z -m"simeon_test.map" --stack_size=80 --heap_size=80 --use_hw_mpy=16 --warn_sections -i"C:/Program Files (x86)/Texas Instruments/ccsv4/msp430/include" -i"C:/Program Files (x86)/Texas Instruments/ccsv4/tools/compiler/msp430/lib" -i"C:/Program Files (x86)/Texas Instruments/ccsv4/tools/compiler/msp430/include" --reread_libs --rom_model -o "simeon_test.out"  "./tsk_clamp15_enc.obj" "./timer1_enc.obj" "./spi_handler.obj" "./main.obj" "./low_level_initialization.obj" "./io_handler.obj" "./error_handler.obj" "./bildraum.obj" -l"libc.a" "../lnk_msp430f147.cmd" 

error: output file "simeon_test.out" exceeds code size limit
error: errors encountered during linking; "simeon_test.out" not built

>> Compilation failure
gmake: *** [simeon_test.out] Error 1
gmake: Target `all' not remade because of errors.
Build complete for project simeon_test

We rebuild the program with msp430-gcc and -o2 and the program works now. Time to bug the msp430-gcc project!