wygonski
-
Content Count
16 -
Joined
-
Last visited
Recent Profile Visitors
1,061 profile views
-
We have used Energia for TM4C123GXL for firmware development of a product. Now we want to do firmware updates in the field over USB-serial bridge to UART0. We have successfully used the serial variant of the TM4C123GXL built-in ROM bootloader with Code Composer - built apps to test the serial update process. However with the Energia-generated .bin files, the serial load works but the app does not restart correctly after the load, and requires a hard reset or power cycle to boot correctly. So I think it may have something to do with jumping to the start address after load. I have look
-
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
-
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
-
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 c
-
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/energia
-
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.
-
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.)
-
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 poin
-
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?
-
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?
-
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?
-
(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, 0
-
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
-
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?
-
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.