Search the Community
Showing results for tags 'vector'.
Found 2 results
-
Hello, I have a problem with strange behavior of gcc compiler, which does not seem to generate interrupt vectors correctly. I tried to search for hints on the forum, but could not find any helpful information. I have the following C code: void __attribute__((interrupt(TIMER0_A0_VECTOR))) timer0_isr(void) { //IMPORTANT !!!!!!! //Clear TAIV by reading it !!!! (void) TAIV; /* ... */ } void __attribute__((interrupt(TIMER0_A1_VECTOR))) timer0_a1_isr(void) { P1OUT ^= PIN0; } volatile int qq; __attribute__((interrupt(USCIAB0TX_VECTOR))) void usci_tx_isr(void) { qq=1; P1OUT ^= PIN6; IFG2 &= ~UCA0TXIFG; } __attribute__((interrupt(USCIAB0RX_VECTOR))) void usci_rx_isr(void) { qq=2; P1OUT ^= PIN6; if(IFG2 & UCA0RXIFG) { (void) UCA0RXBUF; } IFG2 &= ~UCA0RXIFG; } Only the TIMER0_A0_VECTOR ISR contains meaningful code at the moment, and the other 3 procedures are just placeholders. For some strange reason, the only ISRs which are linked in the executable code to the interrupt vector table are TIMER0_A0_VECTOR and TIMER0_A1_VECTOR: Disassembly of section .vectors: 0000ffe0 <__ivtbl_16>: ffe0: 6c c1 bic.b @r1, r12 ffe2: 6c c1 bic.b @r1, r12 ffe4: 6c c1 bic.b @r1, r12 ffe6: 6c c1 bic.b @r1, r12 ffe8: 6c c1 bic.b @r1, r12 ffea: 6c c1 bic.b @r1, r12 ffec: 78 c4 bic.b @r4+, r8 ffee: 8e c4 6e c4 bic r4, -15250(r14);0xc46e(r14) fff2: b8 c3 6c c1 bic #-1, -16020(r8);r3 As==11, 0xc16c(r8) fff6: 6c c1 bic.b @r1, r12 fff8: 6c c1 bic.b @r1, r12 fffa: 6c c1 bic.b @r1, r12 fffc: 6c c1 bic.b @r1, r12 fffe: 00 c0 bic r0, r0 I must be doing something wrong, but I can't find where is the mistake. Target CPU is MSP430G5553, and here is the information about the compiler: $ ~/.platformio/packages/toolchain-timsp430/bin/msp430-g++ -v Using built-in specs. Reading specs from ~/.platformio/packages/toolchain-timsp430/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/lib/msp430mcu.spec COLLECT_GCC=~/.platformio/packages/toolchain-timsp430/bin/msp430-g++ COLLECT_LTO_WRAPPER=~/.platformio/packages/toolchain-timsp430/bin/../libexec/gcc/msp430/4.6.3/lto-wrapper Target: msp430 Configured with: ../../gcc/configure --enable-languages=c,c++ --disable-nls --target=msp430 --prefix=/home/robertinant/opt/mspgcc_energia --with-pkgversion='MSPGCC 20120406 (With patches: sf3540953 sf3559978)' Thread model: single gcc version 4.6.3 20120301 (mspgcc LTS 20120406 unpatched) (MSPGCC 20120406 (With patches: sf3540953 sf3559978)) Has anybody encountered similar problems? EDIT: Moving void before __attribute__ has no effect.
-
Hey all! Finicky issue, and I've been up for way too many hours so I'm breaking from usual habit and posting after only doing minimal digging. Hopefully it's a simple solution. Fingers crossed. Board: TM4C1294NCPDT IDE: CCSv6.1 OS: Ubuntu 16.04 Compiler: GNU v4.9.3 (Linaro) So here's what's up: I'm versed using timers and setting up my vector table properly, or so I thought. Code Composer Studio isn't finding my interrupt handler... It's confuzzling me to say the least... Here's what I'm doing: In startup_gcc.c //......Skipping top of file for readability, all is stock // External declarations for the interrupt handlers used by the application. extern void Timer1AIntHandler(void); //......Skipping a bunch of nonsense for readabilities sake //Beginning of vector table (NOT Blizzard, but Snowflake/RA0) #else __attribute__ ((section(".isr_vector"))) void (* const g_pfnVectors[])(void) = { (void *)&_estack, // The initial stack pointer ResetISR, // The reset handler NmiSR, // The NMI handler FaultISR, // The hard fault handler IntDefaultHandler, // The MPU fault handler IntDefaultHandler, // The bus fault handler IntDefaultHandler, // The usage fault handler 0, // Reserved 0, // Reserved 0, // Reserved 0, // Reserved IntDefaultHandler, // SVCall handler IntDefaultHandler, // Debug monitor handler 0, // Reserved IntDefaultHandler, // The PendSV handler SysTickIntHandler, // The SysTick handler GPIOAIntHandler, // GPIO Port A GPIOBIntHandler, // GPIO Port B GPIOCIntHandler, // GPIO Port C GPIODIntHandler, // GPIO Port D GPIOEIntHandler, // GPIO Port E UARTStdioIntHandler, // For UARTStdio - UART0 Rx and Tx UARTIntHandler1, // UART1 Rx and Tx IntDefaultHandler, // SSI0 Rx and Tx IntDefaultHandler, // I2C0 Master and Slave IntDefaultHandler, // PWM Fault IntDefaultHandler, // PWM Generator 0 IntDefaultHandler, // PWM Generator 1 IntDefaultHandler, // PWM Generator 2 IntDefaultHandler, // Quadrature Encoder 0 ADC0IntHandler, // ADC Sequence 0 IntDefaultHandler, // ADC Sequence 1 IntDefaultHandler, // ADC Sequence 2 IntDefaultHandler, // ADC Sequence 3 IntDefaultHandler, // Watchdog timer IntDefaultHandler, // Timer 0 subtimer A IntDefaultHandler, // Timer 0 subtimer B Timer1AIntHandler, // Timer 1 subtimer A (Thar she blows...) And then in my main project file: // Only showing relevant pieces... // // Prototypes // ========== // Bunch of skipped out-of-scope stuff... void init_Timer(void); void Timer1AIntHandler(void); void init_Timer(void) { // Enable interrupts to the processor. ROM_IntMasterEnable(); // Enable Timer Peripheral ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER1); // Configure Timer1 to be Periodic, with a 100Hz interrupt ROM_TimerConfigure(TIMER1_BASE, TIMER_CFG_PERIODIC); ROM_TimerLoadSet(TIMER1_BASE, TIMER_A, g_ui32SysClock / 100); // Setup the interrupts for Timer1 timeout. ROM_IntEnable(INT_TIMER1A); ROM_TimerIntEnable(TIMER1_BASE, TIMER_TIMA_TIMEOUT); // Enable Timer1A. ROM_TimerEnable(TIMER1_BASE, TIMER_A); } // void loop() is there somewhere, but it's HUGE, doesn't use the timer anyway. void Timer1AIntHandler(void) { // Clear the timer interrupt. ROM_TimerIntClear(TIMER1_BASE, TIMER_TIMA_TIMEOUT); // Call the FatFs tick timer. disk_timerproc(); } I need the timer for FatFS by ChaN. CCS gives me this on building (skipped everything until the linker output): Sooo what's going on here? Does the Energia part of CCS do something different with the timer section of the vector table? I have a custom ADC0IntHandler which works just fine... If anyone needs more info, I'm more than glad to provide it. Frustrations abound, and it especially sucks 'cuz after a 20 hour coding marathon, a problem like this is just... Awful.
