This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR6043: Program doesn't run after BOR

Part Number: MSP430FR6043
Other Parts Discussed in Thread: UNIFLASH

Hi everyone,

I'm using a msp430fr6043 with USS module. I'm using cl430 (from ti-cgt-msp430_21.6.1.LTS) to compile/link using the following flags:

Compiler:

CFLAGS    += --define=__MSP430FR6043__
CFLAGS    += --define=_MPU_ENABLE
CFLAGS    += --c99
CFLAGS    += --silicon_version=mspx
CFLAGS    += --code_model=large
CFLAGS    += --data_model=large
CFLAGS    += --opt_level=4
CFLAGS    += --opt_for_speed=1
CFLAGS    += --use_hw_mpy=F5
CFLAGS    += --compile_only
CFLAGS    += --printf_support=minimal
CFLAGS    += --diag_wrap=off
CFLAGS    += --display_error_number
CFLAGS    += --silicon_errata=CPU21
CFLAGS    += --silicon_errata=CPU22
CFLAGS    += --silicon_errata=CPU40
CFLAGS    += --disable_interrupts_around_hw_mpy=on
CFLAGS    += --section_sizes=on
CFLAGS    += --obj_extension=.o
CFLAGS    += --obj_directory=$(BUILD_DIR)

Linker (also cl430):

LDFLAGS   += --silicon_version=mspx
LDFLAGS   += --silicon_errata=CPU21
LDFLAGS   += --silicon_errata=CPU22
LDFLAGS   += --silicon_errata=CPU40
LDFLAGS   += --code_model=large
LDFLAGS   += --data_model=large
LDFLAGS   += --printf_support=minimal
LDFLAGS   += --run_linker        # Next flags are linker flags
LDFLAGS   += --use_hw_mpy=f5
LDFLAGS   += --heap_size=160
LDFLAGS   += --stack_size=512
LDFLAGS   += --cinit_hold_wdt=on
LDFLAGS   += --entry_point=_c_int00_noargs
LDFLAGS   += --section_sizes=on
LDFLAGS   += -m"$(PROJECT).map"
LDFLAGS   += -xml_link_info="$(PROJECT).xml"

I'm also generating an .hex file with:

hex430 --memwidth=8 --romwidth=8 --diag_wrap=off --intel  project.elf -o project.hex

But I'm getting some unusual behaviors.


Problem 1:

  1. When loading the *.elf file with mspdebug,
    1. program starts
    2. runs for ~1s
    3. stops (no reset, no interrupt called)
  2. When loading the *.elf file with mspdebug,
    1. program starts
    2. runs normally
  3. When loading the *.hex file with uniflash,
    1. program starts
    2. runs normally
  4. If the program is running and I power cycle the board
    1. Same as (1.)

Both 1. and 2. happen with the same file. If I program the msp 4x in a row with the same file, sometimes 1. happens, other times 2. happens


Problem 2:

If I have a global variable declared as:

const struct my_struct_t my_struct = {
    &my_element_1,
    &my_element_2,
    &my_element_3
};

The addresses stored in the struct are correct after the program is flashed, but not after a power cycle.

Seems the memory is not being initialized the second time.


I think both problems are related, but I can't figure out what I'm missing...

  • Hi Eduardo,

    To clarify, in problem 1, item number 4 occurs with both the .elf and the .hex file? In other words, the device always stops about 1 second after a power cycle?

    Also, when you say the device stops, could you elaborate a little more? Do you mean that the device jumps to the default handler, does the program execution hang, or something else?

    It is interesting to hear that you're getting different behavior depending on the ABI you use.

  • Hi Dylan, sorry for the misunderstanding.

    Problem 1, number 4 happens, independent of the file used and/or tool.

    However, it has 2 different behaviors.

    Sometimes the program simply hangs. Runs correctly (apparently) for ~1s and then just hangs. Even the timer I use for ticks stops.

    Other times it keeps running, seems to be running OK at first, but looks like it keeps resetting.

    I have a pin toggling on some parts of the program and can share some prints with the patterns as soon as I get back to the office.

    Under debug (mspdebug with tilib + gdb) I can't seem to catch a problem. I easily found a problem 2 workaround (although not a solution) but can't catch a problem 1 situation. Sometimes I step an operation and even the gdb server stops. Other times I break the program at ??? and can't step because the debugger doesn't know where the non-existent function ends (figures)

  • Thank you for clarifying Eduardo,

    Could you try reducing the optimization level that you are using? See if the issue goes away if you reduce the optimization level, or remove optimization altogether. If that does not help we will continue to look at this.

  • So something happened that made things worse?

    As you asked, I compiled with `--opt_level=off` and everything worked OK, so I started increasing the optimization too see where it started misbehaving.

    `--opt_level=4`: Boot OK -> Power cycle -> FAIL

    `--opt_level=off`: Boot OK -> Power cycle -> OK

    `--opt_level=0`: Boot OK -> Power cycle -> OK

    `--opt_level=1`: Boot OK -> Power cycle -> OK

    `--opt_level=2`: Boot OK -> Power cycle -> FAIL

    Figured from level 2 forward it would fail, but forgot to save the logic analyzer output so I went back to repeat everything.

    Only this time I got back to level 4 without anything failing...

  • That is interesting. Have you tried running this project with all of the default linker and compiler settings, and in opt level 4, to see if this issue still occurs? I am glad that reducing optimization helped but I'd like to know what the exact issue is/ what exactly the optimization settings are changing that result in the device hanging after a power cycle.

    Another thing that you can try is debugging the device, power cycling it, and then when the device hangs you can use the debugger to connect to the device while it is running to see where it hangs. This might help us reveal the issue. Let me know if you need instructions on how to connect to the running device. There are some debug settings you will have to adjust to prevent a reset on connection.

  • Hello Dylan,

    I tried compiling with as few flags as possible, but ended up needing to use the following

    CFLAGS    += --c99
    CFLAGS    += --silicon_version=mspx
    CFLAGS    += --silicon_errata=CPU21
    CFLAGS    += --silicon_errata=CPU22
    CFLAGS    += --silicon_errata=CPU40
    CFLAGS    += --code_model=large
    CFLAGS    += --data_model=large
    CFLAGS    += --printf_support=minimal
    CFLAGS    += --opt_level=1     #tried off -> 0 -> 1 -> 2
    CFLAGS    += --compile_only
    
    # Linker Flags
    LDFLAGS   += --silicon_version=mspx
    LDFLAGS   += --silicon_errata=CPU21
    LDFLAGS   += --silicon_errata=CPU22
    LDFLAGS   += --silicon_errata=CPU40
    LDFLAGS   += --code_model=large
    LDFLAGS   += --data_model=large
    LDFLAGS   += --printf_support=minimal
    LDFLAGS   += --run_linker        # Next flags are linker flags
    LDFLAGS   += --entry_point=_c_int00_noargs

    And as previous, from level 2 forward, the program doesn't wake correctly from boot

    As you can see in the following pictures, pic.1 and pic.2 should be the same, but this happens with opt_level>1

  • I see, thank you for trying that out.

    So in your images, it looks like increasing your optimization level is shortening your boot process (but only after power cycling the device)?

    My concern is that I am not aware of something in our optimization settings that should cause the change that you are seeing. Those compiler and linker flags all look fine to me as well. 

    It seems like something that should be saved to flash and persistent through a BOR is not being saved correctly. My initial suspicion was that the optimization level was combining with some flag you set to move important settings around in memory, but I do not see anything out of the ordinary in your flags. 

    Of course, you could leave your optimization lower but I understand why you would not want this. If you'd like to send me your code (through this post or via an e2e message) I might be able to tell you more but so far I am not able to tell what the exact issue is. 

  • Sorry Dylan,

    I couldn't actually send the project, however, the problem was fixed.

    The solution was somewhat anti-climatic...

    When searching for the cl430 documentation, I found this and saw in 4.3.7 that `-rom_model` was the default so I didn't use the flag.

    In the end, there was a newer user guide for cl430. In this guide there's no reference to a default and it seems the default is `-ram_model`...

    This was why nothing worked after a boot. There was no global variable initialization (faster boot time)

**Attention** This is a public forum