KatiePier

Members
  • Content count

    42
  • Joined

  • Last visited

  • Days Won

    3

KatiePier last won the day on August 1 2015

KatiePier had the most liked content!

About KatiePier

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    http://e2e.ti.com/members/1555997/default.aspx

Profile Information

  • Gender
    Female
  1. Glad to see that my gift made it overseas! :-)
  2. Mine came in, but unsure who my Santa was because Amazon conveniently lost the shipping receipt! :-) My photo didn't look nice so here is a better one: Very fun game! It's a word-association party game. Anomia is the word for when you cannot think of the word for something, and that basically is how the game goes. We played with some friends we had in town this weekend and had a blast. Thank you Santa! :-D -Katie
  3. In addition to @@oPossum 's awesome advice, the final point that always confuses people is that each Timer has TWO different ISRs. One (TIMER0_A0_VECTOR) is a special higher priority one just for TA0CCR0, and its interrupt flag is cleared automatically by entering the ISR at all. The other one (TIMER0_A1_VECTOR) is for all of the other TA0CCRx interrupts and TAIE - this is the one that uses TAIV - its highest-priority pending flag is cleared by reading TAIV. This code example uses both of them, so you can see: http://dev.ti.com/tirex/#/?link=MSPWare%2FDevices%2FMSP430%2FMSP430G2XX%2FMSP430G2553%2FExamples%2FC%2Fmsp430g2xx3_ta_07.c It's a common point that trips people up. If you currently have no ISR defined for TIMER0_A1_VECTOR but have TAIE enabled, if you use CCS for example it defines a trap ISR for all undefined ISRs for just this case (so part doesn't jump off into some random location), so your part is probably hanging out there.
  4. Hi @@MSPLife, @@enl's summary above is spot on. One or two more additions about BSL - with the BSL password protection, as @@enl mentioned you cannot read out the part unless you provide the correct 32-byte BSL password. Now, if you provide an incorrect password, the part will do a mass erase which should get rid of the code in the part - that is to try to help against someone brute-forcing your password. After your code is erased, there's not anything for them to read anymore of value. This should all be described in www.ti.com/lit/pdf/slau319 The other point I wanted to make was, that only some parts in the G2xx family have a BSL in hardware - G2xx3/4/5 do, but the earlier G2xx1/2 don't I believe. Make sure to check your device datasheet if you want to use BSL. If you still need to do firmware updates, but also want to blow the JTAG fuse on a G2xx1/2 that does not have BSL, you could look into doing a main/info memory bootloader like discussed in the MSP-BOOT app note SLAA600, or potentially the tiny G2xx loader mentioned at the end of SLAA450. But as @@enl and others have mentioned, there's not one way to make sure you are 100% safe if someone really has the resources time and motivation trying to break in with some fancy tools - this is true of any IC. But you do what you can to make it harder for someone to do it - it's like locking the door on your car. Regards, Katie
  5. Hi @@nickn, Looks like you are using driverlib function calls - great! It is recommended to use the PMM_setVCore() function call from driverlib for setting the Vcore level before you change the clock - this has the most recent implementation of what @@fatihinanc showed you in their code. This will do all the single stepping of the core and required checks for you. For using the UCS functions you mentioned - are you using CCS? If you have CCSv6 with MSP430ware, go to View > Resource Explorer and you can see in MSP430ware under Libraries there is Driver Library, and there should be examples here for all the different driver library functions. I remember there is even one specifically for setting the DCO to a desired frequency on F5xx: in Resource Explorer, MSP430ware > Libraries > Driver Library > MSP430F5xx_6xx > Example Projects > UCS > ucs_ex1_DCO12MHz. If you have questions about how a particular driverlib function call works, you can find documentation built into Resource Explorer under MSP430ware > Libraries > Driver Library > MSP430F5xx_6xx > API Programmer's Guide. This is html-based documentation - you can click Modules to get a list of all the modules in the device family, click on one of them (like ucs) and it will give you a list of all the function calls for that module. Click on a function call, like UCS_initFLLSettle, and it has a full description and a list of all the parameters that you pass to it. MSP430ware also has some blank driverlib projects that you can use as a starting place. Let me know if you have any more driverlib questions! I like to help people out with these libraries. Regards, Katie
  6. There's also this app note here: www.ti.com/lit/pdf/slaa513 (Note that it will soon be updated though because of this E2E thread: e2e.ti.com/support/microcontrollers/msp430/f/166/p/403099/1428736#1428736 - so make note. I think this issue shouldn't matter on G2211 though because of its limited pin and timer options) -Katie
  7. @@Optronik, See the datasheet www.ti.com/lit/gpn/msp430g2553 p. 30. You'll see under Test Conditions that the calibration is done at 30C and 3V. The spec to the right then specs what tolerance you'll get off of this 30C/3V calibrated frequency when you use it across the full 0-85C at 3V, or across 1.8-3.6V at 30C, and across both -40-85C and 1.8-3.6V. -Katie
  8. Hi @@Optronik, Just a note - Your mention earlier about using 32kHz with FLL to help set the DCO is actually what is done on some of the other newer MSP430 device families. You may want to take a look at the MSP430FR2033 for example (its big brother with LCD is also found on MSP-EXP430FR4133 Launchpad). This device uses the external crystal as an input to an FLL with the DCO to constantly keep tuning and adjusting the DCO to a specific frequency. Something similar is also done on MSP430F5xx/6xx devices if you ever use those. So what you are asking about is something that is done, it's just not a feature on the particular part you are using. Some people have created software FLL algorithms on their own though, using a timer to compare the output of the DCO to the 32kHz crystal (# of DCO ticks in one XTAL period), then in software adjust the DCO control bits accordingly. This is more involved and software heavy though than on the parts where this is done in hardware. Regards, Katie
  9. Similarly, this will allow you to do the same thing but across all MSP sub-families (2xx, 5xx, FRxx, etc) as well: http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/msp/products.page For more detailed information than what is in this comparison tool online though, it is always best to check the specific device datasheet. The User's Guides cover an entire sub-family and so they include information on every possible module in that sub-family, so to see if a particular module or feature is present in a specific device it is best to check the datasheet. Regards, Katie
  10. Video of it in action: https://www.youtube.com/watch?v=jxUdoCaI04o
  11. Ok I'll fess up - it was me :-) Though I've got to give a hat-tip to @@ILAMtitan for the inspiration (and letting me use his book) hahaha. I'm just disappointed that although I sit right next to you (which makes trolling easier ) I somehow missed the opening of both of these, and thus the reaction. Probably a good thing though, as I really have no poker-face at all and would have smiled and laughed too obviously.
  12. Came home yesterday to this tiny bundle of awesome waiting in my mailbox: Quarter for scale. IT'S SO TINY AND ADORABLE!!! It pretty much looks and sounds like a big bee when you're flying it around. Still working on hovering/landing without wiping out - was starting to get better towards the end of the night. Fortunately it's been pretty durable so far despite all my crash landings. If I can master it maybe we'll get an action shot/video posted up here :-) I will also have to buy my husband one for Christmas now because he can't stop playing with it and is super jealous hahaha. Dueling micro-copters! Thanks @@spirilis!!!
  13. Yeah unfortunately this is because of different pinouts as you alluded to. There is a board that supports FR4xx - but it is a new one: http://www.ti.com/tool/msp-ts430pm64d. If you want to learn more about the IR module there's also an app note about it: http://www.ti.com/lit/pdf/slaa644 Really fun if you want to make your own remote control :-) Right - currently this device is just sampling engineering samples so people can start designing with it now to be able to go to production at release. Production orders can only be placed later at full release and those parts will be the final release revision and be MSP430FR4133 not XMS430FR4133. If you look at the product page this is why it says "Preview" next to the part number at the top. It will change to "Active" at full production silicon release. http://forum.43oh.com/topic/5609-ti-msp430-wolverine-now-in-production/?p=48972 You can find FR2033 device here: http://www.ti.com/product/msp430fr2033 Pretty similar but no LCD. Finally, if you want to know more about the differences on this part, there are some migration guides posted too: http://www.ti.com/lit/pdf/slaa649 (F2xx/G2xx to FR2xx) http://www.ti.com/lit/pdf/slaa648 (F4xx to FR4xx)
  14. Hi @@mrinverter, There are a few things that jump out at me: 1. Your GPIO setting looks incorrect to me. You are using P2.5 + P2.6 for UCA1TXD/RXD. However, looking at the FR5969 datasheet http://www.ti.com/lit/gpn/msp430fr5969 on p. 88 table 6-52 I see this for the pin setup: You need to have P2SEL1 bit 5 and 6 set to 1, and P2SEL0 bit 5 and 6 set to 0. Right now, it looks like your code does the opposite: P2SEL0 |= RXD + TXD; //Setup the I/O //P2SEL1 |= RXD + TXD; So switch which line is commented out. 2. You are now using FR5969. This device has an eUSCI module (enhanced USCI) rather than USCI that was present on G2553. There are a few differences (for more detail please see the USCI to eUSCI migration guide http://www.ti.com/lit/pdf/slaa522). One thing is the interrupt vector is different on eUSCI so this needs to be changed. It should be the USCI_A1_VECTOR, and you should also modify the ISR to have a switch statement to handle and respond to the correct values for UCA1IV because this is different. You may want to look at some FR5969 code examples for a demonstration of this. Another thing is the baud rate generation. The eUSCI module provides a few more bits to get you better granularity and accuracy for generating baud rates - please check the FR5xx/6xx user's guide http://www.ti.com/lit/pdf/slau367 Table 21-5 for a list of recommended settings to generate different baud rates, and note the slight difference - you should change your code to match this (notably UCBSx = 0x49). There may be other things to change, but hopefully these tips will help! Regards, Katie