MSP430 use all 128kB (not just 47kB)

Yes indeed, if it works and all is set up correctly, the new TI GCC compiler should automatically fill up all the available flash space with code and data how it needs to, without any additional direction giving, and you’d need to change from your current

[env]
platform = timsp430
board = lpmsp430f5529
board_build.mcu = msp430f5529 ; change microcontroller
board_build.f_cpu = 24000000L ; change MCU frequency
board_upload.maximum_size = 131072 ; 128kByte = 131072 Byte / 48128 Bytes is default
debug_tool = mspdebug
[env:lpmsp430f5529]
;extra_scripts = extra_build_script.py
board_build.ldscript = msp430f5529.ld ; linker script
build_type = release ; debug or release
build_flags =
  ;-v ; Verbose
  -Wall ; warning message generation and syntax checking
  ;-O ;optimization O0,-O,-O1,-O2, and-O3
  ;-std=c99
  -Wl,-Map=output.map #linker create an output.map file

to (simplified)

[env]
platform = https://github.com/maxgerhardt/platform-timsp430.git
board = lpmsp430f5529
board_build.mcu = msp430f5529 ; change microcontroller
board_build.f_cpu = 24000000L ; change MCU frequency
debug_tool = mspdebug
; upgrade to 9.3.1, binary distribution uploaded here, **WINDOWS ONLY**
platform_packages = 
     toolchain-timsp430@https://github.com/maxgerhardt/pio-toolchaintimsp430-new.git

[env:lpmsp430f5529]
build_type = release ; debug or release
build_flags =
  -Wall ; warning message generation and syntax checking
  -Wl,-Map=output.map #linker create an output.map file

aka a change of platform and an addition of platform_packages to upgrade the compiler and compiling logic / settings. (while also deleting the msp430f5529.ld inside the project folder because it would interfere).

But check out the minimal example first :slight_smile:

Hi @maxgerhardt,
this is what i did first today:

At first it didn’t work but I think PIO needed to update some things (probably also fetching your github repos) and then I had instant success compiling.

1 Like

Looks good. If you have multiple projects open in your VSCode workspace you can also double-check that the right one is active with the project environment switcher.

Otherwise, try and get the UART working to get the printf() output to confirm high-ROM placement is working – as I have no board I wasn’t able to test that UART output is there, only that the build tools say that the functions are indeed placed correctly.

If that’s working you can start adding your original project files from there and see if it gets a better result now :slight_smile:

Second step today was to try and use your simplified platformio.ini and apply it to my simple blink example I can succesfully compile and flash. I didn’t want to use your UART example because my hardware is a little bit specific e.g. using the other UART port, also LED blinking is fine for now.

this .ini file works (it differs to your proposal only in platform and platform_packages)

[env]
platform = timsp430 ;https://github.com/maxgerhardt/platform-timsp430.git
board = lpmsp430f5529
board_build.mcu = msp430f5529 ; change microcontroller
board_build.f_cpu = 24000000L ; change MCU frequency
debug_tool = mspdebug
; upgrade to 9.3.1, binary distribution uploaded here, **WINDOWS ONLY**
;platform_packages = 
    ;toolchain-timsp430@https://github.com/maxgerhardt/pio-toolchaintimsp430-new.git
[env:lpmsp430f5529]
build_type = release ; debug or release
build_flags =
  -Wall ; warning message generation and syntax checking
  -Wl,-Map=output.map #linker create an output.map file

this .ini file does not work (changes only in platform and platform_packages → it equals your proposal)

[env]
platform = https://github.com/maxgerhardt/platform-timsp430.git
board = lpmsp430f5529
board_build.mcu = msp430f5529 ; change microcontroller
board_build.f_cpu = 24000000L ; change MCU frequency
debug_tool = mspdebug
; upgrade to 9.3.1, binary distribution uploaded here, **WINDOWS ONLY**
platform_packages = 
    toolchain-timsp430@https://github.com/maxgerhardt/pio-toolchaintimsp430-new.git
[env:lpmsp430f5529]
build_type = release ; debug or release
build_flags =
  -Wall ; warning message generation and syntax checking
  -Wl,-Map=output.map #linker create an output.map file

this is my simple blink example which includes some other initializations due to the specific hardware…

#include <msp430f5529.h>

#define DELAY_1S    24000000
#define DELAY_100MS 2400000
#define DELAY_10MS  240000

void setup() {
  //watchdog off
  WDTCTL = WDTPW + WDTHOLD; 
  // important for hardware
  PASEL = 0x0000; // 0=io       1=func 
  PADIR = 0xffff; // 0=input    1=output 
  PAOUT |= 0x1fff;      // LOAD1 to LOAD13 must be high
  // important for hardware
  //P8.0 (UNLOAD) and P8.2 (HV_ENABLE) must be high
  P8SEL &=~ BIT0 + BIT2; // 0=io       1=func  
  P8DIR |= BIT0 + BIT2;  // 0=input    1=output
  P8OUT |= BIT0 + BIT2;  
  /* initialize clock and core voltage */
  PMMCTL0 = PMMPW + PMMCOREV0 + PMMCOREV1;  // Set Vcore Voltage to maximum
  P7DIR |= BIT7;                            // MCLK set out to pins
  P7SEL |= BIT7;
  P5SEL |= BIT2+BIT3;                       // Port select XT2
  UCSCTL6 |= XT2DRIVE0 + XT2DRIVE1;         // Decrease XT2 Drive according to
  UCSCTL6 &= ~XT2OFF;                       // Enable XT2 
  UCSCTL3 |= SELREF_2;                      // FLLref = REFO
                                            // Since LFXT1 is not used,
                                            // sourcing FLL with LFXT1 can cause
                                            // XT1OFFG flag to set
  UCSCTL4 |= SELA_2;                        // ACLK=REFO,SMCLK=DCO,MCLK=DCO
  do
  {
    UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);
                                            // Clear XT2,XT1,DCO fault flags
    SFRIFG1 &= ~OFIFG;                      // Clear fault flags
  }while (SFRIFG1&OFIFG);                   // Test oscillator fault flag
    UCSCTL4 |= SELS_5 + SELM_5;               // SMCLK=MCLK=XT2  

  // setup Rear Valves
  P6SEL &=~ (BIT2 + BIT3);
  P6DIR |=  (BIT2 + BIT3);
  P6OUT &=~  (BIT2 + BIT3);
  // setup cycle LED
  P6SEL &=~ BIT5;
  P6DIR |= BIT5;
  P6OUT &=~ BIT5;
  // signalize end of initialization 
  // double blink cycle LED
  for(int i=0; i<4; i++){
    P6OUT ^= BIT5; 
    __delay_cycles(DELAY_100MS);
  }  
}

// simple blinking loop
void loop() {  
  P6OUT ^= BIT5;
  __delay_cycles(12000000); 
}

int main(){
  setup();
  while(1){
    loop();
  }
  return 0;
}

errors i get:


Building in release mode
Linking .pio\build\lpmsp430f5529\firmware.elf
c:/users/wolfg/.platformio/packages/toolchain-timsp430@src-af925a7ca3ab95b9df147cb9f1e9b1d9/bin/…/lib/gcc/msp430-elf/9.3.1/…/…/…/…/msp430-elf/bin/ld.exe: .pio\build\lpmsp430f5529\src\main.o: in function setup()': main.cpp:(.either.text._Z5setupv+0x0): undefined reference to WDTCTL’
c:/users/wolfg/.platformio/packages/toolchain-timsp430@src-af925a7ca3ab95b9df147cb9f1e9b1d9/bin/…/lib/gcc/msp430-elf/9.3.1/…/…/…/…/msp430-elf/bin/ld.exe: main.cpp:(.either.text._Z5setupv+0x8): undefined reference to PASEL' c:/users/wolfg/.platformio/packages/toolchain-timsp430@src-af925a7ca3ab95b9df147cb9f1e9b1d9/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/bin/ld.exe: main.cpp:(.either.text._Z5setupv+0xe): undefined reference to PADIR’
c:/users/wolfg/.platformio/packages/toolchain-timsp430@src-af925a7ca3ab95b9df147cb9f1e9b1d9/bin/…/lib/gcc/msp430-elf/9.3.1/…/…/…/…/msp430-elf/bin/ld.exe: main.cpp:(.either.text._Z5setupv+0x14): undefined reference to `PAOUT’

so for some reason these MSP430 specific definitions casue the problem?

Are you 100% sure there is no msp430f5529.ld in your project directory? I’ve had this error too which was due to this local file overshadowing the correct linker file in the toolchain repository, which includes the peripherals addresses linker file. That’s why I also put that note in the README.

perfect! Thanks. I think you mentioned that earlier that we woun’t need any .ld file

… seems like I am not the only one having that problem :wink:

adapting your example with my init stuff and changing UCA0 to UCA1, i get the following messages on the serial monitor after flashing

a) defining → #define FORCE_HIGHMEM

Entry params: 1, 2
FORCE_HIGHMEM is activated. The following functions and constants should be in high-ROM >= 0x10000.
Constant test: value 123, address 0x10000
my_function_in_hirom address: 0x10002

b ) undefining → //#define FORCE_HIGHMEM

Entry params: 1, 2
FORCE_HIGHMEM is deactivated. The following functions and constants will probably be placed in low-ROM, depending on compiler settings.
Constant test: value 123, address 0x2400
my_function_in_hirom address: 0x476c

so to me that looks like the expected output right?

Yes that’s great! :slight_smile: The function was successfully placed in high-rom when forced to do so and not when it can decide by itself (and low-ROM is not already full).

This should mean that you can try to add the entire other code in the project and it should hopefully use up all available space nicely by itself…

Would I be able to see in the firmware.hex file that the address 0x10000 is written?

I can see that a lot of data will be writte to adress 0x4400 until 0x685C, also at address 0xFFFE as expected. I am not so sure about the last two lines of the firmware.hex file though.

last six lines from firmware.hex:

:10683C000C4D0D4E401882431825B01348673C93FD
:10684C00072040181D4218250D9302248A4D000084
:0A685C000A161001B01302671001C4
:02FFFE00F846C3 (2 bytes at FFFE)
:04000003000046F8BB (4 bytes not sure where exactly)
:00000001FF (0 bytes at 0x0000 → probably end of file intel style)

Per Intel HEX file Viewer that part only shows that addresses up to 685C are being used.

If I use my original example and plug the hex file into the viewer above, I get

So clearly the high addresses are visible, but the hex file has to use an extended segment address record to be able to convey addresses beyond the 16-bit usual address space (address is only 4 hex chars…).

A better way to get see what addresses are used would be to use the nm (the arm version of it) to dump all symbol information (name + addresses) in the .elf file

C:\Users\Max\.platformio\packages\toolchain-gccarmnoneeabi\bin\arm-none-eabi-nm.exe .\.pio\build\lpmsp430f5529_large\firmware.elf | grep 1000
00010006 t .LCFI0
00010002 t .LFB1
00010002 t .Loc.28.1
0001000e t .Loc.29.1
00010000 D constant_in_hirom
00010002 T my_function_in_hirom

or directly the .map file together with e.g. amap.

All three show the high addresses being used in my example.

thanks for the nice tips. It is definately producing firmwarecode at 0x10000 and beyond!

Thanks a lot for all the Help @maxgerhardt very much appreciat it! Is there a way that this might become part of standard PlatformIO? Maybe also note that I created an issue on this topic last week here: 128kByte on MSP430F5529 · Issue #21 · platformio/platform-timsp430 · GitHub