Jump to content

wygonski

Members
  • Content Count

    15
  • Joined

  • Last visited

About wygonski

  • Rank
    Member

Recent Profile Visitors

344 profile views
  1. So I have successfully placed named code and data sections in to upper FRAM, which was my goal. Next I'll test out the program to verify that the MSP430 20-bit address mode is used when accessing these sections. Thanks much for your suggestions and help, indeed it seems to work well. John
  2. Hi, thanks for your comments. Just to elaborate a bit on using ".upper.data" Using the ".upper.data" section directive on an array: ADI_REG_TYPE __attribute__((section(".upper.data"))) Param_Data_IC_1[PARAM_SIZE_IC_1] = { 0xFF, 0xEE, 0xEE, 0xDD, the resulting .hex file has record :065E34000100FFEEEEDDAF showing the load address of the array at 0x5E36 in lower FRAM I believe the explanation is in the linker control file, where the named section ".upper.data" gets mapped to "> HIFRAM AT> ROM". Then I changed the declaration to use ".upper.rodata", after seeing in the linker control file that the named section ".upper.rodata" gets mapped to "> HIFRAM" ADI_REG_TYPE __attribute__((section(".upper.rodata"))) Param_Data_IC_1[PARAM_SIZE_IC_1] = { 0xFF, 0xEE, 0xEE, 0xDD, and the resulting .hex file has records :020000021000EC :04000000FFEEEEDD44 showing the load address of the array at 0x10000 in upper FRAM. So a minor point, just that the ".upper.data" section directive did not behave as I thought it should, and of course the linker followed the attributes in the control file.
  3. Thank you, that suggestion worked and now there are no build errors. I compiled a sketch without any section directives and the build output message is: Sketch uses 47865 bytes (99%) of program storage space. Maximum is 48128 bytes. Global variables use 1744 bytes (85%) of dynamic memory, leaving 304 bytes for local variables. Maximum is 2048 bytes. Low memory available, stability problems may occur. Then I added section directives to place a few functions in ".upper.text" and the build output message did not change, which likely reflects your earlier comment that mem size computations are off. I examined the .hex file records for the two cases and I found that the .hex file after adding the section directives contains an extended segment address record: :020000021000EC which indicates that subsequent data records in the file are located at offset 0x1000 * 16 = 0x10000. So I believe this demonstrates that those functions are located in .upper.text as desired. Thank you very much for your time and expertise to get this working for me! A few followup questions: 1. Is there a way to instruct the gss-elf compiler in Energia to produce a map file? 2. I would like to locate some large initialized data arrays in upper FRAM, and I used a section directive ".upper.data" to achieve this. However, after examining the .hex file the array did not get located at 0x10000 as desired. I examined the linker control file for the part I'm using and I saw that the named section ".upper.data" gets mapped to "> HIFRAM AT> ROM" which means the load address is at 0x4000, not at 0x10000 as desired. I note that in the same linker control file, the named section ".upper.text" gets mapped to "> HIFRAM" so the load address is 0x10000 as prevously demonstrated. Is this the intended behavior? Thank you, John
  4. Thanks for the reply, I made the change as you pointed out. I also needed to change my board selection to MSP-EXP430FR5969LP in Energia MSP430 boards (elf-gcc) instead of the default boards package. Now I am seeing this build error: c:/users/johnw/appdata/local/energia15/packages/energia/tools/msp430-elf-gcc/8.3.0.16/bin/../lib/gcc/msp430-elf/8.3.0/../../../../msp430-elf/bin/ld.exe: C:\Users\johnw\AppData\Local\Temp\arduino_build_821791/Master_Firmware_ZFM_Gen1_5_V1_8_08-08-2018.ino.elf section `.upper.text' will not fit in region `HIFRAM' c:/users/johnw/appdata/local/energia15/packages/energia/tools/msp430-elf-gcc/8.3.0.16/bin/../lib/gcc/msp430-elf/8.3.0/../../../../msp430-elf/bin/ld.exe: region `HIFRAM' overflowed by 24605 bytes I have removed all the section directives in my source code but still this error persists. The size of the original code (small memory model) is around 47 kBytes. It is not clear to me why upper FRAM is overflowing by over 24 kB, isn't lower FRAM used first? Thanks for your help, John
  5. After restarting Win10 and reinstalled Energia again. Installed ENergiaMSP430 boards (elf-GCC) and waited patiently (>30 minutes!) even though the install appeared to hang as before. Finally shows installed: Moving on to try out the use of upper FRAM with MSP430FR5969. Started with a project that utilized around 94% (approx number is 47300 bytes) of the available 48k in FRAM. Added __attribute__((section("REGION_FAR_TEXT"))) to a few function definitions and the build output shows: Sketch uses 44912 bytes (93%) of program storage space. Maximum is 48128 bytes. So is this good sign, program memory size is reduced? And where is the code relocated to? I assume to "REGION_FAR_TEXT" mapped to memory region "far_rom" at 0x010000 as declared in the memory.x file. Also, Maximum size is not correct (continues to report 48128 bytes) in that it is not taking into account upper FRAM that should be available. However then I added the section attribute to another function declaration, and the build failed, with the error message indicating that the linker is trying to locate the function in memory region "ram". So this is a bit puzzling to me: c:/users/johnw/appdata/local/energia15/packages/energia/tools/msp430-gcc/4.6.6/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld.exe: C:\Users\johnw\AppData\Local\Temp\arduino_build_27531/Master_Firmware_ZFM_Gen1_5_V1_8_08-08-2018.ino.elf section `REGION_FAR_TEXT' will not fit in region `ram' c:/users/johnw/appdata/local/energia15/packages/energia/tools/msp430-gcc/4.6.6/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld.exe: region `ram' overflowed by 348 bytes I looked in my %appdata% path and I do see the msp430-elf-gcc folder in addition to the msp430-gcc folder in packages/energia/tools. In preferences.txt I do have boardsmanager.additional.urls=http://s3.amazonaws.com/energiaUS/packages/package_msp430_elf_GCC_index.json So this build output does not look right, can you advise?
  6. Hi, thanks very much for the clarification and I am enthusiastic to try out your suggestion. I started by downloading Energia 1.8.11E23 from the Energia site, and then I added the path to the additional boards managet URL in Preferences. However I am having difficulty installing the latest version of the Energia MSP430 boards (elf-GCC). It hangs while installing after the download and And same hanging behavior installing v1.0.7 of Energia MSP430 boards. Is there a different place I sould be asking for help with this one? (Google did not turn up anything useful.)
  7. Thank you both StefanSch and Rei Vilo for your helpful responses. I will go back to our dev group to discuss the options you presented. If I understand correctly, both your suggestions involve modifying or rebuilding the Energia tools. Our group has a few developers working on product code which started in Energia and grew over the years, and and it's not clear that we have the expertise to take that on in order to solve our memory space problem with our MSP430 codebase. Do either of these two options hold the possibility of being merged into the Energia main trunk at some point down the road? If I am not understanding correctly please let me know. In any event, thank you for your quick responses and we may take one of the options you suggested.
  8. I would like to locate code (or data) in upper FRAM using something like: void __attribute__((section("REGION_FAR_TEXT"))) myFunction(void); This should be possible because Energia for MSP430 memory.x files have a line REGION_ALIAS("REGION_FAR_TEXT", far_rom); and far_rom is declared as: far_rom : ORIGIN = 0x00010000, LENGTH = 0x00004000 /* END=0x00014000, size 16K */ but this was not working back in Energia E20. Is this working now in Energia E23?
  9. 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?
  10. 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?
  11. (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
  12. 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
  13. 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?
  14. 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.
  15. 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...