• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 79 subscribers
  • Views 835 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.

Remote programming: in-system flash programming and reset issues

Alex Asvestopoulos
Prodigy 140 points
Other Parts Discussed in Thread: MSP430F1611

Greetings Community,

I am currently developing a "Remote programming protocol" via wireless code update for msp430f1611 platform, facing some issues that need to be solved.

1. In order to use block write to flash, I need some code to run from RAM. As indicated here: http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/42302.aspx by mr William Goh's response (code .zip),  all I need to do is :

a) modify the linker command file as follows:

MEMORY
       {
         ...

         RAM_MEM         : origin = 0x1900, length = SIZE_OF_CODE
         ...
       }

       SECTIONS
       {
         ...     
         .RAMCODE   : {} > RAM_MEM     
         ...
       }

b)  include a PRAGMA directive in the source file, just before the definition of function to be run from RAM:

#pragma CODE_SECTION(ram_func,".RAMCODE")

void ram_func(...) {
  ...

}

This way I don't need to copy the ram_func at runtime to RAM, right?

2. What is the correct/safe Flash timing generator frequency for msp430f1611? I've looked through documentation, but haven't found anything more specific
than the constraint : 257KHz <= FTG_freq <= 476 KHz.

3. After I have copied the whole code image into flash (all main prog mem sections: .text, .const, .cinit etc, as well as the interrupt vector), what kind of reset
should I generate (PUC, POR?) and how can I do this in-system-wise ?

Thank you in advance.

  • 0
    Guru 227245 points

    Alex Asvestopoulos said:
    a) modify the linker command file as follows:

    It should be possible to go even without this. There's already a linker segment that gets copied from flash to ram on startup: the initialized variables segment. It's not 'clean' to put code into a variables segment, but sinc eboth share the same limited ram anyway (no 'protection' of any kind for the ram code) it doesn't hurt.

    So just use the pragma with the initialized data segment name and it should work.

    Alex Asvestopoulos said:
    What is the correct/safe Flash timing generator frequency for msp430f1611

    Any frequency within the given range. Keep an eye on the maximum cumulative programming time. For ram->flash block writes, this is unimportant, for single writes, slower frequencies might exceed the allowed time, especially when writing bytes.

    Alex Asvestopoulos said:
    what kind of reset should I generate (PUC, POR?) and how can I do this in-system-wise ?

    best would be a POR, but it cannot be done in softwre only from the 1611. If your code is properly written, it is sufficient to trigger a PUC. It won't reset all modules (e.g. timers and timer interrupts remain active - just blocked by GIE), but if your code initializes everything at startup before setting GIE, then a PUC will be fine.
    A PUC can be forced by writing to the WDT config or the Flash controller without the password.

    5x family MSPs have a way to trigger a BOR or POR through the power management module.

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

    Jens-Michael Gross said:

    a) modify the linker command file as follows:

    It should be possible to go even without this. There's already a linker segment that gets copied from flash to ram on startup: the initialized variables segment. It's not 'clean' to put code into a variables segment, but sinc eboth share the same limited ram anyway (no 'protection' of any kind for the ram code) it doesn't hurt.

    So just use the pragma with the initialized data segment name and it should work.

    [/quote]

    Ok. I think I'll go with the "cleaner" solution of modifying the command file though.

    Jens-Michael Gross said:
    What is the correct/safe Flash timing generator frequency for msp430f1611

    Any frequency within the given range. Keep an eye on the maximum cumulative programming time. For ram->flash block writes, this is unimportant, for single writes, slower frequencies might exceed the allowed time, especially when writing bytes.

    [/quote]

    Do you mean I should be careful not to exceed cumulative prog. time in case I write more than one blocks without reseting the flash controller at the end of each block write (clear and resetting flash registers) ? Is it safe if I follow the programm flow shown in slau049F pages 5-12,13 ?
    btw, the code in slau049F(page 5-13) assumes that ACCVIE = 0. Is there anything I should do to ensure that?

    Jens-Michael Gross said:
    what kind of reset should I generate (PUC, POR?) and how can I do this in-system-wise ?

    best would be a POR, but it cannot be done in softwre only from the 1611. If your code is properly written, it is sufficient to trigger a PUC. It won't reset all modules (e.g. timers and timer interrupts remain active - just blocked by GIE), but if your code initializes everything at startup before setting GIE, then a PUC will be fine.
    A PUC can be forced by writing to the WDT config or the Flash controller without the password.

    5x family MSPs have a way to trigger a BOR or POR through the power management module.

    [/quote]

    I need to look this up a bit more, because the application code is not written by me.

     

  • 0 in reply to Alex Asvestopoulos
    Guru 227245 points

    Alex Asvestopoulos said:
    I think I'll go with the "cleaner" solution of modifying the command file though.

    I tmakes no differen e whether your code is behind or between the variables. An improper write (e.g. an array index out of bounds) will overwrite it in both cases. The problem with linker command files is that they are replaced with each new compiler version,a trhey belong to the compiler and not to the project. Also, when forwarding a project to someone else, he also needs to change his comamnd files.
    And last, usualyl you have one set of command files per processor. Depending ont he compiler suite, a change in them will change the layout for any other project with the same processor or processor group.

    Alex Asvestopoulos said:
    Do you mean I should be careful not to exceed cumulative prog. time in case I write more than one blocks

    No, the cumulative time counts for each block separately. But while a slow clock will still write proper flash write results, it may be that you cannot write the whole block without exceeding the maximum time. Won't hurt if you just want to write a few data bytes into an info sector. in fact, it is impossible to write 64 single bytes without exceeding the maximum time. The demo code from TI does it :( However, the result might be that data integrity is only 50 and not 100 years. :)

    Alex Asvestopoulos said:
    I need to look this up a bit more, because the application code is not written by me.

    You can always connect a port pin with the reset pin and pull the pin low if you want a real BOR (the BOR will release the pin to high-impedance input again). :)

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

    Jens-Michael Gross said:

    I tmakes no differen e whether your code is behind or between the variables. An improper write (e.g. an array index out of bounds) will overwrite it in both cases. The problem with linker command files is that they are replaced with each new compiler version,a trhey belong to the compiler and not to the project. Also, when forwarding a project to someone else, he also needs to change his comamnd files.
    And last, usualyl you have one set of command files per processor. Depending ont he compiler suite, a change in them will change the layout for any other project with the same processor or processor group.

    Fair enough. So, I just place the desired function in the .bss section with the PRAGMA directive and that's all?

    Jens-Michael Gross said:

    No, the cumulative time counts for each block separately. But while a slow clock will still write proper flash write results, it may be that you cannot write the whole block without exceeding the maximum time. Won't hurt if you just want to write a few data bytes into an info sector. in fact, it is impossible to write 64 single bytes without exceeding the maximum time. The demo code from TI does it :( However, the result might be that data integrity is only 50 and not 100 years. :)

    According to the examples in SLAA334A page 6, I can commit a block write (edit: or even 32 word writes) without exceeding the Cumulative program time (unless the value of 10ms is too optimistic!).

  • 0 in reply to Alex Asvestopoulos
    Guru 227245 points

    Alex Asvestopoulos said:
    I just place the desired function in the .bss section with the PRAGMA directive and that's all?

    Should be, yes. Unless (and that's specific to the toolchain) there are other limitations placed on .bss that prohibit this, but you'll see if the linker complains. If not, that's all.

    Alex Asvestopoulos said:
    I can commit a block write (edit: or even 32 word writes) without exceeding the Cumulative program time

    Yes, a block write should always work (if not, you were unable to program teh flash at all). The write time is only important if your code is slow with writing (you don't necessarily have to do the individual writes as fast as you can - your code might do something else (in ram) while a word is being flashed.) or if you don't use block write. For a fast block write (next word written as soon as the controlle rreports last write done), even the slowest clock will be okay.

    The reason for the cumulative write time is that there is no perfect insulation. Whiel the programming voltage is attached to a block, ALL cells might catch one or another electron, whether you write a '0' or not. So after a certain time, the worst case amount of trapped charge may reach a level where even unprogrammed bits might appear as '0'. Or (depending on the internal signalling) the natural depletion of trapped charges in the programmed cells will sooner reach the level of these partially charged cells, causing errant reads after soem time (but sooner as the specs tell).
    However, with the next erase, these effets are nullified and it does not cause permanent damage. But may add to the wear-out over time (reducing thmaximum number of programming cycles).

    All this is just an interpretation based on available info and notes and some intelligent guessing, but not authoritative, as I don't know how TI has implemented the flash internally.

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

    Ok. I'm covered. Thank you for your immediate answers.

**Attention** This is a public forum