ADuC7124 - VIC, strange intermittent behaviour where ISRs are not executed

Hi Troels,

You mentioned that D2 never lights up because the ISR never fires at random startups. Do you mean that the ISR doesn't execute when powering the device, or is there a considerable delay before the D2 lights up?

Is there any instance of the ISR starting when resetting the device, or does it only work when the usb power supply connector is unplugged/replugged?

When checking the code, I noticed that in the RAM_sections_init.c function, I saw the for loop is like this:

for(i=0;i<16;i++)
{	
	// Copy 0x040 bytes to RAM (0x00040000 to 0x0004003F (both included))
	*uDest++ = *uSrc++;
}

Should it be like this, to include writing to 0x00040000?

for(i=0;i<16;i++)
{
	*uDest = *uSrc;
	*uDest++;
	*uSrc++;
}

In the ISR handler, have you tried writing directly to the register? I'm not sure if calling a function inside the ISR while running the program at RAM can cause the issue.

__ramfunc void IRQ_handler_T2(void)
{	
    T2CLRI = 1;
    
    GP4CLR = 0x400000;
    
    return;
}

Regards,

Karl

Hi Karl,
Thanks for replying, much appreciated. I tried your suggestions, but the behavior is the same.
I have made one more discovery and possible solution.

You're right. When performing a hardware reset/power cycling, the ISR actually always executes - eventually (patience...).
With JTAG debugging I have found out that when I program the device and the ISR isn't fired immediately, the value of T2VAL seems to be very high, as if it was initalized to 0xFFFFFFFF and not the T2LD value. After the interrupt eventually fires, T2VAL is loaded with the T2LD value, so it seems sort of like "er005" from the silicon anomaly document.

I tried modifying the code, so that timer 2 isn't actually enabled at the same time the clock source is changed:

T2CON = 0x00000644;

T2LD = 250;

T2CON |= 0x80; // Set bit 7 to enable timer 2.

And then the ISR works each and every time. I have also tried to leave the clock source as default, and do this:

T2LD = 250;

T2CON = 0x000000C4;

The ISR is also fired immediately after 250 ticks with this.
So, it seems that changing clock sources and enabling the timer just after T2LD was written messes something up with T2LD. Changing the clock prescaling does not seem to affect the behavior.

What is strange is that we have used the approach with T2LD and then T2CON = 6C4 in code for ADuC7026 and ADuC7024 with no issues, so something must have changed with the ADuC7124 (?).
Are you able to reproduce a similar problem?

Also, by the way: Reserved bits/bytes - does it matter what value is written to them - or is it recommended to always write them as 0?

Hi Karl,
Thanks for replying, much appreciated. I tried your suggestions, but the behavior is the same.
I have made one more discovery and possible solution.

You're right. When performing a hardware reset/power cycling, the ISR actually always executes - eventually (patience...).
With JTAG debugging I have found out that when I program the device and the ISR isn't fired immediately, the value of T2VAL seems to be very high, as if it was initalized to 0xFFFFFFFF and not the T2LD value. After the interrupt eventually fires, T2VAL is loaded with the T2LD value, so it seems sort of like "er005" from the silicon anomaly document.

I tried modifying the code, so that timer 2 isn't actually enabled at the same time the clock source is changed:

T2CON = 0x00000644;

T2LD = 250;

T2CON |= 0x80; // Set bit 7 to enable timer 2.

And then the ISR works each and every time. I have also tried to leave the clock source as default, and do this:

T2LD = 250;

T2CON = 0x000000C4;

The ISR is also fired immediately after 250 ticks with this.
So, it seems that changing clock sources and enabling the timer just after T2LD was written messes something up with T2LD. Changing the clock prescaling does not seem to affect the behavior.

What is strange is that we have used the approach with T2LD and then T2CON = 6C4 in code for ADuC7026 and ADuC7024 with no issues, so something must have changed with the ADuC7124 (?).
Are you able to reproduce a similar problem?

Also, by the way: Reserved bits/bytes - does it matter what value is written to them - or is it recommended to always write them as 0?