piranha32

Ah, thanks! Stupid formatting. That explains the mystery. I checked addresses for a couple of vectors, but I missed those in between. The fifth one is the default power up vector, so I'm not concerned about it.

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.

I've just discovered this forum, but I've got two boards from preorder . May I ask for the EA award?

I'd like to say that I really appreciate your help. I realize that the project is new and I don't expect it to be completely flawless. It's really important that there is a place where problems can be reported and that they are solved quickly. I found the forum through a link to a code snippet posted in a discussion on TI forums or buried somewhere in TI wiki (I don't remember). It think it would be worth to give it a little bit more publicity. regards, j.

The project I'd like build using the launchpad is a digital rlc meter. The c2k family has two features which make it ideally suited for such job: dual channel simultaneous sampling AD converter and lots of computational power. The simultaneous sampling is important in measuring the phase shift between voltage and current. An A/D with sequential sampling would make the job much more difficult. Many such projects just look at the min/max sample values to determine the amplitude of the measured voltages and look for zero-crossing to estimate the phase. While simple to implement, such methods require high degree of oversampling to be accurate. I want to fit sinusoidal functions to the measured values and use them to estimate the parameters of the voltages and current. It requires solving of several non-linear optimization problems, but can work well with only 4-5 samples per period. That's where the high MIPS power comes in handy. I have a working proof-of-concept implementation in octave, now I need to implement it on the microcontroller. I'll keep you posted on the status of the project, but don't hold your breath. It may take a while

http://focus.ti.com/...l?sku=OLT212010 has almost everything you need to know about to start coding for C2k. It's tailored for 28069, but with small modification should be also applicable to 28027.

Trey, thanks for the hint about adding CLK_enableTbClockSync. I was going to post a question about AdcSoc example, but this thread solved my problem.

Hi! I'd like to say hello to everybody on the forum. I've got launchpad a couple of weeks ago and, time permitting, I'm playing with it. It's not my first encounter with C2k family. I have a Piccolo Control Stick which I bought about a year ago from a promotion on tideals, but I've never had time to really sit down and start using it. Even though I worked with many different microprocessors and I'm no stranger to writing my own startup files, I felt intimidated by the amount magic that had to be done to just make an LED blink. Since i was going to use the controlstick only for my hobby projects and I've always had other projects promising faster results, the stick was sitting on a shelf collecting dust. I got back to it several weeks ago, after I found a series of videos guiding through the mysterious beginnings of development for C2k. I've also got a Lanuchpad XL and with its driverlib software development started to look like a piece of cake. I already found the forum very helpful and I think I will be visiting it regularly Regards, Jacek