Search the Community

Showing results for tags 'fram'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • News
    • Announcements
    • Suggestions
    • New users say Hi!
  • Spotlight!
    • Sponsor Spotlight
    • Sponsor Giveaways
  • Energia
    • Energia - MSP
    • Energia - TivaC/CC3XXX
    • Energia - C2000
    • Energia Libraries
  • MSP Technical Forums
    • General
    • Compilers and IDEs
    • Development Kits
    • Programmers and Debuggers
    • Code vault
    • Projects
    • Booster Packs
    • Energia
  • Tiva-C, Hercules, CCXXXX ARM Technical Forums
    • General
    • SensorTag
    • Tiva-C, Hercules, CC3XXX Launchpad Booster Packs
    • Code Vault
    • Projects
    • Compilers and IDEs
    • Development Kits and Custom Boards
  • Beagle ARM Cortex A8 Technical Forums
    • General
    • Code Snippets and Scripts
    • Cases, Capes and Plugin Boards
    • Projects
  • General Electronics Forum
    • General Electronics
    • Other Microcontrollers
  • Connect
    • Embedded Systems/Test Equipment Deals
    • Buy, Trade and Sell
    • The 43oh Store
    • Community Projects
    • Fireside Chat
  • C2000 Technical Forums
    • General
    • Development Kits
    • Code Vault
    • Projects
    • BoosterPacks


There are no results to display.

Found 17 results

  1. We are using Energia 17 with the MSP430FR5969 iand we now need to utilize upper block of FRAM at 0x10000 for storage of an initialized byte array because our program size has increased beyond the 48k in lower FRAM. I've modified the linker command file to locate the ".upper.rodata" section in "far_rom" at 0x010000 and declare the array as follows: const unsigned char __attribute__((section(".upper.rodata"))) Program_Data_IC_1[4096} = { <byte values here> } However, after modifying the Energia linker command file and rebuilding the Energia project (in CCS 6.1.3) the Energia build fails with: "relocation truncated to fit: R_MSP430_16_BYTE against symbol `Program_Data_IC_1' defined in .upperFram section in ./sigma_SPI.o" All I really need is to produce a loadable file with the array mapped to upper FRAM. I will be accessing this data array with a C pointer initialized to 0x010000, I just need to get the Energia build system to output a elf file--the linker gets to the point of producing a correct .map file (in CCS 6.1.3) I've tried a few things such as introducing the -mlarge build option, and the "far" keyword, but these produce build errors because they are not supported in MSPGCC 4.6.3. So it appears that the Energia 17 build tools will not allow for any location of data above the 64k boundary? Any workaround? Thanks in advance, John
  2. Hi everyone. I was looking through the Energia library (cores/msp430/twi.c) today trying to debug an issue I have been seeing, and noticed the following code: /* Work around for: * If the master does a read and then a write the START interrupt occurs * but the RX interrupt never fires. Clearing bit 4 and 5 of UCBxCTLW0 solves this. * bit 4 and 5 are however marked as reserved in the datasheet. */ UCBxCTLW0 &= ~0x18; Does anyone happen to know why this is? I have searched high and low for a reference on TI's forums and in their documentation to no avail. Thanks for the help! NJC
  3. Hi Guys, My name is Nathan. I've lurked around here on 43oh a bit, but this is my first official post. I've been working with the MSP430FR5969 for several months now and I've quickly grown to really like it. It seems to me TI's FRAM processors should really be getting more exposure for battery powered development in both professional and maker communities. To that end - I was hoping to get some feedback on a product idea. We've packaged the FR5969 into a tiny coin-cell powered module. The module can operate as a stand-alone processor or it can plug into an UNO-form-factor breakout board with an eZ-FET lite programmer, allowing you to program it with CCS or Energia. We're waiting on the first PCB's to debug the base product right now, but the goal would eventually be to offer with with a handful of matching small daughter-boards to add WiFi, BTLE and either the Sharp LS013B4DN04 hybrid screen or an e-ink display - all except the WiFi would be powered directly by the coin cell (WiFi would require a couple AAA's). It might make sense to have a few sensor boards too depending on interest level (humidity/temp, compass, GPS, accel, gyro, prox, etc.) Does that make sense? Any thoughts? Is this a product you think people would be interested in? It doesn't seem like anyone is offering really well-packaged small, ULP, battery powered MCU modules, especially with Arduino code compatibility and this would fill a good niche (certainly one I have some uses for anyway). Anyway - I'd appreciate any feedback or suggestions. Thanks. NC
  4. Sorry to bother if I'm missing something obvious in the documentation - but there's something I can't seem to figure out. I'm migrating a simple datalogger that uses an ATTiny24a, BMP180, and an external EEPROM to (hopefully!) take advantage of the power savings and FRAM on the MSP430FR5969. I've attached a sample of my code by I can't seem to find anywhere similar functions to and EEPROM.write. All I've managed to find is FRAM_write<enter # of bits here> in the fram.c in the DriverLib library. Basically all I'm trying to do is log data to the FRAM at a specified interval, then after a certain number of datalogging events read it back out and convert to on-off keying. Each datalogger has it's own unqiue ID. At a later time I want to look into the different lower power modes on the MSP430, but first things first. Again, I apologize if I'm overlooking something quite simple.
  5. MSP-BNDL-FR4133IR (MSP430FR4133 LaunchPad with IR BoosterPack) now $17.99 MSP-BNDL-FR5969LCD (MSP430FR5969 LaunchPad with Sharp
  6. Hi All, My company is interested in developing passive sensors that are capable of harnessing energy from the environment, so basically the sensor are completely dead and without power until there's either light, temperature difference, vibration, or RF illumination. So I do not care about high current draw in sleep mode. In this type of environmentwhat would work best? MSP430FR? or M0+? Current draw during start-up on the MSP430 is also a problem, which is roughly 1 ms. Looking at the EMF32 Zero Gecko, Its list as 400us with a 24MHz clock. It seems to me that Zero Gecko would be a better choice, but from uA/MHz FRAM based MSP430 is a better choice. I don't need to do any crazy computation here, all I need is for the ADC to measure a time decay, and send it back out through a wireless tx module.
  7. Hi All, I'm attempting to get an SD card working with the MSP430FR5969 (launchpad) and FatFS but I'm having a difficult time. Two questions: 1. Is it possible to get FatFS working with the MSP430? When I did a search of these forums I mostly saw PetitFat being used with MSP430s. Ultimately, PetitFat would be okay but I would prefer FatFS. 2. Has anyone gotten either PetitFat or FatFS working with the MSP430FR5969? If so, would you be willing to share your code or knowledge regarding it? Thank you in advance for any help, Nipun
  8. I'd like to write to FRAM on a MSP430FR5739 with Energia, Does anyone has an example? Thank you, Stephane
  9. Recently there was a contest for applications using TI's ESI hardware rotation/flow sensing peripheral, I was one of the winners of that. Actually TI did a pretty cool thing and gave the prize (target board and programmer) to everybody who entered rather than just their favorite five. Go TI! In any event, here is product pitch I submitted: I also submitted a more advanced version that ties into the fuel injectors and computes instant and average mileage, but I may or may not get to that in a reasonable time period. This is my project thread for this project, if you hadn't guessed. I'll be updating this first post as progress continues, as well as making more posts in the thread. I welcome any/all input, feature ideas, suggestions, comments, etc. I'm hoping to begin work on prototype code later today, I'll probably start off using a MSP430G2553 rather than a FRAM w/ESI chip, as I'd much rather blow up a $2.70 chip than a $25 launchpad or a FRAM MCU that isn't available for sale yet. I do have a FR5969 launchpad, which has the ESI bits in it as well, that will go into use once I make sure the inputs are at the voltage(s) I think they are.
  10. Using the FRAM as though it were RAM on the msp430fr59xx chips can make it really easy to drive those ws281x chips even at a relatively slow MCU clock rate. The ws281x chips are great because you can get a boat load of leds for the cost of only one pin. Also, it doesn't hurt the price of these ws281x chips keeps falling and making them more and more attractive. I decided to see if I could take advantage of FRAM to help me drive some of those leds. I ended up with an extremely simple driver routine that works great even when you clock the FRAM MCU @ 6MHz. You couldn't really do this on a RAM limited msp430 chip as you would quickly run out of memory. ... I configured the FRAM chip for 6MHz and then configured the SPI to use a clock divisor of 1 the MOSI is selected for output and is wired to ws281x DIN pin. ... static const uint8_t frame_buffer[60*3*8] = {0}; /* provide an FRAM buffer for a strip of 60 leds */ /* * inline msp430-elf-gcc asm version */ void sendRGB(uint8_t * led_data, unsigned led_data_len) { const uint8_t *led_data_end = led_data+led_data_len; uint8_t *dest = const_cast<uint8_t *>(&frame_buffer[0]); uint8_t *frame = dest; do { unsigned color = *led_data++; register unsigned colormask = 0x80; do { *dest++ = (color & colormask) ? 0x78 : 0x60; colormask = colormask >> 1; } while (colormask); } while (led_data < led_data_end); // shift out bits in MSB order without much delay __asm__ __volatile__ ( "1:\n" " mov.b @%[led_data]+, %[TXBUF] ; 5 cycles\n" " jmp .+2 ; 2 cycles\n" " cmp %[led_data_end], %[led_data] ; 4 cycle\n" " jl 1b ; 2 cycles\n" :[led_data] "+&r" (frame) ,[led_data_end] "+r" (dest) :[TXBUF] "m" (UCB0TXBUF) : "cc" ); In the code above, I provided a function that expects an array of RGB data (well GRB data actually ) and I I looped through it and setup the FRAM buffer with proper SPI bits for ~333ns/~666ns and with a period of ~1500 ns. The wave it spews out looks really pretty on my scope. Best of all, the ws281x chips seem to like it. I encountered one wierd anomaly of the eUSCI periperal. It seems that if the high bit of the last thing you sent is high, then the MOSI pin floats high instead of leaving the value at the last bit set. This is why I'm using 0x78 (0b01111000) and 0x60 (0b01100000) instead if 0xF0 and 0xC0. I wasted a bunch of time trying to find out why my code wasn't working on that one. I never did find a tech note or errata about it. If you are using the SPI device as a normal SPI device instead of a shift register, it wouldn't matter. -rick
  11. Just as an FYI - I was concerned about using the built in DCO in the FR5969 for UART because the spec sheet says although it's factory trimmed, it's still +/-3.5%. Generally it needs to be within 2% for a UART to work correctly so I measured the two FR5969's I have on our 2.4GHz frequency counter and this is what I got. 2 is obviously not a big sample size, but the frequency trimmed DCO on the FR series looks pretty good @ room temp and 8MHz or under. I found another doc from TI that's a comparison between F5xxx and FR5xxx and it mentions the DCO is generally within 2% "within a restricted temperature range" and within 3.5 in the full temperature range (-40C to 85C). I may need to re-measure at 4C because that's typically where our project will be operating.
  12. I tested the lauchpad FR5969 with the new version of energia. After having changed both HIL.dll and MSP430.dll files in the directory E: \ ENERGIA_V13 \ energia-0101E0013 \ hardware \ tools \ msp430 \ mspdebug, I managed to correctly program the FR5969 launchpad. Searching the memory.x file in the E: \ ENERGIA_V13 \ energia-0101E0013 \ hardware \ tools \ msp430 \ msp430 \ lib \ ldscripts \ msp430fr5969, I saw that the compiler does not take advantage of the characteristics of FRAM which allows sharing of 64 kbytes memory between program space and ram space. Indeed it currently uses the standard 2 kbytes static ram. I did some tests by changing the values ??to use 4 KB of RAM in fram memory and 44 kb to store the program and it seems to work ?. Question: Is this possibility can be integrated in a future revision of ENERGIA. Enclosed changes: old file memory.x ram (wx) : ORIGIN = 0x1c00, LENGTH = 0x0800 /* END=0x2400, size 2K */ Static ram rom (rx) : ORIGIN = 0x4400, LENGTH = 0xbb80 /* END=0xff80, size 48000 */ new file memory.x ram (wx) : ORIGIN = 0xEF80, LENGTH = 0x1000 /* END=0xff80, size 4K */ Fram rom (rx) : ORIGIN = 0x4400, LENGTH = 0xAB7F /* END=0xEF80, size 44000 */ on the other hand i have tried to use the new ENERGIA version with the CC3000 TI BoosterPack . (it's work fine with VE0012) I think it is impossible to use this booster pack with this release because simpelinkwifi library has been replaced by Wifi library and SPI library was modified and seems to be incompatible with the old SPI library. Can I get a confirmation of my observations. Some assistance will be really helpful. Thanks in advance.
  13. Hey all, just wanted to share some code and a sweet picture of a QR code that was generated on an msp430fr5739: I'm working on a larger project that needed this functionality so I thought a proof of concept before I got too far into this was in order. While the pixels on the LCD I'm using (Nokia 5110 / PCD8544) aren't quite square, this code scans fine on my phone (Nexus 4). Anyways it uses the qrduino library to generate the code and some pcd8544 library for the lcd display. I briefly attempted to get this running on a g2553 but didn't quite manage it. The code is at, so fork and add g2553 support if you want! Cheers, -Andrew
  14. I recently bought a Fram board and a CC3000 for a small project. I have Code Composer already but wanted to try somthing new and ran across Energia. So I installed it and fired it up. I selected CC3000FirwareUpdate project to get started. Selected the FraunchPad w/ msp430fr5739 board in the Tools menu. Then I hit the Verify button... "Error compiling." c:/energia-0101e0011/hardware/tools/msp430/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld.exe: CC3000FirwareUpdate.cpp.elf section `.rodata' will not fit in region `rom' Regards Ken
  15. I recently bought a Fram board and a CC3000 for a small project. I have Code Composer already but wanted to try somthing new and ran across Energia. So I installed it and fired it up. I selected CC3000FirwareUpdate project to get started. Selected the FraunchPad w/ msp430fr5739 board in the Tools menu. Then I hit the Verify button... "Error compiling." See attached file. Regards Ken Error Compiling.txt
  16. Hey all! I have received an email from the Official MSP430 Blog where they announce a Holidays offer. They are taking 54% off the regular price for just this last two weeks of the year!!! So if you always wanted a Chronos or a Fraunchpad and the price tag was your restraint... now you have no more excuses. Woohoo!!! I just bought my very first Fraunchpad, and the discount code works... and I'm feeling tempted to get another Chronos... mmmmmmmmm Gast
  17. I was poking around on today, and I was pleasantly surprised as I noted two product families that are now public. The datasheet and user-guide dates are not super-new, but there has been little fanfare and somehow I missed it. Maybe the reason is because I've spent the last 6 months working mainly on Cortex-M. But anyway... 1. RF430F5978 I have been working with this for a long time, in private (i.e. there are libraries and board support in OpenTag). It's really cool, because it combines a CC430F5137 with a 134kHz passive RF IC. One cool app you can do with it is wireless charging, but really there are all kinds of cool apps that combine passive RF for localization with long-range active RF for data backhaul. 2. RF430FR15xH This is an NFC chip with a small FRAM MSP430 built right in. I have not used it, but I love NFC so it can't be bad.