Jump to content
43oh

AaronInSpace

Members
  • Content Count

    43
  • Joined

  • Last visited

  • Days Won

    1

AaronInSpace last won the day on October 2 2011

AaronInSpace had the most liked content!

About AaronInSpace

  • Rank
    Advanced Member
  1. Good catch. Pardon me! It is in fact pin 8 (XIN) which the oscillator is attached to with these issues. I keep getting mixed up on that point since you can imagine XIN being the input to the crystal (WHICH IT IS NOT!) Still limping along. Anyone notice anything else?
  2. I appologize for the lack of commenting on those lines. I was worried that my IDE was doing weird things with bit logic and so just assigned values instead of ORing in constants. I'll explain my expectations of what I have set in the registers. # This sets XT2OFF to 1 making sure XT2 is not running. The "7" sets RSELx to 7 which is a range select for the DCO BCSCTL1 = 0x87 | XTS; // Default reset + // XTS = high-freq mode # This sets MCLK to DCOCLK with a divider of 1, sets SMCLK to DCOCLK with a divider of 1 and sets the DCO resistor to internal BCSCTL2 = 0x00; // Default reset
  3. I've been working on a high-altitude balloon for the last couple months. It is controlled by an MSP430-F2619. I wish I had a schematic to show you but I didn't make one and its complicated enough now that I'd rather just float this question out there without one and if we can't say without seeing them, oh well. So, here it goes! There is a 5 MHz digital oscillator driving LFXT1 through XOUT (pin 9 on the 64-pin PM package). Here's my clock and initialization code: void init_clocks_and_io(void) { volatile u32 i; WDTCTL = WDTPW + WDTHOLD; // Stop WDT // Set all unused pins to output
  4. Those sound like some good questions but I'm too much of an EE noob to answer them. I'll ask my EE guy to help me answer those questions. What I can say at my level of understanding is we have two capacitors with "22" etched on them going to ground. One on the XTAL input and one on output. Circuits I've seen on other TI products call for 12 but I guess that depends on the crystal (mine is soldered in pretty good so that I can't see its name but I guess we'll have to tear that out and inspect it)?
  5. Thanks for your suggestions. I'm too busy at the moment to get into this problem for another week or so but I can say that I have tried what you suggested (scoping the clock lines) and that is where I observed the strange phenomenon I have been observing. They look great until the problem starts creeping up an hour or so into run time. I also observed last run that leaving the JTAG unplugged from my system causes I2C timeouts, but keeps the MCLK from crashing and the oscillator from faulting! So that leads me to think it's a power delivery issue or a problem with the JTAG. Anyways, I plan to r
  6. So you wouldn't think the crystal could be to blame? I should have said earlier that when the crystal faults, the DCO takes over for MCLK until the crystal stops faulting at which time it should switch back to the crystal. The fact that the signal becomes unclean before the freezeup is what lead me to believe that the crystal was faulting. If it were easy to swap out the MSP430 I would certainly try that right away like you suggested but its in a moderately complicated system soldered in. Before I spend the day doing that I'm just hoping to hear why you lean towards the MCU instead of the crys
  7. So I've found with some more testing that when the UART stops spitting out but my other continues, the MCLK appears corrupted before it completely freezes up. It looks as if it is switching between crystals very quickly. The signal isn't constant or clean. It might be a fault on my crystal, right? That was a problem I had the last few days which I thought I had fixed by replacing some wiring on the JTAG part of my board which looked nasty. What would happen is the DVcc would drop to 2.7V or so and the AVcc would stay at 3.4V. Then OFIFG would flag often as I could tell by flipping an LED on th
  8. I just realized that the UART (driven off SMCLK) stopped outputting about 5 minutes before the crash happened on the last run. I can tell this because I have another output which continued to output timestamped data 5 minutes longer. I couldn't get the UART output coming in on my PC again until I restarted the MCU.
  9. Hey all. Working out a bug right now I'm hoping for some help with. I have an MSP430F2619 on a project which freezes up occasionally. The WDT is off and no LPM is implemented. When it freezes, my crystal remains active, as does SMCLK which is driven off of it, but my MCLK, which is also driven off of it, stops oscillating and just idles high while the MCU remains unresponsive. My Vcc is 3.4V and my xtal is LFXTAL1 on HFXT mode at 5 MHz. As for what is happening in code, nothing unusual. Just running through a state machine which runs a task every 15 seconds and another every 3 seconds. Doe
  10. Sorry to take so long to get back here! I blame the holiday. That and that I've been busy on other projects since last post. I appreciate you taking the time out to run my algorithm on your PC. Thanks for the results and optimizations! I'll be sure to let you know if I see anything in the listing when I get to doing that.
  11. Ha! Good man. Thanks. I forgot to mention the WDT is off. No lpm either atm. As for interrupts they can likely be ruled out as the cause as this is 100% repeatable at the same spot in code regardless of when I invoke this call. I can't debug because my RTOS conflicts with debugging. The problems are not averted by moving the call around. Simply having the assignment in the function anywhere fixes the issue which is why I'm so confident its a stack issue. As for my experience level: low. Thanks for your ideas. Should have answered those in the original post.
  12. Thats all the code I can post unfortunately as I was saying. That is the full function in question though. As for the mcu sorry! Its an MSP430F1612.
  13. Update: this thing is stuck up with the WiFi module not working. Still working on getting simple UART to work to the device. No response from it from either my FTDI or straight through the LaunchPad's USB.
  14. Here's how its going: poorly. I can not for the life of me communicate with the module. I'm honestly not sure its working. I didn't buy the dev board but I can't get UART working through it. I'm starting to think cheaping out and not buying the dev board was a horrible idea. Anyone have any experience with this thing yet?
×
×
  • Create New...