• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 78 subscribers
  • Views 2581 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430F5419A ISP Flash programming question

Igor Igor
Intellectual 675 points
Other Parts Discussed in Thread: MSP430F5419A

Hello.

I have a question regarding the MSP430F5419A ISP Flash programming.

We are running some code from the flash bank 2 (starting at 0x20000 address). This code programs flash bank0 (starting at 0x5c00).

This is achieved by first erasing the bank 0 (this code is working).

Than we program the bank 0 as follows:

for (i = 0; i < length; i++)
{
         FCTL1 = FWKEY+WRT; // Set WRT bit for write operation
        *flash_ptr = *val; // Write value to flash
          FCTL1 = FWKEY; // Clear WRT bit
         while(BUSY & FCTL3);
         FCTL3 = FWKEY+LOCK; // Set LOCK bit
         while (!(FCTL3 & WAIT));

        flash_ptr++;
        val++;
}

where flash_ptr points to the 0x5C00 on.

The question is: theoretically if the code is bug free and running from bank 2 (placed there by the help of #pragma location in IAR) can it work (except for the time consumption)? (we make sure that the interrupts are disabled during the whole loop)...

Additional question is: why sometimes on some boards (this happened twice in a raw) the operation succeeds but further on we got a "

Mon Nov 12, 2012 22:38:17: Security Fuse has been blow" and unable to program the MSP430 with the FET anymore?

Thank you very much.

Regards

Igor

  • 0
    Guru 227245 points

    Igor Igor said:
    Security Fuse has been blow

    For the FET, there is no difference between a blown security fuse and a device that doesn't respond. This is often caused by a firmware that causes a device reset before JTAG can attach and take over control. Maybe a WDT security key violation right at the start of main.
    Inthis case, there are several things that could be tried to revivie the chip: first, try to erase flash using a faster software than CCS (CCS-> FET interfacing is rather slow due to all the hardware abstraction layers between program and USB port). Sometimes, using the free Elprotronic software does help being the few µs faster.
    If this doesn't help, the other way is to connect to the MSP using the BSL (serial connection), as the BSL kicks in before executing the applicaiton code.

    About your othe rquestion:

    First, there is an erratum on some MSPs where a bank erase is supposed to let the CPU continue if running from ram or a different flash bank, but if it runs from a different flash bank, the system will crash. (I moved my bank erase + wait loop into ram as workaround)

    The write function looks not bad. However, both, flash_ptr and val* need to point to lower 64k since by default, pointers are 16 bit only. Unless you use large data model (with its increased code size and execution times). This is why flash write funciton for 20 bit address space are often written in assembly.

    However, there is no need to set and clear WRT bit for every byte. It is mroe efficient (especially on 5x family and its 32 bit write capabitily) to set WRT before the loop and clear it after - and copy all the data in one burst.
    Also, if the code runs from flash, ther ei sno need to wait for busy. TH eflash controller will push the CPU a 'JMP $' instruction as long as it is busy, and the CPU jumps on place.
    One important thing: while the flash is busy writing (or erasing!), interrupts must be globally disabled (cluear GIE), because the CPU would fetch the wrong ISR address (0x3fff) from the busy flash.

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

    Hi Jens-Michael


    Thanks a lot for the clarification.

    Jens-Michael Gross said:
    However, both, flash_ptr and val* need to point to lower 64k since by default

    Thanks a lot but will not the IAR option of medium data option taking care of that? Or shall I use a specific __data20_write intrisic?

    Jens-Michael Gross said:
    However, there is no need to set and clear WRT bit for every byte. It is more efficient (especially on 5x family and its 32 bit write capabitily) to set WRT before the loop and clear it after - and copy all the data in one burst.

    I did that in order to make sure that the flash programming time does not exceeds a tWrite as defined in user guide...Or did I misunderstand the meaning ? From the spec "

    The cumulative programming time, tCPT, must not be exceeded for any block. Each byte, word, or
    long-word write adds to the cumulative program time of a segment.

    "

    The point is if I leave WRT bit on I may find myself spending more than required time in write operation and thus exceed that time...Can u please clarify?

    And the last but not the least: I was wondering if the following idea can work:

    In bank2 there is a code together with main. Our MSP is connected to the SPI Flash where the code for bank0 and bank 1 is stored. I am writing a program that reads the memory and reprograms flash bank 0 and bank 1 while running from bank 2. Can this work ? (We can not use BSL since the image is received over the air and stored into the serial flash and hte device has no UART/USB).

    Thanks a lot for prompt answer.

    Regards

    Igor

  • 0 in reply to Igor Igor
    Guru 227245 points

    Igor Igor said:
    shall I use a specific __data20_write intrisic

    This is a really convenient intrinsic. Depending on whether you want to write a char, int or long, there are three intrinsics taking a long address and a data value of the specified type and generates the proper 20 bit assembly code. The opposite is __data20_read_xxx() which takes a long address value and returns a value of the type xxx read from this 20 bit address.
    However, these intrinsics aren't portable (well, inline assembly code also isn't directly portable due to different compiler syntax).
    Also, don't forget to disable interrupts around these intrinsics because they are designed for small code mode, where ISRs only save the lower 16 bit of processor registers (possibly destroying the intermediate 20 bit register contents while the intrinsic-generated assembly code executes)

    If you do not make heavy use of constants stord in flash >64k, the intrinsics are by far the better way of accessing the 'upper flash'. Large dat amodel adds a significant impact to all code (all push/pop operaitons are 32 bit instead of 16 bit, inlcuding those in ISRs. And all data pointers are 32 bit). It increases code size for 20 bit operations (one byte longer than 16 bit operations), execution time (at least one clock cycle more, two for each push/pop ) and storage space (more stack used for push/pop, larger memory foortprint of all poitner variables).

    So if this can be avoided, it should be avoided.

    Igor Igor said:
    I was wondering if the following idea can work:

    Yes, it can. However, since the vector table is in BANK0, there are no vectors at all (and no reset vector) when erasing Bank0. Any failure before this is reprogrammed will make the device stop working until reprogrammed using JTAG/BSL.

    It's better to put the management code into Bank 0, and the loaded content to Bank1+2. Then the managing code (the 'OS') can redirect the interrupt vectors to the code in Bank 1+2 ISRs (the 'real' vector table in bank 0 points to small functions that indirectly jump to the functions in Bank1/2). So the OS is never deleted, nor is the vector table.

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

    Hi Jens-Michael

    Thanks a lot for clarifications.

    Additional question is I reset WRT bit after each byte program to flash.

    I did that in order to make sure that the flash programming time does not exceeds a tWrite as defined in user guide...Or did I misunderstand the meaning ? From the spec "

    The cumulative programming time, tCPT, must not be exceeded for any block. Each byte, word, or
    long-word write adds to the cumulative program time of a segment.

    "

    The point is if I leave WRT bit on I may find myself spending more than required time in write operation and thus exceed that time...Can u please clarify?

    Thanks a lot 

    Igor

  • 0 in reply to Igor Igor
    Guru 227245 points

    Igor Igor said:
    I did that in order to make sure that the flash programming time does not exceeds a tWrite as defined in user guide...Or did I misunderstand the meaning ?

    The writ time is cumulative. It means total write time between two erase operations.
    the reason is that there are leakage currents when the programming voltage is on.Even bits that are not meant to be programmed will get some charge over time. If the total writ etime is exceeded, this charge may cause unprogrammed bits of this block to erroneously flip to 0. It make sno difference whether the voltage is applied in one block or with delays. Well, a delay of weeks may 'undo' some µs of programming time :)

    If you do some math, you can calculate how many write operations in total are allowed to a 64 byte block, no matter whether they are byte, word or dword operations. So writing a 4 byte takes more than 4 times the programming time a dword takes, due to the additional pre-programming delay for each write. Unless you use block write mode and have the writing code execute from ram (and the data source in RAM too). Then there is only one pre-programming delay for the whole block operation and byte to word timing is factor 4.

    To make things more complicated (well, actually it makes things more relaxed), the flash controller can group two 16 bit (word) writes to one dword write if done properly (dword aligned and low word written first). That's new with 5x family.

    Igor Igor said:
    The point is if I leave WRT bit on I may find myself spending more than required time in write operation and thus exceed that time...Can u please clarify?

    The time only counts for the actual writing operation, when the writing voltage is on (and the CPU is halted). The time needed for the loop itself and for reading the value to be written does not count. If the writing code runs from ram and block write mode is used, this is different. Here the time form the first write until clearign WRT or first write to a different block will count. However, it is still less (unless ou do unnecessary things in your write loop) because the pre-programming delay (during which the programming voltage is starting up and settling) only happens once and not for every write.

    On 1x/2x family, the maximum of write operations you could do to a 64 byte block was 56 writes or so. So writing 64 individual bytes was violating the maximum time limit (except for block write mode). Unfortunately, the original Ti demo code wasn't taking care of it either. I hope this has been changed since. On 5x family, there's plenty of time now.

    BTW: IIRC the cumulative write time applies to a 64 byte flash block while flash segments are 1 to 8 blocks (64 to 512 bytes)

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

    Thanks a lot Jens-Michael.

    I got your points...

**Attention** This is a public forum