• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 82 subscribers
  • Views 1076 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.

Does CCS preserve TLV?

incoherent
Intellectual 350 points

Other Parts Discussed in Thread: MSP430F5438, MSP430F5418A, CC430F5137

While attempting to read the ADC cal data on an F5438A, I found the entire TLV populated by 0x3FFF.

Confused, I attempted to verify that I was looking in the right place by running the TLV_01 example program included with the 5xx/6xx core library--again all 0x3FFF.

Is it possible that Code Composer (v5.1) does not preserve the TLV portion of flash?  Or is the TLV in a different location on this device.  According to the spec sheet, the ADC12 gain factor should be found at 0x1A16--right where I'm looking...

  • 0
    Guru 227245 points

    The TLV structure is not user-writable. It is not subject to CCS's mass erase.
    I'm not even sure whether it is in flash at all.
    However, after being erased, the content shoudl be 0xFFFF, not 0x3FFF. 0x3FFF is the typical content returned on vacant (unused) memory.

    0x1A16 is the right place to look for the ADC Gain factor. And on my MSP430F5438 (non-A), it is there and I use it.

    Some possibilities: SInce the TLV is something that is not mask programmed but individually written, it may be flash or PROM.
    So one possibility is that it wasn't written to at all for some reason. This shouldn't happen, but it did in the past.
    If the TLV indeed is flash, it may be that it has been erased by massive overvoltage or overtemperature, which can erase flash.
    It is also possible that there is a bug in CCS that does not allow reading this area (there was a similar bug with the lower part of RAM). However, if you used code to read the TLV then this is not an option.

    Maybe your MSP has preliminary silicon (XMS430) and never got the TLV structure written. Many of the early free samples were XMS devices.

  • 0
    Genius 4925 points

    I just tried with my msp430f5418a (basically the same device) and indeed if you use the expression or memory view, it seems like the TLV is populated with 0x3FFF.

    Then I tried the following:

    void main(void)
    {
     WDTCTL = WDTPW+WDTHOLD; // Stop WDT 

     volatile unsigned char test = *((char*)(0x1A14));

    }

    And well  inside the test there was a 0x11, which is what you expect from that position inside the TLV (ADC12 Calibration Tag). So I guess there is some issue with reading the TLV structure with the debugger inside the CCS directly.

    My calibration value at 0x1A16 reads 0xFF which seems a rather curious value again. 

  • 0 in reply to Bernhard Weller
    Guru 227245 points

    Bernhard Weller said:
    My calibration value at 0x1A16 reads 0xFF which seems a rather curious value again. 

    Can well be right. It is a signed word, and 0xff being the low-byte is in the range of valid values.
    It's a bit strange that there is no information in the users guide about how to use the calibration values.
    Correction: teh 2x family users guide contains a section about the TLV and how to use the factors. It's missing in the 5x users guide.

  • 0 in reply to Jens-Michael Gross
    Genius 4925 points

    Ah yes, I missed that it's actually a 16 bit value for correction, I'll check the complete calibration value tomorrow.

  • 0 in reply to Bernhard Weller
    Intellectual 350 points

    I think you are both correct, there seems to be an issue with Composer when reading this portion of memory.

    I modified the TLV_01 example to copy the ADC cal structure, and here's what I got:

    ADCCAL    struct s_TLV_ADC_Cal_Data    {...}    0x1C0A    
        adc_gain_factor    unsigned int    32769    0x1C0A    
        adc_offset    unsigned int    1    0x1C0C    
        adc_ref15_30_temp    unsigned int    2034    0x1C0E    
        adc_ref15_85_temp    unsigned int    2409    0x1C10    
        adc_ref20_30_temp    unsigned int    1534    0x1C12    
        adc_ref20_85_temp    unsigned int    1815    0x1C14    
        adc_ref25_30_temp    unsigned int    1216    0x1C16    
        adc_ref25_85_temp    unsigned int    1438    0x1C18


    Looks much better, thanks for the clue. 

    I guess the lesson learned here is:  Never trust the debugger!

    Thanks,

    --Mike

  • 0 in reply to incoherent
    Genius 3370 points

    Are you using CCS V5 or CCS V4. I am using CCS V4 with a cc430F5137 (based on the F5xx series) and am able to read the TVL memory in debug mode. Maybe it is a CCS issue? The CC430 user guide also has a section on the TLV FYI.

  • 0 in reply to Timothy Barr
    Intellectual 400 points

    Same here, CCS V5, F5172: TLV area reads 3FFF in debug mode, but seems to be readable from the MCU.

    Is this a CCS bug?

  • 0 in reply to Martin55843
    Intellectual 700 points

    Is there any news on this from anyone at TI? I'm having the same issue with CCS 5.1 and the 5308.

**Attention** This is a public forum