• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 80 subscribers
  • Views 1698 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.

MSP430 Firmware update from external sdcard

Troy Johnson
Intellectual 555 points

Other Parts Discussed in Thread: MSP430F5418

I've done a bit of searching, but haven't found if this sort of thing is possible with the MSP430.  I'm specifically using the MSP430F5418.  What I would like to do is store a new firmware on the sdcard that is attached to one of the SPI interfaces.  Then update the micro's firmware using this new firmware file.  Is such a thing possible?  If so is there any information available that would document how I would start doing this?

As always any help would be appreciated!

  • 0
    Guru 46710 points

    Troy Johnson said:
    Then update the micro's firmware using this new firmware file.  Is such a thing possible?

    Yes. You have to write your "SD card bootloader" - part of firmware which reads file and program flash.

    Troy Johnson said:
    If so is there any information available that would document how I would start doing this?

    Dunno. When you finish developing your SDcard bootloader, you can write such document ;) Well.. there is one document:  SLAA103 - MSP430 Flash Self-Programming Technique.

  • 0 in reply to Ilmars
    Intellectual 555 points

    That is exactly what I was looking for.  Thanks so much.

  • 0 in reply to Troy Johnson
    Guru 227245 points

    The tricky thing is: when you have the new firmware stored on SD card as a file, the bootloader needs to implement a file system driver etc. Which makes the bootloader quite big.
    It might be easier to put the new firmware onto raw data sectors on the card. Starting at first card sector and then sequentially.
    Well, easier on the MSP side, but more difficult to put the firmware on it from a PC. :)

  • 0 in reply to Jens-Michael Gross
    Intellectual 555 points

    Yes, after reading through the app note and playing around with a few things yesterday, I now understand how complicated of a problem it is.  With so much code it is hard to determine what pieces need to be copied to RAM.

    Would it be possible to load an entire application into RAM? Then run it from there?  I have plenty of RAM, I'm just not sure how to do that sort of thing.

  • 0 in reply to Troy Johnson
    Guru 227245 points

    In theory, it is possible to put an entire application into ram and run it from there. On 5x family devices, even the vector table can beput into ram and use from there (allowing interrupts active during flash write operations).

    However, this is not the usual case, and the linker scripts won't handle this. Even though you can declare all funcitons as ram-based, the startup code will still be placed in flash, the constants will (in case of implicit constants like the parameter tring of a printf call, this cannot be avoided), the stack init won't reserve space for the vector table etc. Quite some work to do. But possible.

    In Theory, you can replace all function calls by function pointer calls, using a address table. Then you can opy the whole application from flash to ram and only have to adjust the offset in the jumptable and the interrutpt vector table.

    I guess I have described this idea in an old thread, as a way to dynamically load a library from SD card into a running applicaiton.

  • 0 in reply to Jens-Michael Gross
    Intellectual 555 points

    So far I'm making good progress on making this work.  I have about a dozen functions that I'm copying from Flash into RAM and then running those functions from RAM.  To start with, I erase the flash segments the main code normally runs from.  After this my functions continue to work (they did not work at first, when I had a bug with the offsets, the functions would not run at all, it would crash)

    My code reads a .txt file from an SD card  and writes the correct values to the flash address. Everything seems to be working (memory locations are being updated correctly) for about 30 % of my txt file (over 6000 bytes).  At this time, things come to a screeching halt and the program crashes... acting as it did when I didn't have my function addresses setup up correctly.

    I'm thinking that my program must still be trying to access something in flash (I'm just lucky that the erased state of the flash 0xFF works) until I over write that value.

    Jens-Michael Gross mentioned that implicit constants will remain in the flash.  I've tried to limit these, but maybe I've missed some?

    If I define something like this:

    #define SIZE  512

    then loop on size

    for  (i=0; i<SIZE; i++) { }

    Will SIZE be placed in flash?  I have a bunch of constants like this, do I need to move them inside of the functions and change them to

    for  (i=0; i<512; i++) { }

    Is there a way to know if something is being placed in flash?

    Thanks

    Troy

  • 0 in reply to Troy Johnson
    Intellectual 555 points

    OK, I tracked this down a bit more.  The problem comes about as I overwrite this portion of the flash that has these functions in them:

    0000608a __mspabi_sral_15
    0000608e __mspabi_sral_14
    00006092 __mspabi_sral_13
    00006096 __mspabi_sral_12
    0000609a __mspabi_sral_11
    0000609e __mspabi_sral_10
    000060a2 __mspabi_sral_9
    000060a6 __mspabi_sral_8
    000060aa __mspabi_sral_7
    000060ae __mspabi_sral_6
    000060b2 __mspabi_sral_5
    000060b6 __mspabi_sral_4
    000060ba __mspabi_sral_3
    000060be __mspabi_sral_2
    000060c2 __mspabi_sral_1
    000060c8 __mspabi_slll_15
    000060cc __mspabi_slll_14
    000060d0 __mspabi_slll_13
    000060d4 __mspabi_slll_12
    000060d8 __mspabi_slll_11
    000060dc __mspabi_slll_10
    000060e0 __mspabi_slll_9
    000060e4 __mspabi_slll_8
    000060e8 __mspabi_slll_7
    000060ec __mspabi_slll_6
    000060f0 __mspabi_slll_5
    000060f4 __mspabi_slll_4
    000060f8 __mspabi_slll_3
    000060fc __mspabi_slll_2
    00006100 __mspabi_slll_1
    00006106 __mspabi_srll_15
    0000610a __mspabi_srll_14
    0000610e __mspabi_srll_13
    00006112 __mspabi_srll_12
    00006116 __mspabi_srll_11
    0000611a __mspabi_srll_10
    0000611e __mspabi_srll_9
    00006122 __mspabi_srll_8
    00006126 __mspabi_srll_7
    0000612a __mspabi_srll_6
    0000612e __mspabi_srll_5
    00006132 __mspabi_srll_4
    00006136 __mspabi_srll_3
    0000613a __mspabi_srll_2
    0000613e __mspabi_srll_1

    I'm not sure what these functions are?  Do I need to move them to RAM?

  • 0 in reply to Troy Johnson
    Prodigy 90 points

    IMHO, the defines will be expanded at preprocessor stage, there is no benefit of changing this:

    #define SIZE  512

    for  (i=0; i<SIZE; i++) { }

    to this:

    for  (i=0; i<512; i++) { }


  • 0 in reply to Troy Johnson
    Guru 227245 points

    For 'SIZE', Vladimir is right.

    "Implicit constants" referred to inlined constant arrays, such as the format string in printf("%d",128). Constant integers are used as immediate values instead (merged directly into the CPU instructions).

    Those srll etc. functions (these are only 3 functions, but with multiple entry points) are for shifting signed and unsigned integers and long values by multiple bits. The MSP does nto have multiple-bit shift operations (especially not for long values that span two words)

    if a value needs to be shifted right by 10 bit, the compiler makes a funciton call to __mspabi_srll_10, where it falls through the following 9 'entry points', shifting one bit at a time, until the function returns after __mspabi_srll_1.
    IMHO, srll means "shift right logically long" (for unsigned long values). 'sral' stands for 'shift right arithmetically long' for signed values. For left shift, logical (binary) and arithmetical shifts are the same, hence no 'slal'.

**Attention** This is a public forum