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 again,

Hmm - the corrections in my other post are definitely needed, but it seems that setting the processor mode to "Thumb" instead of "ARM" makes interrupts sometimes not fire at all, and the values of the timer registers are as expetect, and counting is active.

I see it was mentioned here:
aduc7061 VIC

But what makes it not work in Thumb mode and is this stated somewhere more officially from ADI?

Hi,

In the datasheet, Rev. D page 28, the core should switch automatically to ARM code for exception handling. I believe that the mentioned exception handling should include the ISRs.

The datasheet did state that for more information with the ARM7TDMI core, the following material is available:
DDI0029G, ARM7TDMI Technical Reference Manual
DDI-0100, ARM Architecture Reference Manual

Regarding the reserved bits/bytes, the recommended is to follow the default values written in the datasheet.

I tried the approach of T2LD and then T2CON = 6C4. I did notice some instances that the ISR did not execute after replugging the power supply or pulling down the reset pin to GND for some time.

Thanks Karl, much appreciated and am glad you were able to reproduce the timer issue.

On further investigation on the ARM/Thumb: It turns out it is only with the JTAG connected and performing "Software reset" that it doesn't always work, but it turns out it doesn't matter if it is Thumb or ARM mode - at least that is what it looks like. Setting reset mode to "Normal" or "Hardware (Reset pin)" seems to work consistently no matter what.

I have never had any issues when issuing RSTSTA = 0x04 to perform a softreset, not with JTAG connected either, except that it loses the connection when resetting.
Maybe the software reset is purely a Segger driver issue. Anyways, I won't spend more time on this.