Jump to content
43oh

smiffy

Members
  • Content Count

    34
  • Joined

  • Last visited

  1. Thank you. I had wondered about some sort of compensation mechanism. If I work out when the errors become significant, I can have another, slow, counter that can pull the numbers like that.
  2. Very good question. I can't actually remember why that specific part was chosen, but the criterion which turned it up was being able to take a crystal that ran at my desired frequency - where the G-series ones seemed to be geared up to 32kHz and nothing more. I actually made a bit of a mess of my re-calculations as the bit of Perl that I wrote to do them had been modified so many times, with so many different parameters put in - so I'm not *entirely* sure that a crystal-accurate 32kHz clock will get the desired resolution. In test mode, it's fine - that being running at the speed of a "no
  3. That's very interesting to hear. Whilst I only did a quick (and aborted) test with IAR, all my tests have been done whilst connected with mspdebug - I haven't had the board disconnected from the debug system. Whilst it's different debug software on the computer end, it's still going through the TI debugger hardware (LaunchPad, in my case.) I'm still not going to pursue this any further at present, as using a G-series is more attractive from a power consumption point of view. However, I will certainly bear this in mind for future testing and make sure that everything is tested with NO conne
  4. Conclusion I have routed the calibrated DCO to SMCLK to the appropriate external pin - absolute garbage (wildly fluctuating frequencies) showing on the frequency counter. As my R&D time is constrained to time not booked by clients (ie: when I'm not doing my Day Job,) I'm cutting my losses and am going to write off the AFE253 as far as this project is concerned. Toolchain support of the part is lacking in the gcc/libc version I have (I've had to copy in a few bits from the TI-provided header file so far) and suspect even in Uniarch, as Gordon's binary didn't work, so I really don't want
  5. IAR was a nightmare. I got the code modified and compiling (all the time peering at the non-resizeable editor window) but it was having worse problems talking to the LaunchPad than mspdebug. Gave up. I hate GUI development environments. I want mind-bleach. Since my problem appears to be with interrupts, and I'm diverting elsewhere - trying to see if the first parts of the process are working: will the XO run, will it feed SMCLK? Trawling the datasheets trying to find the control that allows me to output SMCLK on P1.0. Once I find that, I can stick a scope/frequency counter on the breakout
  6. I'm currently working with VLFO -> ACLK -> Timer_A, so have added the | TAIE in the appropriate place, still nothing. I have hacked msp430x20x2.h, which I'm assuming is the one being used when gcc is invoked with the -mmcu=msp430x2012 CFLAG, changing the vector offsets to correspond with the AFE datasheet. STILL nothing. I can only think that the next thing to do will be to remove the entire build toolchain from the equation and try it with IAR. Just got to find some example code to see how they do their ISRs. Sure there must be some on this forum! Still a bit concerned about thi
  7. Timer Interrupt Vectors MSP430AFE253 Timer_A3 TA0CCR1 CCIFG - 0x0FFEC Timer_A3 TA0CCR2 CCIFG, TA0CTL TAIFG - 0x0FFEA MSP430G2211 Timer_A2 TACCR0 CCIFG - 0x0FFF2 Timer_A2 TACCR1 CCIFG, TAIFG - 0x0FFF0 So they ARE different. The vectors used by the G part correspond to USART0 receive and USART0 transmit correspondingly, on the AFE part. But that doesn't explain why Uniarch building for the specific part doesn't work (unless there's a bug in there.)
  8. Thanks. LED never turns on. So - I guess if you've built against the specific part, that tends to eliminate the interrupt vectors. (I'll still check the datasheets, just to satisfy my curiosity.) I've got a nasty feeling that I'm going to have to do something unpleasant - either fire up a Windows VM, chuck IAR on there and test an IAR-ified version on there or possibly try to write the whole thing in assembly. Also wondering whether I should assemble a second board (I have one more part to hand) and test that. But I really can't see this as being a likely failure mode for a faulty part
  9. Oops. Corrected, ta. Not that it makes any difference at the moment. I've just popped the code that's working on the G series onto the AFE and, no, it doesn't work. Think I've eliminated incorrect peripheral control register addresses though - they're stated in SLAU155(h) - which covers all parts concerned. (The only difference I can see in any of the parts is that LFXT1OF is low at PUC.) However, maybe oPossum was on the right track asking if I'd used the right interrupt. Well, it works on one device, but not another. Whilst the peripheral control registers are all in the same lo
  10. Think I've got the right one at least on the G series - I've got the G series device working by changing the timer to use ACLK and ACLK to run off the VLO. (The same changes don't work on the AFE device.) I want to get the LaunchPad device working off the DCO next to see where the break in the process is (works with ACLK/VLO, not SMCLK/DCO.) Think I'll leave that for the morning when I'm feeling a little more fresh - I'll go write some Verilog now. It seems an absolute doddle after wrangling recalcitrant peripherals
  11. I just modified the code (reverse the on/off of the LED and changed the LED pin) to run on another LaunchPad loaded with an MSP430G2211. Same story - ISR isn't getting invoked. Maybe it's time to stop using macros and start setting registers by the numeric addresses from the datasheets.
  12. Let's try eliminating the crystal oscillator from the equation and use the DCO instead. Putting my code aside for the moment, I have modified the simple example given to feed SMCLK from the DCO, feed the timer from SMCLK (so I'm still going via SMCLK, but with a totally internal clock source.) LED is initialised OFF, ISR turns it ON. This should mean that everything is happening internally, no external hardware is getting involved. #include #include interrupt (TIMERA0_VECTOR) t_isr(void) { /* Turn on LED. */ P1OUT &=~ BIT6; } int main(void) { /* Watchdog off. */ WDTCTL = WDTP
  13. Oh, yes, I did that earlier - I set the test LED to turn on after the XO stabilised loop - it did. (After a scarcely perceptible delay.)
  14. Thanks. I'll test the minimal example tomorrow. Tomorrow I'll also stop being lazy, walk the two metres to the other side of my office, plug onto a battery pack and put the crystal test point to my scope and frequency counter! If hardware issues possible, test the hardware way...
  15. Well, nothing happened. This is my clock/timer setup code: void init_timer(void) { unsigned int i=0; /* Crystal oscillator ON. */ BCSCTL1&=~XT2OFF; /* XTS commented out: "This bit is reserved in the MSP430AFE2xx devices."*/ /* BCSCTL1|=XTS; */ /* This is a 1-3MHz crystal. */ BCSCTL3|=XT2S_1+LFXT1S_1; /* Wait for XO to stabilise. */ do { IFG1 &= ~OFIFG; for (i = 0xFFF; i > 0; i--); } while (IFG1 & OFIFG); /* SMCLK runs off XO. */ BCSCTL2|=SELS; /* Clear timer. */ TACTL|=TACLR; /* SMCLK UP /8 */ TACTL=TASSEL_2 + MC_1 + I
×
×
  • Create New...