Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by tripwire

  1. It may be too late to try this, but CCS has a basic file history system which comes in handy when you fix/break something unexpectedly. If you right click on a file in Project Explorer you can select "Compare with->Local History..." That brings up the history tab which lists snapshots of the file by date and time. You can then compare the current file against old versions to see what's changed. If needed you can replace the current file contents with an older version too.
  2. Ok, you've got TAIE set rather than CCIE. That means the TIMER1_A1_VECTOR routine fires when TAIFG is set and not when CCIFG in TA1CCTL0 is set. TAIFG is set when the timer rolls over to zero, which happens every 0x10000 ticks in continuous mode. Try this setup instead: TA1CTL = TASSEL_2 | TACLR; //SM_Clock, Reset Timer TA1CCTL0 = CAP | CM_2 | CCIS_1 | CCIE; //Capture mode, Falling edge trigger, Use CCI1B Input (P2.3) EDIT: By the way, you should probably look into using synchronous capture mode by setting the SCS bit. That will prevent a race condition which can happen whe
  3. I'm assuming you're setting CCIE somewhere else. Are you just using CCIE or do you have TAIE set too? If neither are set then I'm not sure how you're getting into that ISR...
  4. Aha, I see the problem now. I hadn't noticed the lack of TA0.2 output connection on the 20pin 2553 before
  5. Huh? Timer 0 on the G2553 has three CCRs as well. Were you getting compile errors before you changed over to Timer 1?
  6. Also, if you use a capacitor from RESET to GND, make sure it's less than 2.2nF. Any higher and it can interfere with SBW programming.
  7. The 2553 has it too. Thanks for the TLV code! EDIT: I've just been reading the threads oPossum linked and it seems that the 2553 didn't always have temperature calibration values (they were zeroed). Mine does have valid data, so perhaps TI only started calibrating them sometime in the last year or so.
  8. Sorry, I should have been a bit clearer in my last post. If you use the formula I posted it will make your readings even higher - it's based on the calibration values specific to the chip I have here. I was trying to find out whether the conversion formula based on typical values could differ significantly from the calibrated version. On my chip the difference was a couple of degrees at most - not enough to account for the difference you're seeing. Having said that, maybe my chip just happens to produce results that are quite close to the typical ones in the datasheet... Do you have an
  9. I tested out B.Noll's code on my 2553, first with the typical slope/offset values from the linked post and then with the factory-set calibration values. The difference was about 1
  10. It looks like you're not using the temperature sensor calibration values stored in info A on the 2553. I'm not sure if that's sufficient to cause the inaccuracy you're seeing, but it's worth a shot. The calibration values are mentioned in chapter 24 of the MSP430x2xx Family User's Guide and also on page 15 of the 2553 datasheet: The temperature sensor is calibrated using the internal voltage references. At VREF2_5 = 0 and 1, the 12-bit conversion result at 30
  11. It looks like that's the case: "The XT1 oscillator supports ultra-low-current consumption using a 32768-Hz watch crystal in lowfrequency (LF) mode (XTS = 0). The watch crystal connects to XIN and XOUT and requires external capacitors on both terminals. These capacitors should be sized according to the crystal or resonator specifications." Having said that, I'd be surprised if TI supplied the board with a suitable crystal but no capacitors to match*. Check the board itself and make sure those DNPs aren't just an error on the schematic. You might also need to look at the XT1DRIVE setting
  12. Those capacitors aren't actually present on the board. The letters "DNP" alongside them mean "Do Not Populate". The oscillator circuit inside the MSP430 includes software-selectable load capacitors. You'll need to check that you've got the appropriate XCAP (or equivalent) bits set for the supplied crystal.
  13. It took me a while to figure that command line out, and it turns out to be the source of the problem. The command you're using is: set /p x="255" <nul >//./COM5 Apart from the redirections, the command is setting the value of environment variable "x" to a value provided by the user, and showing "255" as a prompt. The input is redirected from nul so the command doesn't wait for user input. The output is redirected to the COM5 port. Crikey! It looks like a roundabout way of printing the string "255" to the COM5 port. What that means is the UART first receives the character '2',
  14. No, the array is arranged like this: GIMP array layout for a 4x4 pixel image. Pixel coordinates are shown as (X,Y). 0 1 2 3 4 5 ... R G B R G B R G B R G B R G B R G B R G B R G B R G B R G B R G B R G B R G B R G B R G B R G B 0 | \_/ \_/ | | \_/ \_/ | | | | | | | | | | | | | | | | | | \_ Null terminator | (1,0) (2,0) | | (1,1) (2,1) | | | | | | | | | |
  15. Ooops, I hadn't noticed that you're using TASSEL_1 (aka ACLK) as the timer source! ACLK is sourced from the LF crystal oscillator by default. Ike's post above includes the (quite bewildering ) lines: static int MAGIC_8MHz = ' '; ... BCSCTL3 = MAGIC_8MHz; Which are equivalent to: BCSCTL3 = LFXT1S_2; // ' ' == 0x20 == LFXT1S_2 That changes ACLK to be sourced from the VLO instead of the crystal oscillator. If that change fixes the problem, then the crystal is failing to start up correctly when you're running without the debugger attached. It's worth taking a look at this threa
  16. I think you'd need the overflow interrupt to fire when TA0R rolls over. The CCR0 interrupt would only fire when the capture occurs. That means you'd need to be extra-careful of interrupt priorities, since the capture interrupt could happen at the same time as the TA0R interrupt. In that case the CCR0 interrupt would be processed first, and then the count would be off by 65535. BTW, I haven't tried any of this so I might be wrong
  17. Apologies for drifting way off topic, but 16-bit 5-6-5 format came into use a little later than that. It was used in the early days of the PC's transition to 3D hardware rendering, as well as on consoles a generation or two ago (eg PSP). C64 and Amiga used indexed colour screen modes, where each pixel stored an index into a colour look-up table (aka palette).
  18. Hi, I don't know anything about UART, but I can help explain the syntax used by GIMP for that image array. Each row of the image corresponds to one of the strings. The strings contain escape sequences that encode the RGB components of each pixel in the row as literal byte values. Since there are no commas between the strings they get concatenated into one big string by the preprocessor. The result is that bytes_to_send is a linear array with three bytes for each pixel, and the rows are placed together one after another. The red component of the pixel at (7, 2) should be at bytes_to_sen
  19. Have you tried using the timerA "toggle output mode" to flash the LED instead of code in an ISR? The ISR processing latency for TIMER0_A0_VECTOR is 11 cycles, and you're toggling the LED with an XOR instruction which takes 5 cycles. That means it takes at least 32 MCLK cycles for a complete on/off cycle of the LED. The LED would be flashing at a maximum frequency of 500kHz if the MCLK was at 16MHz*. Using the timer's output mode you'd be able to toggle the LED every 2 MCLK cycles for a flash frequency of 4MHz. That only works for fixed patterns like square waves and PWM, though. By the
  20. As far as I know, problems with moisture ingress only apply to reflow soldering. In a reflow oven the whole component is brought up to soldering temperature. To avoid damage to the component body the moisture level and oven temperature profile need to be carefully controlled. When you're hand soldering there might be some heat conducted from the leads to the case, but not enough to bring the whole component up to about 230 degrees C.
  21. I took a look at the USB socket on my launchpad (V1.5). The two pads at the back of the socket are similar to yours, with the feet partially embedded in a thin layer of solder. The front ones, however, are completely hidden under huge solder fillets that rise almost half-way up the sides of the socket. I don't think it could have been done by reflow, so perhaps they've got people with soldering irons on the production line to fix up the sockets
  22. I don't know if you spotted my sneaky edit, but I added some extra info after I made my previous post. Before you resolder the crystal it's worth searching the forum for "crystal fault". There are quite a few posts about different things that can cause the crystal to misbehave.
  23. Hmm, that was unexpected... I've modified the test code to just flash the green LED while the oscillator fault flag is set. The red LED now continues to flash at whatever rate is produced by the timer (even during a fault). crystal.c It would be good if you'd try the new code and see what happens. I'm hoping that the green LED will flash rapidly from the moment you run the code, and the red LED will flash every second (approx) with the debugger attached and slower after you terminate debugging. If you get the expected result then it suggests the crystal is in a rather sensitiv
  24. The oscillator fault just indicates that the crystal oscillation frequency is less than 10kHz. This confirms that the crystal is actually outputting the wrong frequency, rather than something going wrong further down the line inside the 430. To be clear, when do you get the fault? After terminating debug or immediately upon starting the program?
  25. During debugging the TST and RST lines of the MCU are used for JTAG communication. They happen to be near the XIN/XOUT pins for the crystal, so perhaps there could be some interference or a short there. Also, remember how the reset button doesn't work when running in the debugger? That's because the RST line is in use. You can get the debugger to temporarily detach from the target MCU by pausing execution, then selecting "Free Run" from the Run menu. After that the reset button will work normally. You should give that a try and see whether selecting Free Run and then pressing the reset but
  • Create New...