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.

skills with defensive programming

Other Parts Discussed in Thread: HALCOGEN

Dear All

I noticed that the code generated by halcogen has concerned defensive programming or maybe try to satisfy the MISRA standard.

for example:

void esmEnableInterrupt(uint64 channels)
{
/* USER CODE BEGIN (15) */
/* USER CODE END */

    esmREG->IESR4 = (uint32)  ((channels >> 32U) & 0xFFFFFFFFU);
    esmREG->IESR1 = (uint32)  (channels & 0xFFFFFFFFU);

/* USER CODE BEGIN (16) */
/* USER CODE END */
}

it is a simple function to divide a 64 bit value into two 32bits value, high 32bits and low 32bits respectively

but why it should be ORed with 0xFFFFFFFFU,  and for what reason, there is a "U" followed by value?

it seems that if not ORed with 0xFFFFFFFFU, and no "U" followed, no error will occur, but I know you guy have some consideration for coding like this.

And I also noticed that, it is better to write 0xAA  or 0x55 to register to avoid soft error, it can be took account as a   defensive programming skill.

Please let me know if there are other defensive programming skills I didnt notice.

Leo

 

 




  • Hi Leo,

      It is an AND as in '&' with 0xFFFFFFFFU  not an OR. What it is trying to do is to enable the specified channel for interrupt. The register can only be written a '1'. Writing a '0' has no effect. Let's say IESR1 is current 0x7U. This means that channel 0, 1, 2 are already enabled. Suppose now you want to enable 3. You will do esmEnableInterrupt(0x8U) to enable channel3. 0x8 & 0xFFFFFFFFU is still 0x8U. Writing 0x8U to esmREG->ESR1 will only set bit 3 and the result of IESR1 will become 0xFU. Note that the bit 0, 1, 2 are not affected as writing 0U to these register bits has no effect.

     The U at the end is a MISRA check. See below rule. 

    Rule 10.6 (required): A “U” suffix shall be applied to all constants of unsigned type.”

      I'm not too sure what you meant by writing 0xAA or 0x55 in what context. Some critical registers requires writing 0x5 or 0xA to activate certain modes. For example, the default value of EDACEN (Flash memory error detection and correction enable) is 0x5 which is to disable the ECC detection. Writing any values other than 0x5 will enable ECC detection. Since this is a critical register that we want to protect from flipping that may result in disabling the ECC during runtime, the register is designed such that all values except 0x5 will still put the ECC in enable state. Therefore, we recommend writing 0xA to enable ECC. It will take 4 bits to flip to 0x5 to disable the ECC which reduces the likelihood of disabling the ECC due to radiation. 

  • Dear Charles
    Sorry for my typo, it is AND. But you have perfectly answered my question, we are using the MISRA standard, so the explanation of "U" makes me suddenly enlightened.
    But as you said, 0x8 & 0xFFFFFFFFU is still 0x8U , so why we need to AND with 0xFFFFFFFFU
    why not just write like this :
    esmREG->IESR1 = (uint32) channels ; there must be some reason?
    Thank you for your reply, and your interpretation of "0xAA or 0x55" is the answer I expected.
    Leo
  • Hi Leo,

      I don't think there is a strong reason to AND with 0xFFFFFFFFU. This is a HalCoGen generated code and it is like that for a long time. I think it just wants to make sure only the specified channels are updated to the registers and nothing else. I can check with the HalCoGen developer for the purpose. 

  • Dear Charles
    Thanks, waiting for your answer.
    Leo