Compiler/MSP430FR5848: What defines __MSP430_BASEADDRESS_TLV__ to the compiler?

Hello,

Matthew Sergei Perrin said:

I've been going through some of the driverlib seeing how the tlv layer was implemented and came across two instances where exact addresses are specified for the Device ID fields, they were 0x1A04 and 0x1A05.

I was surprised they weren't defined relative to the TLV_BASE definitions in the runtime headers, for each chip.

I specified them relative to this and the compilation fails due to __MSP430_BASEADDRESS_TLV__ not existing anywhere. Obviously if I define it as 0x1A00, it works for my chip - but I am not sure about whether that address is valid for other chips. I analysed all the header files and produced a list of possible values for TLV_END which came up as either 0x1AFF or 0x13FF and a TLV_START of 0x1A08 or 0x13C0.

You're right. The  __MSP430_BASEADDRESS_TLV__  or TLV_BASE defines don't appear to be used anywhere, perhaps due to the fact that this address varies device-to-device. I'd recommend using TLV_START as the effective base address, since this define is device-specific and should be correct in that device's header file. I'll make our software team aware of this, so they can remove these un-used defines. Thanks for pointing it out!

Matthew Sergei Perrin said:

So I looked at this chip, the i2020 and the tlv really starts at 0x13C0, whereas the tlv for the fr5848 starts at 0x1A00 - the conflict being in the meaning of TLV_START in the header. The definition of these clearly differs.

Exactly. The TLV structures are similar device-to-device but may exist in different memory locations. It's best to refer to the specific device's datasheet for the TLV information.

Matthew Sergei Perrin said:

When it comes to calculating the checksum, the data used for the fr5848's TLV CRC constitutes the range from after the stored CRC,until the end - whereas for the i2020 it constitutes what? How can this range be programatically determined?

The definition of TLV_START (0x1A08) for the fr5848 appears to be the first byte of the Die Record, which would be the first valid tag, but some bytes in this 'information block' are also made to be part of the crc.

The search algorithm for tags that the driverlib implements to parse the tlv searches from TLV_START, defined in these files, up to TLV_END for tag identifiers, skipping any bytes inbetween. So what happens if the CRC for the i2020 contains a valid tag identifier?

The fr5848 appears to have a correct structure for this search to function without error.

For implementing this functionality across several devices, I'd use pre-processer #defines for each selected device with different code that specifies the CRC range for that device under the related define. You can learn more about how to do this in the following thread.

preprocessor

Regards,

James