• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 81 subscribers
  • Views 1305 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.

Problems in slaa294a checksum

frank Bolton
Prodigy 30 points

Other Parts Discussed in Thread: MSP430G2553, MSP430WARE, MSP430F1612

Hi,

I am planning to use the checksum functionality listed on the application note and example code slaa294a.

There are a few places where the example seems to have some gremlins.
Hopefully, someone from TI or the community can tell me if I'm right so that I don't put bugs into a production.

  • The comments n the code and the pdf file indicate that the checksum spans two segments of the flash memory which should be 1024 bytes /  0x400 (0xFA00 to 0xFDFF).
    In the for loops for generating and testing the checksum, the range is 0 to 0x200 which looks like it's spanning only a single block (512 bytes / 0x200). 
    (I assume that incrementing pointers works in bytes and not words).
  • In setting up FCTL2 the FSSEL0 is used which implies that ACLK is the base clock
    The divider FN0 is used which means that the divider should be one 
    Flash clock should be written as ACLK/1 instead of MCLK/2
  • At the end of the example, the set lock code is missing. Is this optional or is this omission a mistake?
  • Overall logic listed in the comments hasn't been implemented in the code. 

Looking forward to some answers from the community. If I'm posting a topic that I should have found with searches- please let me know what terms I should have used.

  • 0
    TI__Genius 13215 points
    Hi Frank,

    I will check with our experts and reply you.
  • 0 in reply to Wei.Jetim Zhao
    TI__Guru 56685 points
    Hello Frank,

    Can you tell me which device you are using? I see you tagged the MSP-EXP430G2 Launchpad. this leads me to believe you are using the MSP430G2553 or some variant there of.

    For the pointer indexing question, since the array is defined as a bunch of ints, then it will increment via ints which are 16-bit. thus it is incrementing via words or 2 bytes at a time.

    For your other questions, I haven't delved to far into them as this program was written for the MSP430F1612, which has a different clock system and flash system than some of our later parts. If you are using this family of parts, please let me know and I can look into further. If you are looking for an example on how to write to flash on the MSP430G2553 or similar variant, there are examples of this found within MSP430Ware. Navigate to TI Resource Explorer within CCS or at dev.ti.com From there take the following path: TI Resource Explorer -. Software -> MSP430Ware -> Devices -> MSP430G2xxx -> MSP430G2553 -> Peripheral Examples -> Register Level ->MSP430G2xx3_flashwrite_01.c . Similar examples can be found on other devices within this path as well.
  • 0 in reply to Jace H
    Prodigy 45 points
    Hi Jace,
    Thanks for the response. I think the issues are 75% solved with some better level of understanding my side.

    1 - the for-loop indexing working at word level and not as I thought (byte level) explains the first question.

    2- I am using the MSP430g2553, so the example you provided from Resource Explorer was really helpful.
    The use of FCTL2 and FCTL3 in the family guides was identical and I now have the following understanding:

    3- FCTL2 FNx operates as follows:
    FCTL2 = FWKEY + FSSEL? + FN0 -> divisor = pow(2,0) + 1 = 1 + 1 = 2
    FCTL2 = FWKEY + FSSEL? + FN1 -> divisor = pow(2,1) +1 = 2 + 1 = 3
    FLTL2 = FWKEY + FSSEL? + 0x3F -> divisor = 0x3f + 1 = 63 + 1 = 64
    (the FNx values represent powers of 2, but the divisor can also be an arbirary hex code.

    4 - I'm still stuck on what seems to be inconsistencies with the clock selector.
    For instance the family guide for 430g2x53 (page 324) states that FSSELx 00 - ACLK and 01 MCLK
    (which are presumable accessed using ACLK <-> FSSEL0 and MCLK <-> FSSEL1 respectively.)
    In contrast to this, the code example msp430g2xx3_flashwrite_01.c states FSSEL0 <-> MCLK.


    Hope to hear back on item 4.
  • 0 in reply to Frank Bolton
    TI__Guru 56685 points
    Frank,

    I can see your confusion on part 4. If you actually import the code example into CCS and hover over FSSEL0, you will see that it resolves to a value of 0x0400. This corresponds to a choice of MCLK as bit 6 is written as a '1'. Incidentally FSSEL1 resolves to 0x0800 which chooses SMCLK. Now of you use the FSSEL_0 / FSSEL_1 / FSSEL_2 values, you will actually place 0/1/2 into these bit fields, respectively. Note that in this case the underscore differentiates the two. I think the act of making FSSEL0 be equivalent to FSSEL_1 was an effort to make the end user default to MCLK instead of trying to use ACLK. ACLK for these devices is typically used for LF Xtals which cannot generate the timing necessary for the flash controller.

    In other words, its a little confusing, but the FSSEL0 macro expression does not correctly correlate to the register options. In contrast the FSSEL_0/1/2 macro expressions directly correlate to the registers.
  • 0 in reply to Jace H
    Prodigy 30 points
    It makes sense now. Thank you.
    I'll make sure to trust the value reported in the IDE over my interpretation of the documentation when dealing with registers in future.

    Regards,
    Frank

**Attention** This is a public forum