Problem after moving div16u into RAM

I'm sorry, I have no idea what the problem could be.  Please show us your complete command line options and post your linker map file (generated with the --map_file linker option).  When you say you are moving div16u, is that a symbol or file name?  There is no such symbol in the C compiler's RTS, but there is a file named div16u.obj.

I am talking about the file.  The line in the .cmd file is:

.text:rts430x.lib_div16u : { rts*.lib<div16u.obj>(.text) }      load = FLASH_CODE_RAM, run = HIGH_RAM

Same as for all the other entries (div16s, etc).  Also:

    HIGH_RAM                     : origin = 0xF0000, length = 0xC000
    FLASH_CODE_RAM     : origin = 0x16000, length = 0x0B000

A partial list of the map (showing those libraries that have no problem running there):

.text:rts430x.lib_div32u
*          0    00018194    00000058     RUN ADDR = 000f2194
                  00018194    00000058     rts430x_lc_ld_eabi_eh.lib : div32u.obj (.text)

.text:rts430x.lib_newhandler
*          0    000181ec    00000048     RUN ADDR = 000f21ec
                  000181ec    00000026     rts430x_lc_ld_eabi_eh.lib : newhandler.obj (.text:_Z21__default_new_handlerv)
                  00018212    00000016                               : newhandler.obj (.text:_ZNSt9bad_allocC1EPKc)
                  00018228    0000000a                               : newhandler.obj (.text:_ZNSt9bad_allocD0Ev)
                  00018232    00000002                               : newhandler.obj (.text:_ZNSt9bad_allocD1Ev)

.text:rts430x.lib_div32s
*          0    00018234    00000040     RUN ADDR = 000f2234
                  00018234    00000040     rts430x_lc_ld_eabi_eh.lib : div32s.obj (.text)

.text:rts430x.lib_div16s
*          0    00018274    0000002c     RUN ADDR = 000f2274
                  00018274    0000002c     rts430x_lc_ld_eabi_eh.lib : div16s.obj (.text)

.text:rts430x.lib_mul32
*          0    000182a0    00000022     RUN ADDR = 000f22a0
                  000182a0    00000022     rts430x_lc_ld_eabi_eh.lib : mult32_f5hw.obj (.text)

I am using large code and large data model, no near globals.  Compiler command line:

-vmspx --abi=eabi --code_model=large --data_model=large --near_data=none -O4 --opt_for_speed=5 --include_path="/home/swdev/ti/ccsv6/ccs_base/msp430/include" --include_path="/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.2/include" --advice:power="all" --symdebug:none --gcc --define=__MSP430F5659__ --define=NO_PRINT --diag_warning=225 --display_error_number --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --large_memory_model --printf_support=minimal --check_misra="3"

Linker command line:

-vmspx --abi=eabi --code_model=large --data_model=large --near_data=none -O4 --opt_for_speed=5 --advice:power="all" --symdebug:none --gcc --define=__MSP430F5659__ --define=NO_PRINT --diag_warning=225 --display_error_number --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --large_memory_model --printf_support=minimal --check_misra="3" -z -m"Implant.map" --heap_size=1000 --stack_size=1000 --use_hw_mpy=F5 --cinit_hold_wdt=on -i"/home/swdev/ti/ccsv6/ccs_base/msp430/include" -i"/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.2/lib" -i"/home/swdev/ti/ccsv6/tools/compiler/msp430_4.3.2/include" -i"/home/swdev/ti/ccsv6/ccs_base/msp430/lib/5xx_6xx_FRxx" --reread_libs --warn_sections --display_error_number --diag_wrap=off --xml_link_info="Implant_linkInfo.xml" --rom_model

Thank you,
Pibe

Pibe said:

The RELEASE version (with debugging symbols suppressed) keeps rebooting unless either I do not move div16u into RAM

Please show exactly what you change to cause div16u to not move into RAM.

Thanks and regards,

-George

Do you know if it crashes in the process of throwing an exception?  Has the program thrown any exceptions before the crash occurs?  Consider bumping up the size of the heap and stack to see if it alters the program's behavior.

George,

I just comment out the line in the .cmd file.  Then I can see in the .map file that its not moved.

Thanks,

Pibe

Archaeologist,

I had stepped on the assembly list and could not see it throwing.  I had increased the size of the stack (not the heap which was already 1,000 bytes) with no avail.  Still, the test of commenting out all libraries but div16u (fails) and only commenting out div16u (works) is pretty conclusive.  I will try anyway to increase the heap and let you know, I see the reasoning behind.

Thanks,

Claudio

No effect.  For now I will move on and leave the library div16u behind (in FLASH).  I would appreciate you guys letting me know should you uncover something.

Thank you,

Pibe

It actually worked!

The problem was that CCS6 had closed unexpectedly (it does it several times a day, along with the awful problem of reverting to Free License and silently producing a botched binary without giving the warning that one has exceeded the limit for free license) and so the change in heap was not held.  Now the sizes for both heap and stack are 1,000 bytes (which, coincidentally, are the sizes in the Debug version.  Somehow the Release stack remained at 400 bytes and that seems to cause the problem).

Thank you very much, Archaeologist.

Pibe

1000 bytes of heap is kind of small for a C++ program with exceptions enabled, and 400 bytes is surprisingly small, particularly considering you're using large data model.

Agreed.  Still in development though, no stack size analysis yet.

Thank you,

Pibe