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.

Possible bug in gioLowLevelInterrupt/gioHighLevelInterrupt

Other Parts Discussed in Thread: HALCOGEN

Hi, 

I've tried to make gioNotification() work, and while gioNotification() does get called when exposing the GPIO to a falling edge, the port and bit information given as parameters were always wrong.

It was not until I noticed that the IRQ offset register is cleared on read and then inspecting the halcogen generated gioLowLevelInterrupt that I think I see the problem:

From RM48 user manual table 22-11

GIO offset 2. These bits index the currently pending low-priority interrupt. This register and the
flag bit (in the GIOFLG register) are also cleared when this register is read, except in emulation
mode


The gioLowLevelInterrupt:

void gioLowLevelInterrupt(void)
{
    uint32 offset;

/* USER CODE BEGIN (17) */
/* USER CODE END */

	if (gioREG->OFF2 != 0U) 
	{
		offset = gioREG->OFF2 - 1U;
		if (offset >= 8U)
		{
			gioNotification(gioPORTB, offset - 8U);
		}
		else
		{
			gioNotification(gioPORTA, offset);
		}
	}

/* USER CODE BEGIN (18) */
/* USER CODE END */

}

It is seen that the OFF2 reg is read twice and therefore as I see it the register is cleared before assigned to "offset". If I modify the code to only read OFF2 once into a temp var, and then use that instead then the code works perfectly.

Best regards,

Nikolaj 

  • Hi Nikolaj,

    You are correct. This is a bug in the interrupt service routine generated by HALCoGen. I will report this to the HALCoGen team so that it can be addressed in the next release. Thanks for catching this.

    Regards,

    Sunil

  • Sunil,

    just a question related to your HalCoGen-Team:  Do you apply software quality tools before you release a new version?  I am a little bit in doubt, because the code in question from above was correct in Version 3.06.00! It means that somebody of the team must have made the decision to change that part the wrong way. What was the justification for this Change?  

    Here is the code copied from Version 3.06.:

    /* SourceId : GIO_SourceId_011 */

    /* Requirements : HL_SR131 */

    void gioLowLevelInterrupt(void)

    {

        sint32 offset = gioREG->OFF2 - 1U;

    /* USER CODE BEGIN (17) */

    /* USER CODE END */

           if (offset >= 8)

           {

                 gioNotification(gioPORTB, offset - 8U);

           }

        else

        {

            gioNotification(gioPORTA, offset);

        }

    /* USER CODE BEGIN (18) */

    /* USER CODE END */

     

     

  • Hi Frank,

    I understand your frustration. We adhere to Safety quality development process for our software and testing.
    Unfortunalty with 3.08.01 we were trying to acheive MISRA compliance with multiple checkers like LDRA, CCS, Atollic etc. due to some customer push. In the process universally we changed lot of functions. We later realized unless other module tests DMA and GIO testlist missed testcase on offset checks inside the notification function, this lead to the bug slip.

    We were aware of the bug within couple of days but planned to release the fix along with 3.09.00 release end of April 2014 which support for all deviece under Hercules family. Do not want to confuse customer with 2 release in one month.

    Again sorry for the inconvenience, hope you will love HALCoGen again with 3.09.00.

  • Hi Prathap,

    Prathap said:

    We were aware of the bug within couple of days but planned to release the fix along with 3.09.00 release end of April 2014 which support for all deviece under Hercules family. Do not want to confuse customer with 2 release in one month.

    Again sorry for the inconvenience, hope you will love HALCoGen again with 3.09.00.

    I understand the decision to hold back the patch to the next release, however I really could have used that information when hunting the cause of the malfunctioning code.

    Does the Halcogen team have a  public bug-tracker that would have reflected this (if so I would love a link to it)?

    Best regards

    Nikolaj

  • Hi Nikolaj,

    There is a dedicated team who moderates the Forum and they religiously raise the Bugs in our Clearquest(CQ) system where we track all the issues/Enhancement and release commits. Anything that is raised on this Forum will endup in the CQ system with assigned priority and link to Forum post.

    I will check with the IT team to see if there is an easy way to get the CQ list publised.