Hello TI,
we are currently reviewing some of the PDK register definitions (included in the cslr_*.h files) that we want to use in our safety related project.
For eCAP, we accidentally found some mismatches between TRM (Revision from March 2022) and the implementation in the 8.05 SDK/PDK
This is the description in the TRM:
And these are the #defines for the register addresses from cslr_ecap.h:
#define ECAP_TSCTR ((uint32_t)0x0U)
#define ECAP_CTRPHS ((uint32_t)0x4U)
#define ECAP_CAP1 ((uint32_t)0x8U)
#define ECAP_CAP2 ((uint32_t)0xCU)
#define ECAP_CAP3 ((uint32_t)0x10U)
#define ECAP_CAP4 ((uint32_t)0x14U)
#define ECAP_ECCTL1 ((uint32_t)0x28U) /* Mismatch to TRM! */
#define ECAP_ECCTL2 ((uint32_t)0x2AU) /* Mismatch to TRM! */
#define ECAP_ECEINT ((uint32_t)0x2CU) /* Mismatch to TRM! */
#define ECAP_ECFLG ((uint32_t)0x2EU) /* Mismatch to TRM! */
#define ECAP_ECCLR ((uint32_t)0x30U) /* Mismatch to TRM! */
#define ECAP_ECFRC ((uint32_t)0x32U) /* Mismatch to TRM! */
#define ECAP_REVID ((uint32_t)0x5CU) /* Mismatch to TRM! */
The names do not always match (REVID vs. PID), and registers defined as 32bit in the TRM are defined as 16bit in the header.
This is a problem for the safety related software we are developing. When we use the definitions in our code, we need to be able to trace the names to the design, which would be in this case the TRM.
But here it is not obvious that e.g. ECAP_ECINT_EN_FLG is the same as ECAP_ECEINT + ECAP_ECFLG.
The same issue is with the struct definition in the same file. However here seems to be am additional bug in the code (I've added the address offsets as comments):
The size of the RSVD1 - arrays is wrong (should be 40, not 41), the current value leads to a wrong and unaligned address for the PID resp. REVID register.
After finding this, I have several questions:
- especially for these eCAP findings: what is correct, the TRM (all 32bit registers) or the code (mixed 16 and 32bit registers)?
- when someone finds such problems, how long does it take until it is incorporated into TRM resp. SDK?
- for us as PDK users, is there any mechanism which may notify us if a potentially critical error in PDK or TRM has been detected, so we can check if we are affected?
- to justify the usage of external code like these register definitions in our safety critical software, it is helpful if the code has been developed according to established quality standards. Has the PDK been developed according to any safety or quality process?
Best regards
Thomas
