The msp430x1611 is not an MSP430X processor. That means either the
compiler is creating bad code, or you wrote something in assembler
that uses the wrong bra instruction, or the assembler is miss
interpreting the bra command. Maybe you could add a little insight as
to which this is (i.e. are you assembling it, which I assume you're
not, if not, is the compiler creating valid code.

On Wed, Feb 4, 2009 at 12:08 PM, Hugh Hartwig <[email protected]> wrote:
>
> I am having a similar problem on an MSP430F2618 except my unit resets due to
> a RETA call from within the .text region (non far region).  I will follow up
> shortly with more details.
>
> Hugh
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Monday, February 02, 2009 7:10 AM
> To: GCC for MSP430 - http://mspgcc.sf.net
> Subject: Re: [Mspgcc-users] 430X support branch in cvs repo
>
> Hello Sergey,
>
> thank to your advice I managed to build the mspgcc toolchain with 430X
> support.
> When I built a program using far functions I encountered the following
> Problem (using a MSP430F2617):
> the return from far memory seems not to work properly.
>
> Problem occurrence:
> The function
> "__attribute__((section(".fartext")))void fBlink2000(void)" linked to the
> upper memory (0x10000) is called from the lower memory (0x3296). The
> function itself works properly, but when the RETA instruction is executed,
> the msp430f2617 goes directly to the _cint00_ function (reset).
>
> stack content after calla #0x10000:
> 0x0000 0x329A
>
> stack content after pushm.a:
> 0x0000 0x329a 0x0000 0x205e 0x0000 0x1cf0
>
> stack content after popm.a:
> 0x0000 0x329a 0x0000 0x205e 0x0000 0x0000 0x0001 0x5f8f
>
> disassembly of the calling function:
> ....
> 0x03296:   13B1       0000           CALLA   #0x10000
> 0x0329a:   13B0       32A4           CALLA   #0x032a4
> ....
>
> disassembly of the called function:
> 0x10000:   141B                      PUSHM.A #2,R11
> 0x10002:   4105                      MOV.W   SP,R5
> 0x10004:   5235                      ADD.W   #8,R5
> 0x10006:   8221                      SUB.W   #4,SP
> 0x10008:   4104                      MOV.W   SP,R4
> 0x1000a:   4384       0000           CLR.W   0x0000(R4)
> 0x1000e:   4384       0002           CLR.W   0x0002(R4)
> 0x10012:   40B4       0014 0004      MOV.W   #0x0014,0x0004(R4)
> 0x10018:   9394       0004           CMP.W   #1,0x0004(R4)
> 0x1001c:   3401                      JGE     (Port_1_2_P1IN)
> 0x1001e:   3C14                      JMP     (0x0048)
> 0x10020:   9384       0000           TST.W   0x0000(R4)
> 0x10024:   200C                      JNE     (Port_7_8_PASEL)
> 0x10026:   9384       0002           TST.W   0x0002(R4)
> 0x1002a:   2009                      JNE     (Port_7_8_PASEL)
> 0x1002c:   E2E2       0021           XOR.B   #4,&Port_1_2_P1OUT
> 0x10030:   40B4       5F90 0000      MOV.W   #0x5f90,0x0000(R4)
> 0x10036:   4394       0002           MOV.W   #1,0x0002(R4)
> 0x1003a:   53B4       0004           ADD.W   #-1,0x0004(R4)
> 0x1003e:   53B4       0000           ADD.W   #-1,0x0000(R4)
> 0x10042:   63B4       0002           ADDC.W  #-1,0x0002(R4)
> 0x10046:   3FE8                      JMP     (Port_3_4_P3IN)
> 0x10048:   5031       0006           ADD.W   #0x0006,SP
> 0x1004c:   1614                      POPM.A  #2,R5
> 0x1004e:   0110                      RETA
>
>
> If I edit the stack content before executing the RETA instruction (to 0x329a
> 0x0000 0x.....) the function returns correctly.
>
> Is this a bug?
>
> Best regards,
> Norbert
>
>
> -------- Original-Nachricht --------
>> Datum: Sat, 31 Jan 2009 12:15:03 +0200
>> Von: "Sergey A. Borshch" <[email protected]>
>> An: "GCC for MSP430 - http://mspgcc.sf.net";
> <[email protected]>
>> Betreff: Re: [Mspgcc-users] 430X support branch in cvs repo
>
>> [email protected] wrote:
>> > Hi Sergey,
>> >
>> > I am trying to build the new mspgcc tools. I compiled the binutils and
>> the msp430-gcc with the sources from the repository (new branch).
>> >
>> > My problem now is when I try to compile libc I get the following error
>> during the compile:
>> >
>> > [...]
>> > msp430-gcc -c -I./../include -I. -Wall -O2 -g -mmcu=msp1 -c stdlib/abs.c
>> -o msp1/abs.o
>> seems like you got libc sources from trunk, not from MSP430X branch.
>> try cvs up -r MSP430X
>> > Do you have an idea, why my new msp430-gcc doesn't accept msp1 as
>> argument for mmcu?
>> it doesn't need anymore. See comments in gcc/congig/msp430/t-msp430
>> >
>> > Thanks in advance
>> >
>> >
>> > -------- Original-Nachricht --------
>> >> Datum: Mon, 26 Jan 2009 22:55:48 +0200
>> >> Von: "Sergey A. Borshch" <[email protected]>
>> >> An: "\'GCC for MSP430 - http://mspgcc.sf.net\'"
>> <[email protected]>
>> >> Betreff: [Mspgcc-users] 430X support branch in cvs repo
>> >
>> >> Hi everyone.
>> >>
>> >>   I created branch in mspgcc repository (tag MSP430X_fartext) an
>> submitted
>> >> my additions:
>> >>
>> >>   - calla/reta/bra instructions generated for 430X core
>> >>   - pushm[.a]/popm[.a] instructions in prologues/epilogues for 430X
>> >>   - __attribute__((__far__)) for placing data (const) and functions
>> into
>> >> high memory.
>> >>   - -mdata-64k option for disabling far data support. Now it disables
>> >> attribute((far)) for const
>> >> data, replaces pushm.a/popm.a to pushm.w/popm.w (and movx.a/mova to
>> mov.w,
>> >> pushx.a/popx.a to
>> >> push.w/pop.w in libraries compiled from assembly), in future it should
>> >> generate all 430 data
>> >> processing instructions instead of 430X and reduce pointer size from 32
>> >> bits to 16 bit. Code will
>> >> became faster and smaller, less stack usage in price of no far data and
>> no
>> >> pointers to far functions.
>> >>   - -mcode-64k option for disabling far code support. This option
>> disables
>> >> __attribute__((__far__))
>> >> for functions and generates call/ret/br instead of calla/reta/br.
>> Faster
>> >> and smaller code in price
>> >> of no far functions.
>> >>   - .farrodata section added to 430X ld scripts.
>> >>   - multilib support:
>> >>      * separate libraries for 430/430X cores without hwmul/with
>> HWMUL/with
>> >> HWMUL32 (need to write
>> >> routines for HWMUL32, they are the same as for HWMUL now).
>> >>      * separate lib for 430 cores and -msave-prologues option.
>> >>      * separate libs for 430 cores with HWMUL/HWMUL32 and
>> -mdisable-hwmul
>> >> option
>> >>      * separate lib for 430 cores and -msave-prologues and
>> -mdisable-hwmul
>> >> option
>> >>      * separate libs for 430X cores and all combinations of
>> >> -mdisable-hwmul, -mdata-64k, -mcode-64k
>> >> options
>> >>      * separate libs for 430 cores with CPU4 bug (so mcu's without CPU4
>> >> bug should use more fast and
>> >> short library functions without CPU4 workaround).
>> >>      * 36 library sets in total :)
>> >>
>> >> one disadvantage: improper option (-msave-prologues with 430X mcu or
>> >> -mdata-64k with 430 mcu) leads
>> >> to linking default library (library for 430 mcu without HWMUL). The
>> only
>> >> workarounds I see:
>> >>   1) edit specs file - remove unmeaning options from multilib selection
>> >> lines. Need to write sed(?)
>> >> script. Who helps?
>> >>   2) or build fake default library and remove it after building. This
>> >> leads to unresolved symbols
>> >> and forces user to check options.
>> >>
>> >> -------
>> >>    todo:
>> >>     - full far data support (including 32bits pointers and table jumps
>> in
>> >> far code) - need to
>> >> rewrite almost all msp430.md file.
>> >>     - full HWMUL32 support - need to add 32*16, 32*32, 32*64, 64*64 to
>> >> libgcc.S and calls to msp430.md.
>> >>
>> >>   feedbacks, patches and help are welcome.
>> >>
>> --
>> Regards,
>>     Sergey A. Borshch            mailto: [email protected]
>>        SB ELDI ltd. Riga, Latvia
>>
>>
>>
>> --
>> Regards,
>>     Sergey A. Borshch            mailto: [email protected]
>>       SB ELDI ltd. Riga, Latvia
>>
>>
> ----------------------------------------------------------------------------
> --
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Mspgcc-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
> --
> Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL
> für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
>
> ----------------------------------------------------------------------------
> --
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

Reply via email to