Jump to content


  • Content Count

  • Joined

  • Last visited

About wygonski

  • Rank
    Noob Class

Recent Profile Visitors

279 profile views
  1. I am seeing in this post Energia support for MSP430FR5994 LaunchPad? that support has been added in Energia for the MSP430FR5994. This would work for me if I could utilize Upper FRAM on that chip. I have Energia E20 installed, and presumably I need to use -mlarge option for extended addressing to get to upper FRAM. How do I get Energia to use a compiler other than GCC 4.6.3?
  2. Thanks for the reply. In your post you mentioned CCS includes MSP430 GCC v7.3.1. Did you have success building Energia projects in CCS with that compiler selection?
  3. (Apologies for posting both here and on TI E2E forum) I am not able to use upper FRAM above 0x0001000 on MSP430 in Energia for an existing project, I am using latest Energia release E20 which uses latest version of gcc compiler 4.6.6. My goal is to 1) get the linker to locate two initialized data arrays in upper FRAM on MSP430FR5994 or MSP430FR5969 and 2) read that data as a lookup table using the Energia program. I have used the following attribute to map the arrays to upper FRAM: const unsigned char __attribute__((section(".fartext"))) Program_Data_IC_1[5120]= { 0xFF, 0xF2, 0x00, 0x20, 0x01, 0x00, 0x00, 0x00, 0xE2, 0x01, ... However, any code access to the array gives the build error relocation truncated to fit: R_MSP430_16_BYTE against `no symbol' which I believe is due to trying to access upper FRAM with a 16-bit pointer. So I tried modifying Energia's platform.txt to use large memory model: compiler.mlarge_flag=-mlarge but building in Energia E20 gave the error: cc1plus.exe: error: unrecognized command line option '-mlarge' exit status 1 Error compiling for board MSP-EXP430FR5994LP. I also tried using TI's GNU 7.3.1 (Mitto Systems) compiler in CCS 8.1 but I got errors building the Energia core library that is needed. Is there any suggestion as to how to accomplish using upper FRAM in this way? Thanks in advance, John
  4. 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
  5. Just checked the Energia DriverLib, and this may be an issue in eusci_a_spi.c I'm willing to follow up on this--is there a way to flag issues for MSP430 Energia?
  6. Following up on my original question, it turns out this is not an Energia question, but is a bug in MSP430FR5969 silicon. See here: https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/355932/1380140#1380140 Also, I did a quick check of Energia SPI code for MSP430's having a eUSCI (where this issue exists), and the code is implemented in a way that the silicon bug is not an issue.
  7. I'm looking for help in understanding what background processing might be occurring in an Energia sketch. I'm running on a FR5969 Launchpad, and I have a succession of 10 SPI transfers to access a peripheral. (I wrote the SPI functionality in C--not using Energia for that.) I am looking at a logic analyzer timing measurement of these transfers, and I expected to see the transfers execute un-interrupted. However, I regularly see a 1ms gap in the tranfers, occuring at a seemingly random spot. I know Energia implements a timer function in the background, but 1ms seems like a long time to spend in such a background thread. The only other Energia classes used are Serial, and a pin interrupt to handle a button press. Any insight into what might be interrupting the main thread for a millisecond? Thanks in advance
  • Create New...