• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 81 subscribers
  • Views 1995 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Executing from flash memory location >64k (MSP430 F5438A)

Venkat Ramshankar
Prodigy 190 points
Other Parts Discussed in Thread: MSP430F5435

Hi,

I was going through the flash memory organisation of F5438A and seems like the code memory can be placed in 0x5C00 - 0xFF7F and 0x40000 - 0x45BFF of Bank0. I saw the linker command file generated with the CCS setting the default flash origin to 0x5C00, so I changed it to 0x40000. I am able to build the code and map file says that the c_int00 entry point is at 0x40000. 

I have built the application with both --code_model and --data_model options to be 'large' and even tried to use the run time support libraries. The MCU is not able to execute the code from the location. 

Interesting part is, if I pause the execution and set the PC manually to 0x40000, the debugger complains that 'no source was found at the location' and when resumed able to execute the code (Blink LED example).

There is a small compiler or linker option I am missed I guess. It would be a great help if anyone can point out my mistake.

Thanks,

-Venkat.

  • 0
    Guru 227245 points

    I tmight be a problem with the 'binary' file.

    One of the file formats used to contain the binary data doesn't support 20 bit addresses. It just generates 0x0000 for 0x10000 or 0x20000 The programming software uses a workaround where simply 0x10000 is added each time the address goes back below the current address. This workaround fails if there are holes >64k in the programmed range.

    This would mean that probably your code linked to 0x40000 was programmed to 0x10000. Just a guess.

    BTW: code can be placed into all 256k of flash. So unless you want to preserve bank 1-3 for other means, allowing a bank erase operation on bank 1.3 without having code erased, you may well put oyur additional code into 0x10000.

    Venkat Ramshankar said:
    if I pause the execution and set the PC manually to 0x40000, the debugger complains that 'no source was found at the location'

    That's indeed strange.

    Venkat Ramshankar said:
    and when resumed able to execute the code (Blink LED example).

    It's possible that the code execution at 0x40000 causes a violation interrupt, which in turn causes the NMI vector to be read (which contains 0xffff as there is no NMI ISR) and then executes the code at 0xfffe and 0x10000, which is your code. If your code doesn't contain any calls (whcih woudl jump tto the wrong location then), it will run. Again just a guess.

    I think you're the frst one putting code into 0x40000 without anyting in the 192k below. :)

  • 0 in reply to Jens-Michael Gross
    Prodigy 190 points

    Hi Jens-Michael Gross,

    Thanks for your reply.

    1. Yes, I was observing that the addresses in Intel-hex format files were having only 0x0000 for addresses more than 64k.. I remember seeing some code bytes on the 0x40000 address using the memory browser tool, so I am not sure if the program was flashed in 0x10000 or 0x40000.

    2. I will have to check again for the NMI being generated or not. I will get back on this and verify..

    I was just interested to know whether my main() will work in that location for a trial :). It is also good to know that I can execute from any location from the flash ( which means -vmspx compliant devices can "address" the complete flash. )

    Thanks,

    -Venkat.

  • 0 in reply to Venkat Ramshankar
    Guru 227245 points

    Venkat Ramshankar said:
    It is also good to know that I can execute from any location from the flash

    There are two limitations: the code needs to be compiled using the CALLA and RETA isntructions, so it will use a 20 bit destination, and put a 20 bit return address on stack. This includes th ecomplete code, even if placed in lower 64k (as it still needs to to a RETA isntead of a RET to return to an upper memory caller). Also, all ISRs (at least their entry points) and the startup code need to be placed in lower 64k, as the interrupt vectors are 16 bit only.

  • 0 in reply to Jens-Michael Gross
    Prodigy 190 points

    Hi Jens-Michael Gross,

    Thanks for the reply.. It is really a helpful information. I will check about the compiler options for CALLA and RETA instructions.

    Thanks,

    -Venkat.

  • 0 in reply to Venkat Ramshankar
    Guru 227245 points

    The use of CALLA and RETA, the use of 32 bit function pointers and the linker setting that can place non-ISR code into upper memory are the main differences between small and large code model.

  • 0 in reply to Jens-Michael Gross
    Prodigy 190 points

    Hi,

    Is there a way to generate a hex file with 20bit address format ? I think TI-TXT file format supports 20bit addressing, but has a larger size compared to the hex format. 

    A hex file with 20bit addressing mechanism would be best solution, else will have to go with TI-TXT.

    Thanks,

    -Venkat.

  • 0 in reply to Venkat Ramshankar
    Guru 227245 points

    Venkat Ramshankar said:
    Is there a way to generate a hex file with 20bit address format

    I don't think so. The only thing I can imagine is putting 'dummy' constants (content 0xff) into each 64k segment, so the programming software can do the proper counting.

    Since the HEX file format was designed 16 bit, no software (except some yet to write) will support larger values. But I may be wrong here.

  • 0 in reply to Jens-Michael Gross
    Prodigy 190 points

    Hi Jens-Michael Gross,

    Thanks for your replies and suggestions. I would better go with TI-TXT format then.

    Thanks,

    -Venkat.

  • 0 in reply to Jens-Michael Gross
    Guru 25210 points

    Jens-Michael Gross said:

    Is there a way to generate a hex file with 20bit address format

    I don't think so. The only thing I can imagine is putting 'dummy' constants (content 0xff) into each 64k segment, so the programming software can do the proper counting.

    Since the HEX file format was designed 16 bit, no software (except some yet to write) will support larger values. But I may be wrong here.

    [/quote]Actually the Intel-hex format has supported (for as long as I can remember, at least since 1993) extended addressing mode. The IAR tools can output this format. In the Linker options, Extra Output Tab, select Output format to "Intel Extended"

  • 0 in reply to Venkat Ramshankar
    Guru 34753 points

    Venkat Ramshankar said:

    Thanks for your replies and suggestions. I would better go with TI-TXT format then.

    I am also using TI TXT format for MSP430F5435

    http://forum.43oh.com/topic/2972-sbw-msp430f550x-based-programmer/?p=34353

  • 0 in reply to Brian Boorman
    Prodigy 190 points

    Brian Boorman said:

    Is there a way to generate a hex file with 20bit address format

    I don't think so. The only thing I can imagine is putting 'dummy' constants (content 0xff) into each 64k segment, so the programming software can do the proper counting.

    Since the HEX file format was designed 16 bit, no software (except some yet to write) will support larger values. But I may be wrong here.

    [/quote]Actually the Intel-hex format has supported (for as long as I can remember, at least since 1993) extended addressing mode. The IAR tools can output this format. In the Linker options, Extra Output Tab, select Output format to "Intel Extended"

    [/quote]

    I was using Code Composer Studio from TI which was supporting TI-TXT and Intel hex (not Extended) formats. I completed the solution with TI-TXT format. 

  • 0 in reply to Venkat Ramshankar
    Guru 25210 points

    Venkat Ramshankar said:
    I was using Code Composer Studio from TI which was supporting TI-TXT and Intel hex (not Extended) formats. I completed the solution with TI-TXT format.

    Yes, I understood that. I was just pointing out a solution for those who do use IAR. I came across this while trying to solve my own 5438A flash-related information.

**Attention** This is a public forum