Jump to content
43oh

AaronInSpace

Members
  • Content Count

    43
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by AaronInSpace

  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?
  15. Hey all. So I'm working on this project and for the last month have been battling the weird bug ever. I will provide as much code as I can which is very little unfortunately. I have a reset problem to put it simply. I have narrowed it down to this bit of code which is intended to repack an array of 16 bit ints with 12 bits of significance so that the 12 bits which are significant are back to back reducing the number of bytes by 25%. The code the way it is will cause resets. Yet, if I add a variable to the function (such as int t) and assign a value to it (so as to make sure it doesn't ge
  16. Well it sounds like you are all saying this should work. I wonder why it won't work for me and my XBee WiFi...maybe a level shifting problem? I just probed my TXD line on the XBee and it is 2.7V or so. Perhaps it doesn't like the 5.5V line levels.
  17. I don't think the MSP430 would be causing any problems at the moment, do you? If its not in peripheral mode, and the lines are set as inputs they would be free to do as they like. I tried putting it in LPM4 anyways as you suggested but no change. On a side note, I just probed the lines and realized TXD and RXD come in 5.5V from the PC....That's odd ain't it? They are reading 5.5V all the time. I thought the MSP430 did 3.3V UART as I am fairly certain the XBee attempts to do since it's powered at around that. Here's a quote from its manual:
  18. Has anyone ever used their LaunchPad as a tool to quickly hook up some external UART module (such as the XBee WiFi) to a PC? I tried just plugging the data out from the XBee to the TXD of the LaunchPad with a MSP430G2553 chip and the following code to disable the MSP430 and allow me to just pass-through: #include void main(void) { // Stop watchdog WDTCTL = WDTPW + WDTHOLD; P1DIR = 0; P2DIR = 0; while (1); } Didn't seem to work though. Any advice or remarks? EDIT: Aw, what the heck. Let's tell you what I'm up to and see if I'm on the right track. So I got an XBee WiFi module bu
  19. Just an update: I went with the XBee WiFi module and a breakout board from SparkFun. Now I just need a camera module capable of 900x500 or so resolution, capable of transmitting 15 fps or so. Since I plan to use a Launchpad, high frequency crystals are out so therefore high speed UART is out. Will have to be an SPI camera. Those seem few and far apart and all high-priced so far. Can anyone think of any other possibilities for a camera?
  20. Well i ordered one yesterday along with a breakout board by sparkfun. Ill be sure to let you know how it went.
  21. Did either of you ever use one of those yet? Anyone used one yet that can comment on it?
  22. I am learning Python in college right now as an experienced programmer. We are using one of the books linked on that list you showed: http://www.greenteapress.com/thinkpytho ... ython.html It's a pretty good book but is a bit basic. Python is pretty darn easy to learn just sitting down and trying with Google at your side. I also use PyQt /PyQwt at work and its pretty neat. A lot easier than Java and Swing in my mind. The development in Python is freaking fast. I'd recommend it.
  23. Thanks Blue. I have that manual and have previously done that procedure half a dozen times but it doesn't seem to work. I apologize for not having mentioned that earlier. I was mostly just checking to see if that is how ESCs are supposed to work in general. Here's my code to do that procedure if your curious: #include #include "common.h" #include "main.h" #include "utility.h" int up = 0; int command_0ccr1; void init_clocks_and_io(void) { // Stop watchdog WDTCTL = WDTPW + WDTHOLD; // Make P1.0 (red led)and P1.6 (green led) an output. SLAU144E p.8-3 P1DIR |= BIT0 + BIT6; // Set clock
  24. Hey Hylian, you may have nailed it. I'm gonna test that now. Yes my code does work as expected as I use it on a servo just fine. I just have problems reliably controlling the ESC. Sometimes it responds (thought not always in the correct direction or speed) but not always. Thanks
×
×
  • Create New...