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.

MSP430F2272: Timing for JTAG Flash Writing, SLAU320 code

Part Number: MSP430F2272
Other Parts Discussed in Thread: MSP430F5437

Hi,

a customer is using the 

And specifically the erase and write functions similar to the functions in 

C:\TI\MSP430ProgrammingWithJTAG-slau320ad\slau320w\Replicator430X\JTAGfunc430X.c

void WriteFLASH_430X(unsigned long StartAddr, unsigned long Length, word *DataArray)

void EraseFLASH_430X(word EraseMode, unsigned long EraseAddr)

The intent is to write a 32KB segment of Flash in one go with this function. 

The question is whether the a timing in the datasheet is violated using this type of WRITE function. 

The Table "Flash Memory" on page 56 of the datasheet specificies a tCPT Cumulative Write Timing:

The cumulative program time must not be exceeded when writing to a 64-byte flash block. This parameter applies to all programming methods: individual word/byte write and block write modes.

If we take a look at the WRITE function with the IR and DR shifts, we are concerned that these writes are much slower than tCPT required by the datasheet.

void WriteFLASH_430X(unsigned long StartAddr, unsigned long Length, word *DataArray)
{
word i; // Loop counter
unsigned long addr = StartAddr; // Address counter
word FCTL3_val = SegmentInfoAKey; // Lock/Unlock SegA InfoMem Seg.A, def=locked

HaltCPU();

ClrTCLK();
IR_Shift(IR_CNTRL_SIG_16BIT);
DR_Shift16(0x2408); // Set RW to write
IR_Shift(IR_ADDR_16BIT);
DR_Shift20(0x0128); // FCTL1 register
IR_Shift(IR_DATA_TO_ADDR);
DR_Shift16(0xA540); // Enable FLASH write
SetTCLK();

ClrTCLK();
IR_Shift(IR_ADDR_16BIT);
DR_Shift20(0x012A); // FCTL2 register
IR_Shift(IR_DATA_TO_ADDR);
DR_Shift16(0xA540); // Select MCLK as source, DIV=1
SetTCLK();

ClrTCLK();
IR_Shift(IR_ADDR_16BIT);
DR_Shift20(0x012C); // FCTL3 register
IR_Shift(IR_DATA_TO_ADDR);
DR_Shift16(FCTL3_val); // Clear FCTL3; F2xxx: Unlock Info-Seg.
// A by toggling LOCKA-Bit if required,
SetTCLK();

ClrTCLK();
IR_Shift(IR_CNTRL_SIG_16BIT);

for (i = 0; i < Length; i++, addr += 2)
{
DR_Shift16(0x2408); // Set RW to write
IR_Shift(IR_ADDR_16BIT);
DR_Shift20(addr); // Set address
IR_Shift(IR_DATA_TO_ADDR);
DR_Shift16(DataArray[i]); // Set data
SetTCLK();
ClrTCLK();
IR_Shift(IR_CNTRL_SIG_16BIT);
DR_Shift16(0x2409); // Set RW to read

TCLKstrobes(35); // Provide TCLKs, min. 33 for F149 and F449
// F2xxx: 29 are ok
}

IR_Shift(IR_CNTRL_SIG_16BIT);
DR_Shift16(0x2408); // Set RW to write
IR_Shift(IR_ADDR_16BIT);
DR_Shift20(0x0128); // FCTL1 register
IR_Shift(IR_DATA_TO_ADDR);
DR_Shift16(0xA500); // Disable FLASH write
SetTCLK();

// set LOCK-Bits again
ClrTCLK();
IR_Shift(IR_ADDR_16BIT);
DR_Shift20(0x012C); // FCTL3 address
IR_Shift(IR_DATA_TO_ADDR);
DR_Shift16(FCTL3_val | 0x0010); // Lock Inf-Seg. A by toggling LOCKA and set LOCK again
SetTCLK();

ReleaseCPU();
}

Regards,

--Gunter

  • Hi,

    the customer notes that the TCK (TCLK) for the JTAG is set to 327kHz.

    With this could you help estimate the time spent for Flash writing (say given the SLAU320 flash writing function) and whether this would violate the tCPT from the F2272 datasheet?

    Thanks!

    --Gunter

  • Hi Gunter,

    We do not have anyway to easily give this estimate. I suspect that they will need to divide up their writes into multiple chunks in order to not violate the cumulative program time.

    Also, is there a specific reason why they are using the replicator code to do this? Have looked at using the boot loader (BSL) instead? This is much simpler and would likely be a better fit, assuming the programming environment that they are using allows for this.

    Regards,
    Nathan
  • Hi Nathan,

    the customer's system is deployed and the infrastructure for JTAG based MSP430 programming of devices exists. The BSL cannot be retrofitted.

    Could you elaborate on your point to break up the writes into multiple chunks and how that eleviates the concern with the cumulative program time?


    Thanks!
    --Gunter
  • Hi Nathan,

    let me run by you an estimate for tCPT given the slau320 flash write function, and you could comment whether this is on the right track. Then I have an additional question about Flash segment (block) size of 64 bytes vs 512 bytes.

    Assumption:
    Customer reports TCLK of approx 327kHz

    The for loop in the JTAG based flash write function, each iteration writing 16-bit:

    for (i = 0; i < Length; i++, addr += 2)
    {
    DR_Shift16(0x2408); // Set RW to write
    IR_Shift(IR_ADDR_16BIT);
    DR_Shift20(addr); // Set address
    IR_Shift(IR_DATA_TO_ADDR);
    DR_Shift16(DataArray[i]); // Set data
    SetTCLK();
    ClrTCLK();
    IR_Shift(IR_CNTRL_SIG_16BIT);
    DR_Shift16(0x2409); // Set RW to read

    TCLKstrobes(35); // Provide TCLKs, min. 33 for F149 and F449
    // F2xxx: 29 are ok
    }

    Per iteration we have TCLKs
    [] 64 TCLKs for DR shifts
    [] 24 TCLKs for IR shifts
    [] 1 TCLK for set and clear
    [] 35 TCLKs to get ready for next
    TOTAL: 124 TCLK

    tCPT requirement per datasheet is max 10ms for 64 bytes (32 16-bit words)

    32*124 = 3968 TCLK + a some overhead = approx 4000 TCLK

    4000*(1/327kHz) = 12.2 ms

    So this is slightly above the datasheet requirement. The question would be how we could reduce this to sub 10ms.



    Now the other question about segment or block size:

    The note (1) from datasheet page 56
    (1) The cumulative program time must not be exceeded when writing to a 64-byte flash block. This parameter applies to all programming
    methods: individual word/byte write and block write modes.

    Page 18 of datasheet:
    The flash memory can be programmed via the JTAG port, the bootstrap loader, or in-system by the CPU. The
    CPU can perform single-byte and single-word writes to the flash memory. Features of the flash memory include:
    • Flash memory has n segments of main memory and four segments of information memory (A to D) of
    64 bytes each. Each segment in main memory is 512 bytes in size.

    Does the tCPT of 10ms apply to 64 bytes or 512 bytes??


    Thanks!
    --Gunter
  • Flash block size for 2xx is 64 bytes. To decrease tCPT, higher flash clock can be used (up to 476 kHz), or as noted by Nathan writing of 64 bytes can be splited in 2 WriteFLASH_430X calls.
  • Hi Gunter,

    As Zrno has said, my idea of multiple flash writes was to require less time for each write. the cumulative program time only applies to each write.

    As for your estimate, it makes sense to me, but again I cannot know for sure.

    Lastly, tCPT applies to the 64 byte block (not the 512 byte segment).

    Regards,
    Nathan
  • Hi Zrno/Nathan,

    when you say "higher flash clock can be used (up to 476 kHz)", do you mean the JTAG clock should not be higher than 476kHz? Right now the customer has it at 1MHz for IR and DR shifts. Is that too high? Is 1MHz too marginal?

    Also we need to confirm whether when we write to a 64byte segment, and write that partially due to tCPT, then come back to it and continue to write, would that add to the cumulative timing?

    There have been some flash failures at the customer, that is why we are trying to confirm these things.

    Thanks for the comments so far.

    Regards,

    --Gunter

  • I am working with 6 MHz SBW clock (this is not TCLK) without problems (limited to 3 MHz when 1nF cap on reset pin of target device is used). Per datasheet it can go up to 20 MHz. I guess (this should be confirmed by TI) that flash module clock (up to 476 kHz) become relevant only during TCLKstrobes periode, while IR / DR shifting clock inside loop relation with flash module clock is not important because it is idle period.

  • Hi Gunter,

    I believe that 1 MHz should be fine for what you are doing. And, if you do 2 separate flash writes, they will not add to the cumulative write time. However, you typically want to erase flash before writing to it again, so you may want the second write to be to a different block.

    Regards,
    Nathan
  • FlashTrace.txt
    DCO = 8 Mhz
    109976747 - jtagMsp430Dev_FlashInit(417) DCOCTL: 0x6f
    109976755 - jtagMsp430Dev_FlashInit(419) BCSCTL1: 0x8d
    109976762 - jtagMsp430Dev_FlashInit(421) BCSCTL2: 0x00
    
    FNx=0 -> SMClk source, 8 Mhz Clk, 1646 msec
    111476008 - jtagMsp430Dev_FlashErase(607) Start: 0x0000fc00 End: 0x0000ffff SegmentSize: 512
    111476071 - jtagMsp430Dev_FlashSegErase(503) FCTL1: 0x9602
    111476078 - jtagMsp430Dev_FlashSegErase(505) FCTL2: 0x9680
    111476086 - jtagMsp430Dev_FlashSegErase(507) FCTL3: 0x9648
    111476092 - jtagMsp430Dev_FlashSegErase(509) Start
    111477738 - jtagMsp430Dev_FlashSegErase(522) End
    
    FNx=0 -> SMClk source, 8 Mhz Clk, 9248 msec
    111480102 - jtagMsp430Dev_FlashWrite(641) Start: 0x0000fc00 Len: 1024 Src: 0x0048c630
    111480159 - jtagMsp430Dev_FlashWrite(657) FCTL1: 0x9640
    111480166 - jtagMsp430Dev_FlashWrite(659) FCTL2: 0x9680
    111480173 - jtagMsp430Dev_FlashWrite(661) FCTL3: 0x9648
    111480179 - jtagMsp430Dev_FlashWrite(663) Start
    111489427 - jtagMsp430Dev_FlashWrite(681) End
    
    FNx=1 -> SMClk source, 4 Mhz Clk, 3284 msec
    109976708 - jtagMsp430Dev_FlashErase(605) Start: 0x0000fc00 End: 0x0000ffff SegmentSize: 512
    109976771 - jtagMsp430Dev_FlashSegErase(501) FCTL1: 0x9602
    109976779 - jtagMsp430Dev_FlashSegErase(503) FCTL2: 0x9681
    109976786 - jtagMsp430Dev_FlashSegErase(505) FCTL3: 0x9648
    109976792 - jtagMsp430Dev_FlashSegErase(507) Start
    109980076 - jtagMsp430Dev_FlashSegErase(520) End
    
    FNx=1 -> SMClk source, 4 Mhz Clk, 17106 msec
    109984078 - jtagMsp430Dev_FlashWrite(639) Start: 0x0000fc00 Len: 1024 Src: 0x0048c630
    109984135 - jtagMsp430Dev_FlashWrite(655) FCTL1: 0x9640
    109984142 - jtagMsp430Dev_FlashWrite(657) FCTL2: 0x9681
    109984149 - jtagMsp430Dev_FlashWrite(659) FCTL3: 0x9648
    109984155 - jtagMsp430Dev_FlashWrite(661) Start
    110001261 - jtagMsp430Dev_FlashWrite(679) End
    
    FNx=25 -> SMClk source,  307 Mhz Clk, 42592 msec
    113025189 - jtagMsp430Dev_FlashErase(607) Start: 0x0000fc00 End: 0x0000ffff SegmentSize: 512
    113025251 - jtagMsp430Dev_FlashSegErase(503) FCTL1: 0x9602
    113025259 - jtagMsp430Dev_FlashSegErase(505) FCTL2: 0x9699
    113025266 - jtagMsp430Dev_FlashSegErase(507) FCTL3: 0x9648
    113025272 - jtagMsp430Dev_FlashSegErase(509) Start
    113067864 - jtagMsp430Dev_FlashSegErase(522) End
    
    FNx=25 -> SMClk source,  307 Mhz Clk,  205831 msec, 201 msec/byte
    113111160 - jtagMsp430Dev_FlashWrite(641) Start: 0x0000fc00 Len: 1024 Src: 0x0048c63c
    113111217 - jtagMsp430Dev_FlashWrite(657) FCTL1: 0x9640
    113111224 - jtagMsp430Dev_FlashWrite(659) FCTL2: 0x9699
    113111231 - jtagMsp430Dev_FlashWrite(661) FCTL3: 0x9648
    113111237 - jtagMsp430Dev_FlashWrite(663) Start
    113317068 - jtagMsp430Dev_FlashWrite(681) End
    
    
    Hi Guys,

    As per our phone conversation with Gunter, we are still having issues.  

    We have updated the Flash erase and write algorithms to poll the BUSY bit to determine the completion of the operations.  This appears to be operating correctly.

    However,  we can not explain the inconsistency in time duration of performing a segment erase or write.  The datasheet specs a fFTG of 257 to 476 kHz.  When configured in this range the operations are completing at an extremely slow rate.  Configuring the clock at a 8 MHz rate still results in lengthy operations but seems to successfully erase and write.

    The attached is a snippet of a putty trace for the operations.  This is output from a processor which is driving the MSP430 jtag interface to perform the operations.  This is for the most part a bit bashed interface based on slau320.

    For the segment erase, the start timestamps are printed just prior to the dummy write.  The end timestamps are printed following a not busy.

    Any idea on what could be causing this?

    Thanks,

    Dave

  • How you are pulling BUSY bit? For doing this inside strobe cycles flash clock can go outside spec, because shifting clock and strobes are on different frequency. BUSY bit is hardwired, so you can calculate without pulling, in advance when it will change state.

    Strobe cycles frequency (257 to 476 kHz in case of MCLK = flash clk) can be checked by scope, and number of strobes is documented in target device datasheet, for (segment) erase and write.

    Mass erase for MSP430F2272 will take 10600 strobes, minimum 22.3 ms (476 kHz) and max 41.3 ms (257 kHz) with few extra ms for total function.

    Original replicator is done for MSP430F5437, but it can be ported with minimal effort to any MSP430F5xx device, so you can easily check with scope all unclear thing, and compare it with you master device.

  • We are polling BUSY by reading FCTL3 via jtag.  Are you saying this could cause the flash clock to go outside spec?

    The datasheet lists the number of strobes as typical values.  Are these valid for all conditions?

  • Number of strobes that is documented in device datasheet is (hardwired / constant) precise number of flash clocks to have reliable flash operation. After elapsed strobes, flash register flags will change state. During strobes, target device is putted in special SBW / JTAG sequence, where MCLK (and flash clock) is directly coming from master device (TCLK in source code). Mixing strobes with other SBW / JTAG commands / shiftings will cause breaks in constant strobe / MCLK (TCLK) / flash clock (going out of specification).  

  • Hey Zrno, Dave's not in today, so I'm helping him out a little here:

    Are you saying that the TCLK drives the MCLK directly in JTAG Mode?

    This is different from our understanding, of how the module works. Here are couple of snippets from SLAU320AD:
    2.3.4 Programming the Flash Memory (Using the Onboard Flash Controller)
    2.3.4.1 Function Reference for 1xx, 2xx, 4xx Families
    Reference function: WriteFLASH
    This section describes one method available to program the flash memory module in an MSP430 device.
    It uses the same procedure that user-defined application software would use, which would be
    programmed into a production-equipment MSP430 device.

    Using this statement the basis for the algorithm would mean that the BCSCTL2 would define the clock source for the MCLK and FCTL2 would fully describe the clock source for the flash memory controller, as that's how a user-defined application would need to work. There is another somewhat obfuscated reference to this in this statement:

    For more information on the flash controller timing, see the corresponding MSP430 user's guide and
    device-specific data sheet. Table 9 shows the required minimum number of TCLK cycles, depending on
    the action performed on the flash (for FCTL2 register bits 0 to 7 = 0x40 as defined in the MSP430 user's
    guide).

    Which seems to indicate that the user should appropriately set the FSSELx (clock source) and FNx (n+1 divisor) bits in FCTL2 as required for their application to meet the datasheet parameters.

    However in support of your theory, the appnote is also peppered with references like this:

    This programming method requires a TCLK frequency of 350 kHz ±100 kHz while the erase or
    programming cycle is being executed. The frequency that must be applied to SBWTCK in Spy-Bi-Wire
    mode is the same frequency that is applied to TCK in 4-wire mode

    2.3.5.1 Function Reference for 1xx, 2xx, 4xx Families
    Reference function: EraseFLASH
    This section describes how to erase one segment of flash memory (ERASE_SGMT), how to erase the
    device main memory (ERASE_MAIN), and how to perform an erase of the complete flash memory
    address range including, main and info flash segments (ERASE_MASS). This method requires the user to
    provide a TCLK signal at a frequency of 350 kHz ±100 kHz while the erase cycle is being executed, as is
    also the case when programming the flash memory. The following tables show the segment and mass
    erase flows, respectively, and the minimum number of TCLK cycles required by the flash controller to
    perform each action (FCTL2 register bits 0 to 7 = 0x40).

    It was our understanding that the repeated TCK cycles were just a delay. That said, we have tried just polling busy (as described by David), we have also tried waiting out the requisite number of TCK ticks, then checking busy with no appreciable difference to the overall time it takes busy to toggle. Our repeat TCK ticks is generated by a GPS synced FPGA at 327kHz. If we change FCTL2's FNx register, we get proportionally longer or shorter times for busy. Also note that we suspected that JTAG may mess with MCLK (it doesn't seem to) so we also tried SMCLK with the same result. Our MCLK and SMCLK firmware implementations use the DCO which we use the 8MHz calibration from INFO A, we have tried a FNx value of both 18 and 26, no division to MCLK or SMCLK from the 8MHz DCO.

    If you have other information about why busy doesn't work, why it might bother flash timing or what exactly is driving the flash controller's clock source in JTAG mode we would be very interested. We think busy should work, because the users guide gives the impression that writes to flash from a non-flash location (ie: SRAM) should be able to hammer busy without impacting the operation. (SLAU144J - 7.3.2.2 Initiating an Erase from RAM). However the exceptionally long delays would indicate otherwise.

    Thanks for the help thus far.
  • TCLK cycles are not "just a delay", and your picture of 2xx flash module is wrong. Your picture about working target device under SBW / JTAG master control is also wrong. There is nothing wrong with TI documentation, with slau144 or slau320.

    MCLK for target device is generated by SBW / JTAG master and it is marked as TCLK on master side source code. Before use of flash module, target device will be reseted by SBW / JTAG master, and after reset (default) flash clock source (FSSEL = 01) is MCLK with divider 1 (FN = 0). Of course, this default state can be change because of some special reason, but I don't see any point in this.

    Flash clock is generated during strobes by TCLK (erasing or writing), and inside this period flash clock is limited 257 - 476 kHz. I had doubts before, but now I see that is clearly marked in slau320ad on page39, that TCLK frequency outside strobes is irelevantan, because during this period flash module is in idle state...

    only during strobes ------>  (3) Correct timing required. Must meet minimum and maximum TCLK frequency requirement of 350 kHz±100 kHz.

    SBW / JTAG interface (shifting functions) can go on maximum rate (limited by connection or target device datasheet). Only during strobes, interface rate should go down, to keep TCLK inside 257 - 476 kHz range.

**Attention** This is a public forum