RM48L952: SafeTI: Multiple bugs in register bit acknowledging/clearing (operator '|=' used when '=' should be used)???

Hi again,

For example this line clears also DERR and others
BIT_SET(sl_tcram1REG->RAMERRSTATUS, TCRAM_RAMERRSTATUS_ADDR_SERR);/* Clear for subsequent operation */

These clears also possible SERR and others (if single bit error happens simultaneously then details of it are lost), tested that in case of DERR test the SERR bits are not normally active so tis really hides them)
/* Clear double bit error anyways */
sl_tcram1REG->RAMERRSTATUS |= TCRAM_RAMERRSTATUS_DER;
sl_tcram2REG->RAMERRSTATUS |= TCRAM_RAMERRSTATUS_DER;


Example demo application contains same mistakes in abort handler
/* Clear double bit error anyways */
sl_tcram1REG->RAMERRSTATUS |= TCRAM_RAMERRSTATUS_DER;
sl_tcram2REG->RAMERRSTATUS |= TCRAM_RAMERRSTATUS_DER;


definition of BIT_SET
/*SAFETYMCUSW 340 S MR:19.7 <APPROVED> "Reason -  This is an advisory by MISRA.We accept this as a coding convention*/
#define BIT_SET(y, mask)        ((y) |= (mask))

Why even that BIT_SET is not used consistently? Above is exactly same wrong functionality with BIT_SET and without it... Do you even review the code syntax that it is consistent even inside one function?

There are also correct usages of the register like this, in case you would have reviewed the syntax the bugs would have been most likely catched...
sl_tcram2REG->RAMERRSTATUS = TCRAM_RAMERRSTAT_WADDRPAR_FAIL;


Since one register has so many problems I doubt that this is the only one so most likely similar problems exists somewhere else (at least example demo application has many in exception handlers and esm_callback, almost all ESM channel acknowledges has |= operator etc which masks all possible ESM errors away.)...

Do you have active & up to date bug list available in webpages for SafeTI library product? I have received one in my email ages ago and since it looks like that bugs are found "almost every week" I doubt that received one is valid any more...


There also some other much minor issues like documented exit CPU modes for example to functions SL_SelfTest_Status_EFuse() & SL_SelfTest_CCMR4F(), claimed to be SVC but is actually same as entry...