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.

MSP430F5436 - Lost JTAG after ISP attempt

Other Parts Discussed in Thread: MSP430F5436

I've been working for the past couple days on developing an ISP strategy for use with the MSP430F5436.  I was testing and debugging this when suddenly I lost the ability to JTAG connect to the processor.  The firmware update strategy is given below.  Any ideas?

Procedure:
(1) Prepare for flash programming received - Erase Flash Bank1.
(2) Copy received program into Bank1 (program limited to 41kB, size of Bank0; does not occupy all of Bank1).
(3) CRC check Received program in Bank1.
(4) Call Flash write routine which resides in Flash area InfoD.
(5) Erase Bank0. Copy flash program from Bank1 to Bank0.
(6) Software reset processor.

  • From the MSP430F54xx errata sheet:

    FLASH30 Flash Module
    Function: Read disturb
    Description: There is a problem that affects how addresses are decoded for INFO memory, creating read disturb issues for code executed out of information memory.
    Workaround: No code should be executed from INFO memory. In addition, data stored in INFO memory can be accessed only using code executed from the lower 64K of the memory map. Such accesses to INFO memory are unaffected by the problem.

    FLASH32 Flash Module
    Function: Bank erase problems
    Description: A Bank Erase operation can also lead to the erase of the information memory of the selected bank, when there was a read from any information memory address before the dummy write.
    Workaround: Insert a dummy read from any MAIN memory address before the dummy write, which triggers the Bank Erase operation.

    FLASH34 Flash Module
    Function: Concurrent flash read during bank erase fails
    Description: Code residing in flash cannot be executed during a bank erase.
    Workaround: Place the code to be executed during bank erase in RAM.

    So the following things could have gone wrong:

    1. when executing the flash write (copy), teh flash write code may have executed random operations due to FLASH30 erratum.
    2. when doing the bank erase of the copy bank (bank 1), the system may have crashed, because the code that does the bank erase is in flash, so it tries to read flash while bank erase which fails. (FLASH34 erratum)
    3. when doing the bank erase of bank 0, the program in info memory may have been erased too, sicne the last flash access before doing hte dummy write was fething this instruciton form info mem. (FLASH32 erratum)

    Generally, putting the flash write code into info mem was not a bad idea. Unfortunately it doesn't work on the 54xx.

    To revive the processor, you may try to trigger a mass erase through BSL. It may bring the MSP back into a working state.

  • good stuff Jens, thanks much!  I'm actually embarrassed I forgot to reference the errata...

    Jens-Michael Gross said:
    So the following things could have gone wrong:

    #1when executing the flash write (copy), teh flash write code may have executed random operations due to FLASH30 erratum.

    I'll look at moving this routine into an unused bank of main Flash memory or, eeeeek, running from RAM to do the program update.

     

    Jens-Michael Gross said:
    #2 when doing the bank erase of the copy bank (bank 1), the system may have crashed, because the code that does the bank erase is in flash, so it tries to read flash while bank erase which fails. (FLASH34 erratum)

    Waiting for the flash busy to clear should help here right?

    while(FCTL3 & BUSY);                // Wait for erase cycle to complete

     

    Jens-Michael Gross said:
    #3 when doing the bank erase of bank 0, the program in info memory may have been erased too, sicne the last flash access before doing hte dummy write was fething this instruciton form info mem. (FLASH32 erratum)

    Bank0 corresponds to InfoA, Bank1 to InfoB, etc. correct?  So if I'm erasing Bank0, InfoA might also be erased if I do not adhere to the FLASH32 errata note, also correct?

     

    Thanks for your help!

  • jdr said:
    while(FCTL3 & BUSY);                // Wait for erase cycle to complete

    Only if it is running from ram. If it runs from flash, it will crash during a bank erase, since on a bank erase it was planned to allow code form other banks to continue (so the usual 0x3fff jump-in-place is not simulated by the flash controller), but it doesn't work and the flash controller will deliver, well, I don't know, but usually not the code that will do the BUSY checking.
    In my own code, I moved a short code snipped to ram that does the write that starts the erase, then loops for BUSY and returns.

    jdr said:
    Bank0 corresponds to InfoA, Bank1 to InfoB, etc. correct?

    I don't know. really. This is the only place where I ever read about an info sector belonging to a flash bank. (But I could hav missed it). Also, all 54xx devices have the same number of info memories, but they have a different number (2 to 4) of main flash banks.

    But other errata seem to indicate that all info sectors beong the bank 0.
    However, if the last read access to flash was in main flash and not info flash, the info flash is not touched. If oyu put your cod einto info flash and move the erase code to ram, then this erase code should do a dummy read to main flash before doign the dummy write for starting the erase, and all should be well.

    jdr said:
    So if I'm erasing Bank0, InfoA might also be erased if I do not adhere to the FLASH32 errata note, also correct?

    I'd say, yes. And maybe all other info sectors too, as I realll don't know what 'belongs' where.

**Attention** This is a public forum