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.

decoding peripheral entries

Other Parts Discussed in Thread: CC430F5137

I'm writing code to examine the PDTAG block in the device descriptor table on a CC430F5137.  The corresponding content is:

1a30:  08 8a 0c 86 0e 2c 40 92 00 1d 00 23 00 09 00 0f
1a40:  00 03 00 1f 10 41 02 30 02 38 01 3d 00 44 00 40
1a50:  01 48 02 42 03 a0 01 10 04 51 02 52 02 53 0e 5f
1a60:  02 62 04 61 12 68 02 85 04 47 0c 90 14 d1 1c a8
1a70:  10 80 54 bc a8 40 90 91 d0 60 61 bc 46 62 63 50
1a80:  51 01 68 80 00

The first eight bytes comprise the memory entries, and those decode correctly as:

 FLASH 2048 bytes at 0x1000
 FLASH 512 bytes at 0x1800
 RAM 4096 bytes at 0x1c00
 FLASH 32768 bytes at 0x8000

What follows says there are 29 peripherals, with packed entry values starting with 0x2300, 0x0900, 0x0f00, 0x1f00, ...

Several issues: first, where can I find a complete list of peripheral IDs?  There is a partial table in the 5xx/6xx and CC430 user's guides, but it's not complete.  I can't find this in the device data sheet either.

Second, the adrval fields seem completely wrong, since the first four are all at address zero (or, the peripheral entry values differ from everything else and are big-endian, in which case there are four "no modules" at various addresses).

Third, looking ahead, are the one-byte interrupt priority values that end the PDTAG section PID values as well?

Thanks.

Peter

  • Peter Bigot said:
    where can I find a complete list of peripheral IDs?

    There is none. Even the mentioned partial lists do contain peripherals not there in the devices this list belongs to and are missing others which are there. These lists are only examples (and IIRC they are identical across all documents, including the whitepaper describing the table mechanism).

    Peter Bigot said:
    Second, the adrval fields seem completely wrong, since the first four are all at address zero

    No, this is okay. The CPU does not take any memory, nor do the other first components, They are rather cpu feature descriptors than physical module descriptors.
    The address counter begins at 0x00000. Each modules describes the offset to the current address to get the start addess. Due to the granularity of this offset byte (addrval is to be multiplied by either 0x10 or 0x800), some modules (e.g. the WDT) do not have a module offset (share the same ram region) but have different register offsets in their module description (not reflected by the TLV in any way). Pretty confusing

    Peter Bigot said:
    are the one-byte interrupt priority values that end the PDTAG section PID values as well

    Alas, no. Since many modules have more than one interrupt vector, these values are maybe somewhat related to the PID values, but only roughly. Also, there may be modules with identical IDs but of course their interrupts need different ones.

    The PID of TA0 (according to the example table in the 54xx users guide)  0x81, and 0x82 for TA1 (which is confusing since not the number of the timer but the phyysical representation should determine the PID, so TAx_3 and TAx_5 shoul hdave different PIDs, but TA0_3 and TA1_3 should be the same, the '0' just defined by its position in the memory map), but in the 5438 TLV, the PIDs are 0x62 for TA0 and 0x61 for TA1 (not the descending number), while the interrupt IDs are 0x60/0x61 for TA0 and 0x62/0x63 for TA1.
    The four USCIs, however, have identical PIDs (0x90, while the ports 3..10 have different ones, 0x52..0x55 despite the fact that the ports are identical) but then the interrupts for the uarts are 0x90..0x97

    It looks like this TLV structure, even in its Nth, incompatible incarnation, is still not very structured or well-documented.

**Attention** This is a public forum