Post Go back to editing

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

Hi,

I'm having a rather strange problem with the VIC and executing the ISRs in ADuC7124, and I'm seeking an explanation to what is actually happening and why it is intermittent at best.

I have included a cut-down sample project in IAR 9.20 that uses Timer 2 ISR to simply turn on LED D2 on the ADuC7124 eval board. I have also included the hex file. When the ADuC7124 has been programmed, I just unplug/replug the mini-usb power supply connector. At random startups, D2 never lights up, as the ISR never fires.

I would really appreciate if someone from ADI could support in finding the cause, as I have already completed the other project - except for this strange behaviour. I have spent almost a week now on this single issue, and am completely out of ideas.

Thanks.
Kind regards,
Troels

IAR_EWARM_VIC-ADuC7124_T2_example.zip

Parents
  • 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 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?

Reply
  • 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?

Children
  • 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.