The vectors are not part of the crt0 archive, but are linked in at the
same time using the same general infrastructure. There is a separate
vector object file for each vector size (16, 32, and 64 element),
while the selection of which crt0 archive to use depends on MCU
characteristics.
Peter
On Thu, Sep 27, 2012 at 3:49 PM, Stephen R Phillips
<cyberman_phill...@yahoo.com> wrote:
> Changed
> -mmcu=msp430F5172
> to
> -mmcu=msp430f5172
>
> Fixed QED
> Ugh that is a bit of an annoying one I got caught by (sigh).
>
> It appears to compile.
>
> However I am confused about the vectors
> -----------------------------------------------
> .vectors 0x0000ff80 0x80
> 0x0000ff80 PROVIDE (__vectors_start, .)
> *(.vectors*)
> .vectors 0x0000ff80 0x80
> c:/msp430gcc/bin/../lib/gcc/msp430/4.6.3/mcpu-430x/mmpy-16/crt0ivtbl64.o
> 0x0000ff80 __ivtbl_64
> 0x00010000 _vectors_end = .
> -----------------------------------------------
>
> It took me a while to hunt down __isr_52
> -----------------------------------------------
> .text.cpu_clk_reset
> 0x00008bf0 0xa obj\Debug\source\isr.o
> 0x00008bf0 cpu_clk_reset
> .text.timer_a0_0_isr
> 0x00008bfa 0x34 obj\Debug\source\isr.o
> 0x00008bfa __isr_52
> 0x00008bfa timer_a0_0_isr
> .text.timer_a0_1_isr
> 0x00008c2e 0x38 obj\Debug\source\isr.o
> 0x00008c2e timer_a0_1_isr
> 0x00008c2e __isr_51
> .text.serial_port_isr
> 0x00008c66 0x64 obj\Debug\source\isr.o
> 0x00008c66 __isr_55
> 0x00008c66 serial_port_isr
> -----------------------------------------------
> it looks as though I had success.
>
> The map file is a bit confusing because it 'looks' as though the vectors
> are part of crt0 (which would be a bit troublesome). It appears it maps
> it too some instruction (likely reti)
>
>
>
> ----- Original Message -----
> From: Peter Bigot <big...@acm.org>
> To: Stephen R Phillips <cyberman_phill...@yahoo.com>
> Cc: "Mspgcc-users@lists.sourceforge.net" <Mspgcc-users@lists.sourceforge.net>
> Sent: Thursday, September 27, 2012 12:38 PM
> Subject: Re: [Mspgcc-users] mspgcc complains about my isr vectors (a little
> patience and assistance would be a appreciated)
>
> My mistake: I fat-fingered msp430F5127 during my test, which does not
> exist. <msp430.h> would not diagnose the MCU case problem given an
> otherwise valid MCU name, because it's one of the few things that
> actually does manipulate the MCU flag (converts it to upper-case for
> the C preprocessor flag that's provided).
>
> The rest of the toolchain still requires msp430f5172 (lower-case) to
> detect the target MCU and select the appropriate features such as
> length of the interrupt vector and the linker script.
>
> Peter
>
> On Thu, Sep 27, 2012 at 7:21 AM, Peter Bigot <big...@acm.org> wrote:
>> One of the reasons to include <msp430.h> instead of device-specific
>> headers is you would get a diagnostic clue that msp430F5172 is not a
>> recognized MCU. MCU identifiers are all lower-case, and are
>> case-sensitive. The toolchain you're using is probably one that still
>> uses the msp430f110 as the default MCU, and that part has a 16-element
>> vector table, explaining both the warning from the compiler and the
>> size of the .vectors section in the result.
>>
>> Use -mmcu=msp430f5172.
>>
>> I don't know whether -nocrt0 has any effect with mspgcc, as
>> eliminating the C runtime support is a pretty advanced technique that
>> requires something replace it. If you really want to eliminate
>> reference to it, you'll probably have to invoke msp430-ld directly,
>> providing the pieces you need
>> and excluding the ones you don't. Use "msp430-gcc -v" to get a
>> verbose sequence of the steps including the invocation of msp430-ld so
>> you can see what you need to review/remove.
>>
>> Peter
>>
>> On Wed, Sep 26, 2012 at 10:43 PM, Stephen R Phillips
>> <cyberman_phill...@yahoo.com> wrote:
>>> I received complaints about vectors for ISR's so I though I would post some
>>> more fun stuff
>>>
>>>
> this is my cli (per command line) I purposefully didn't NOT want CRT0
> in there (yet it was forced in later oh well one thing at a time).
>>>
>>>
>>> --------------------------------------
>>>
>>> msp430-gcc.exe -nocrt0 -save-temps -mmcu=msp430F5172 -Wa,-alnhs=f.s
>>> -fdata-sections -ffunction-sections -Iheaders -c source\isr.c -o
>>> obj\Debug\source\isr.o
>>> --------------------------------------
>>>
>>>
>>> When I used this code
>>> --------------------------------------
>>> #define T0_A0_VEC (TIMER0_A0_VECTOR - 32)
>>> // 2 keys (emulated) int3 and int5 (I think)
>>> // timer 0 CCR0 is used for 1 second timing
>>> #pragma vector=TIMER0_A0_VECTOR
>>> //#pragma vector=T0_A0_VEC
>>> __interrupt void timer_a0_0_isr(void)
>>> {
>>> // delay for 10ms
>>> TA0CCR0 += CLK32K;
>>> // set the second flag
>>> sec_flag = true;
>>> // maintenance numbers
>>> ++runtime;
>>> #ifdef PUMP_OPERATION_TIME_
>>> // these counters automatically update
>>> // if the output is on
>>> // if ZERO GAS ON
>>> if(ZERO)
>>> { // increment pump 1 on time
>>> ++pump1_time;
>>> }
>>> // if CAL GAS 1 ON
>>> if(CALGAS1)
>>> { // increment pump 2 on time
>>> ++pump2_time;
>>> }
>>> // if CAL GAS 2 ON
>>> if(CALGAS2)
>>> { // increment pump 3 on time
>>> ++pump3_time;
>>> }
>>> #endif //PUMP_OPERATION_TIME
>>> }
>>>
>>> #define T0_A1_VEC (TIMER0_A1_VECTOR - 32)
>>>
>>> // timer 0 CCR 1 etc are used for 10ms tick .. ?
>>> #pragma vector=TIMER0_A1_VECTOR
>>> //#pragma vector=T0_A1_VEC
>>> __interrupt void timer_a0_1_isr(void)
>>> {
>>> switch(TA0IV)
>>> {
>>> case 2: // A0 CCR1
>>> // repeat in 10ms
>>> TA0CCR1 += (CLK32K/100);
>>> // set flag to indicate trip
>>> msec_flag = true;
>>> break;
>>> case 4: // A0 CCR2
>>> break;
>>> case 10: // TAR overflow
>>> break;
>>> }
>>> }
>>>
>>> #define USCI_A0_VEC (USCI_A0_VECTOR -32)
>>>
>>> #pragma vector=USCI_A0_VECTOR
>>> //#pragma vector=USCI_A0_VEC
>>> __interrupt void serial_port_isr(void)
>>> {
>>> // if we have a receive interrupt
>>> if(UCA0IFG & UCRXIFG)
>>> {
>>> // clear the flag
>>> UCA0IFG &= ~UCRXIFG;
>>> // read data from the serial port
>>> // add the data to the receive buffer
>>> serial_buffer_insert(&serial_port_1_in, UCA0RXBUF);
>>> }
>>> // if we have a transmit interrupt
>>> if(UCA0IFG & UCTXIFG)
>>> {
>>> // clear the flag
>>> UCA0IFG &= ~UCTXIFG;
>>> // if we have data to transmit
>>> if(serial_port_1_out.size)
>>> { // read data from the buffer and transmit it
>>> UCA0TXBUF = serial_buffer_remove(&serial_port_1_out);
>>> }
>>> }
>>> }
>>> --------------------------------------
>>> I received this complaint
>>> --------------------------------------
>>> source\isr.c: In function 'timer_a0_0_isr':
>>> source\isr.c:662:37: error: interrupt vector 52 is beyond end of MCU
>>> vector table
>>> --------------------------------------
>>>
>>> So I looked at my map file
>>> --------------------------------------
>>> Memory Configuration
>>>
>>> Name Origin Length Attributes
>>> sfr 0x00000000 0x00000010
>>> peripheral_8bit 0x00000010 0x000000f0
>>> peripheral_16bit 0x00000100 0x00000100
>>> bsl 0x00001000 0x00000800
>>> infomem 0x00001800 0x00000200
>>> infod 0x00001800 0x00000080
>>> infoc 0x00001880 0x00000080
>>> infob 0x00001900 0x00000080
>>> infoa 0x00001980 0x00000080
>>> ram 0x00001c00 0x00000800 xw
>>> rom 0x00008000 0x00007f80 xr
>>> vectors 0x0000ff80 0x00000080
>>> ram2 0x00000000 0x00000000 xw
>>> ram_mirror 0x00000000 0x00000000 xw
>>> usbram 0x00000000 0x00000000 xw
>>> far_rom 0x00000000 0x00000000
>>> *default* 0x00000000 0xffffffff
>>>
>>> .vectors 0x0000ff80 0x20
>>> 0x0000ff80
>>> PROVIDE (__vectors_start, .) *(.vectors*)
>>> .vectors 0x0000ff80 0x20
>>> c:/msp430gcc/bin/../lib/gcc/msp430/4.6.3/crt0ivtbl16.o
>>> 0x0000ff80 __ivtbl_16
>>> 0x0000ffa0 _vectors_end = .
>>>
>>> ------------------------------------
>>>
> So the .vectors seemed too me to be quite strange (16) and not span the
> right area. Could that be what the compilor was complaining about? Also
> I noticed that crt0 was STILL included for some reason. It's probably
> because I need to use the -nocrt0 option with the linker not with the
> normal compile stage (duh?)
>>>
>>> Ideas and or suggestions for putting the ISR's in the correct vector
>>> location quite welcome :D
>>>
>>> Stephen
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>> _______________________________________________
>>> 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://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> 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://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
