TLV checksum algorithm changed on FR4133?

Hi Peter,

XMS samples can have incorrect TLV structures, and the fact that you are missing some data seems to confirm this assumption.

I'll try to double-check if this should be expected for this particular Rev anyways.

Regards,

Luis R

Hi Peter,

For XMS silicons, the TLV datas may be missing. If you want to check TLV datas, please do it on the RTM silicons.

Best Regards,
Darren Lu

Hi, Peter,

Thanks for the good capture. Since it is XMS datasheet, it may have TLV data missed. For the “invalid REF tag structure at 0x1a1E”, we will update the datasheet to add the tag and length and release in RTM version datasheet.

About the TLV CRC, the CRC address range should be 0x1A04 to 0x1A77. We have double checked the data you input. The CRC value of address 0x1A04 to 0x1A77 is 0x4F99. Please double check it.

For FR4133, the TLV data cannot be changed since this area is protected by system. We have CRC checking system to guarantee the TLV data is correct in the device.

Thanks,

Lixin Chen

Lixin Chen1 said:

About the TLV CRC, the CRC address range should be 0x1A04 to 0x1A77. We have double checked the data you input. The CRC value of address 0x1A04 to 0x1A77 is 0x4F99. Please double check it.

Thanks; your response confirms that the intent is to use the same algorithm (edit: i.e. polynomial) as the 5xx family.

However, you appear to be mistaken about the range over which the CRC should be calculated.  In the 5xx family, the first byte of the TLV table (in this case value 6) represents the base-2  exponent of the table length measured in 32-bit blocks (i.e. 2^6 blocks * 4 bytes/block= 256 bytes).  I'm not sure where I found that information originally, but it's been consistent on every other chip.  CRC is calculated from the data start (following the length and CRC information) to the end of the region.

This interpretation is confirmed by the presence of the following in the device-specific header file (msp430fr4133.h revision 1153):

#define TLV_START             (0x1A08)    /* Start Address of the TLV structure */
#define TLV_END               (0x1AFF)    /* End Address of the TLV structure */

These constants specify the range over which CRC is to be calculated.

If the ability to determine the length of the TLV structure from its contents is going to be removed for the FR4xx devices, you will need to make sure all the device-specific headers have the correct value in them.  But if you do that, you will break everybody who currently checks TLV validity with a portable firmware function that reads the length from an unknown chip at runtime.  (In other words, don't change the end because you'll break people.  Instead correct the length in your CRC calculation.)

Peter Bigot said:

CRC is calculated from the data start (following the length and CRC information) to the end of the region.

Sorry; that was wrong: the CRC calculation includes the CRC itself, so starts at TLV_START-4 and goes through TLV_END.

Peter Bigot said:

However, you appear to be mistaken about the range over which the CRC should be calculated.  In the 5xx family, the first byte of the TLV table (in this case value 6) represents the base-2  exponent of the table length measured in 32-bit blocks (i.e. 2^6 blocks * 4 bytes/block= 256 bytes). 

Yes. FR4133 is also following this rules. You can find it in the user guide.

Peter Bigot said:

CRC is calculated from the data start (following the length and CRC information) to the end of the region.

I cannot find this in the user guide. I will check with team about this rule.

Peter Bigot said:

#define TLV_START             (0x1A08)    /* Start Address of the TLV structure */
#define TLV_END               (0x1AFF)    /* End Address of the TLV structure */

Sorry, I didn't check this in the header file. I will check with team.

Peter Bigot said:

If the ability to determine the length of the TLV structure from its contents is going to be removed for the FR4xx devices, you will need to make sure all the device-specific headers have the correct value in them.  But if you do that, you will break everybody who currently checks TLV validity with a portable firmware function that reads the length from an unknown chip at runtime.  (In other words, don't change the end because you'll break people.  Instead correct the length in your CRC calculation.)

I would not like to break anybody about the TLV structure. As I mentioned, the TLV structure and length is following existing rules. The only concern is if the TLV_END is always the end of the TLV area or it can be defined in the header file. I will feedback to you after checking with team.

Lixin Chen1 said:

The only concern is if the TLV_END is always the end of the TLV area or it can be defined in the header file

Sorry, TLV_END should be the end of the TLV area. I will check with team about the CRC calulation rules.

Lixin Chen1 said:

The only concern is if the TLV_END is always the end of the TLV area or it can be defined in the header file

Sorry, TLV_END should be the end of the TLV area. I will check with team about the CRC calulation rules.

[/quote]

So I went back a couple sections in the user's guide, and I think part of the confusion  that the CRC is not calculated over just the TLV, it should be calculated over the whole device descriptor region, regardless of where the last TLV entry ends.

Confirming evidence is that the existing MSP430F5438A, MSP430F5529, and MSP430FR5969 all calculate up to but not including 0x1B00.  Here's the dump from an MSP430FR5969.  The last entry ends at 0x1A44, but the CRC continues to the end of the device descriptor table:

Legacy device table:
0xff0  80 7f 24 35 00 1a 00 00  05 01 00 00 00 00 00 00
TLV table starts at 0x1a00 and ends at 0x1b00
TLV table:
0x1a00  06 06 94 eb 69 81 30 30  08 0a 64 12 9b 08 18 00
0x1a10  22 00 f8 fe 11 10 fd 7f  00 00 63 0a 37 0c 3c 06
0x1a20  56 07 fb 04 db 05 12 06  f1 7f f0 7f 26 80 15 10
0x1a30  6b 60 dc 5f a0 31 7f 54  52 a8 4c 3b 87 16 e5 27
0x1a40  1c 02 00 00 ff ff ff ff  ff ff ff ff ff ff ff ff
0x1a50  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
0x1a60  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
0x1a70  1b 80 a2 7f 0a 82 22 e3  7c 00 ff ff ff ff ff ff
0x1a80  ff ff ff ff ff ff ff ff  ff ff ff ff 10 01 02 96
0x1a90  16 01 ba 8c 18 01 30 9a  1a 01 07 00 10 01 02 96
0x1aa0  14 01 00 40 10 01 01 96  14 01 00 00 10 01 d8 96
0x1ab0  12 01 0a 12 1a 01 00 28  1c 01 00 40 10 01 1c 96
0x1ac0  16 01 00 90 18 01 1c 18  1a 01 00 05 1c 01 64 04
0x1ad0  10 01 a0 96 12 01 22 e2  1a 01 7a 00 1c 01 10 00
0x1ae0  10 01 a8 96 12 01 0a 00  9c 1a 8c 1a aa 05 ff ff
0x1af0  cf ff 14 10 00 00 c3 3c  00 06 18 81 24 02 c5 4b
BSP430_TLV_TABLE_IS_VALID: 1
CRC for [0x1a04, 0x1b00] expect eb94 get eb94: valid data
0x1a08 tag 08 len 10
        Lot ID: 0x089b1264 ; position 24, 34 ; test results 0xfef8
0x1a14 tag 11 len 16
        ADC: Gain factor 32765, offset 0
         1.5V T30 2659 T85 3127
         2.0V T30 1596 T85 1878
         2.5V T30 1275 T85 1499
0x1a26 tag 12 len 6
        REF factors: 1.5V 32753 ; 2.0V 32752 ; 2.5V -32730
0x1a2e tag 15 len 16
0x1a40 tag 1c len 2
0x1a44 tag ff len 255
End of TLV structure

Peter Bigot said:

So I went back a couple sections in the user's guide, and I think part of the confusion  that the CRC is not calculated over just the TLV, it should be calculated over the whole device descriptor region, regardless of where the last TLV entry ends.

Yes. I noticed that. F5xx/F6xx, FR59xx are following this rule: CRC range is TLV_START-4 to TLV_END. But there is no definition for the checksum address range as this. Some devices have different TLV region address range. You can check MSP430i2040 user guide slau335. The TLV is only 64 bytes. And the checksum address range is 0x13C2 to 0x13FF. My point is that we can add a description in the FR4xx user guide or datasheet to mention the chechsum range. Do you think it is ok?

I appreciate your feedback and comments. If you are ok to discuss by email, please share share your email address with me. My email: lixin-chen@ti.com.

Lixin Chen1 said:

Yes. I noticed that. F5xx/F6xx, FR59xx are following this rule: CRC range is TLV_START-4 to TLV_END. But there is no definition for the checksum address range as this. Some devices have different TLV region address range. You can check MSP430i2040 user guide slau335. The TLV is only 64 bytes. And the checksum address range is 0x13C2 to 0x13FF. My point is that we can add a description in the FR4xx user guide or datasheet to mention the chechsum range. Do you think it is ok?

Personally, no.  The firmware I write can't look things up in a datasheet.  Ideally I want the length of the descriptor to be inferrable at runtime for all devices.

The way it is on 5xx/6xx/FR5xx devices: You'd read the word at address 0x0FF4 to get the address of the device descriptor block.  That block follows a documented format, and its length is encoded in it.  You could do similar things on other families, by reading data in the 16-byte block at 0x0FF0 to get MCU identifying information.  I don't know if that feature is being retained in newer devices.

As you point out, the i2XX devices are using the TLV scheme (and addresses) from the old F2xx family (the INFO_A approach).  That's fine because it's existing practice; it'd be nice if it had switched to the new scheme, but at least it's something we already know how to deal with.

It's not so fine if legacy devices have one scheme with per-device fixed structures, 5xx and FR5xx/6xx have an improved, self-describing alternative, and then FR2xx/4xx introduces a third with unmotivated differences from the existing 5xx solution that breaks the self-describing feature.

Lixin Chen1 said:

I appreciate your feedback and comments. If you are ok to discuss by email, please share share your email address with me. My email: lixin-chen@ti.com.

I am afraid it is too late to change the FR41xx/FR20xx TLV CRC range. But we will try to keep things consistent in the future devices. Thanks for good comments.

A basic question, why to check the TLV integrity by CRC in your firmware? You know the device will do CRC check for the TLV when BOR reset. We can guarantee the TLV integrity, otherwise the device cannot work normally.

Lixin Chen1 said:

A basic question, why to check the TLV integrity by CRC in your firmware? You know the device will do CRC check for the TLV when BOR reset. We can guarantee the TLV integrity, otherwise the device cannot work normally.

Because I don't know that anything checks the TLV on BOR reset.  Possibly it does now with the MSP430FR4xx devices, though that feature isn't mentioned in the user's guide.  It certainly doesn't check on any other MSP430 I've encountered.

And what exactly is the behavior of the device if the TLV checksum fails during a brown-out reset?  Does it power itself down without ever jumping through the reset vector?

This sounds like a bad idea.  There's nothing in the TLV that would make a device completely unusable if it's corrupt.

MSP430FR4133 TLV space is not writeable. So it should be safe for customers.

Based on my understanding, to CRC check the TLV table is to make sure the device is corrupt or not, right?

Lixin Chen1 said:

MSP430FR4133 TLV space is not writeable. So it should be safe for customers.

Based on my understanding, to CRC check the TLV table is to make sure the device is corrupt or not, right?

Yes.  While it's true that in these parts the device descriptor table is read-only, other TI folks have confirmed that the TLV section is still potentially invalid in XMS parts, which might slip into a system especially during product development.  Be pretty irritating to spend a couple weeks diagnosing a problem only to discover that misbehavior was due to invalid calibration parameters in an untrustworthy part.

Nor am I willing to assume TI's manufacturing processes are defect-free.

Why would you provide and document a CRC, and not make sure people can actually use it?

Having a correct CRC doesn’t mean the TLV content is correct. It only means it hasn’t changed since CRC calculation.
It’s still possible that bad calibration values or wrong device descriptions have been generated when writing the TLV structure.
(after all, it is no “mask rom”). And in fact, this has happened before.
I bet that even on the XMS parts with missing calibration values, the CRC is correct.

Jens-Michael Gross said:

Having a correct CRC doesn’t mean the TLV content is correct. It only means it hasn’t changed since CRC calculation.

Or that it changed in a way that didn't affect the CRC, yes.

Jens-Michael Gross said:

It’s still possible that bad calibration values or wrong device descriptions have been generated when writing the TLV structure.
(after all, it is no “mask rom”). And in fact, this has happened before.
I bet that even on the XMS parts with missing calibration values, the CRC is correct.

Could be; apparently it is on the FR4133, once you change the range over which it's calculated.

I don't really mind if the fact that these values are now in immutable memory makes CRC validation unnecessary.  I do object to changing how the CRC validation is done in a new MSP430 family without a compelling reason and clear documentation.  Too late now, though.

Hi, Peter,

Sorry there is no clear documentation about the CRC range in the MSP430FR4133 datasheet and user guide. I think a solution is to add the CRC start address and CRC end address in the datasheet. And we can also add the #definition for the two address in the MSP430FR4133 header file so that your software tools can use the #definition for CRC check.  Please let me know if you are ok for this solution.

Thanks,

Lixin

Basically, what you're proposing is using concepts from the less powerful approach of the earlier 2xx family Tag-Length-Value block to work around the fact that FR4xx chips have broken the contract supported by every other MSP430 family (5xx/6xx/FR5xx/FR6xx) that uses the Device Descriptor Table concept.  At least in my experience this is the first deviation.

The solution I'd be OK with is to make the FR4xx chips consistent with existing practice: calculate the CRC to the end of the device descriptor table, even if there's stuff in there that's past the end of the TLV.  But you've said it's too late for that.

A solution that requires external information (from a datasheet or a compile-time header) is a loss in functionality.  How about instead you define the mechanism by which a validation algorithm can identify the end of the last valid entry in the TLV sequence, and specify that that marks the end of the CRC region?  For example, stop at the address for a TLV entry with tag 0xFF.  We can then calculate the CRC up to that point, and up to the end of the region, and call it good if the stored CRC matches one or the other.  (Currently 0xFF and 0x00 are neither defined nor reserved as tags, a gap that should be addressed.)

But in the end it doesn't matter what I think about various hacks intended to make something work.  Whatever solution you come up with, us customers will deal with it somehow.  I'm just increasingly disheartened by the lack of architectural integrity in additions to the MSP430 product line, and irritated that these issues aren't being identified and resolved within TI before the customers encounter them.

Hi, Peter,

Sorry, after checking with team, there is some limitation with your proposed solution. But anyway, thanks for the comments and suggestion.

We will update user guide to describe the CRC address range. And the header file will also be updated to add two defines to feedback this.

• TLV_CRC_START
• TLV_CRC_END

Your software can monitor these two defines in the header file to check the CRC integrity. I hope this change can meet your requirement.

As I've explained, your new approach breaks the self-descriptive properties of the device descriptor table.  A value in the header doesn't work for me because the check code doesn't know what specific MCU it's built for.

In practice I'll to try to use the approach I suggested.  I can't guess what problems your team envisions with it, but hopefully future changes won't break this model even more badly.

I just know your check code doesn't know what specific MCU it is built for. Self-descriptive feature is good to have for the TLV. We will try to keep the CRC range consistent with previous family in the future design. Thanks for understanding.