ADUC7024 & IAR & J-Link

Hi,

I am having problems downloading the compiled code into flash memory of ADUC7024, my design. Can somebody give me a hint about my wrong-doing?

I use IAR KickStart development kit, version 4.42, which came in a bundle with the development kit STR750-SK. The kit included J-Link programmer.

- I can write the program using IAR, compile it, download it into ADUC's RAM using J-Link, run it and debug it. Works fine.

- I can write the program using IAR, compile it into .hex file using Intel-extended format, download it into ADUC's Flash using ARMWSD and RS232, and run it. No debugging available, otherwise works fine!

- I tried downloading the compiled program into ADUC's Flash using the J-Link. The programming does not work, I get the error message from the verification part of the programming stating the difference between the content of the Flash and the programmed value.  The content of the flash does not change during the programming.

I am using the unmodified *.xcl files that came with the IAR Kickstart "ADI702x_FLASH_Standalone.xcl" and "ADI702x_RAM.xcl", and downloading without the "Use flash loader(s)" option ticked at Options/Debugger/Download.

Can somebody give me an advice to program a flash using a J-Link (the debugging of the program is essential)? Thank you!

Additionally, I am having problems simulating the code in IAR, the interrupts in particular.

The interrupt vectors get written into either RAM (0x10000 and onwards) or Flash (0x80000 and onwards) for simulation depending on the *.xcl file used. However, the simulator pretends to execute the software directly from RAM or Flash (the stated content of PC), but looks for interrupt vectors at address 0x00000 and onwards, where either RAM or Flash should be mirrored in real device (but apperantly they are not in simulator).

How to make simulator pick-up the interrupt vectors from correct place or to make the simulator mirror the code? Again, thanks for the hint! And by the way, the same code that crashes in the simulator due to uncorrectly retrieved IRQ vector works fine in hardware!

Many thanks for having the patience with reading and best regards.

Dusan

  • 0
    •  Analog Employees 
    on Mar 10, 2011 2:08 PM

    Dusan,

    V4.42 is a old version of the IAR tool-chain which I don’t have installed any more.

    There was a major change in this tool-chain when the versions went from 4 to 5. Even now, the current revision is v6.

    Also, the kit that you are using is an STMicro kit, for all I know that is only supposed to work with their parts. Or the issues you report have been addressed in a newer version of the tool-chain.

    Please install the latest QuickStart IAR EWARM from the IAR website (which is at least v6.10) and try working with the ADuC702x examples from the examples directory in that version of the tool-chain or from one of our evaluation CDs.

    In relation to the simulators that come with any of the compiler tool-chains, I am not sure how well these match the real hardware as we don’t validate them.

    We usually advise that you use the evaluation board or your own hardware where available. That’s no reflection on the simulators; It is impossible for them to 100% match the silicon anyway.

    This will avoid the “It’s working on the simulator but not working the same on the hardware” situations.

    It sounds like a flash programming problem anyhow, and I guess that when you upgrade you will get an update to both the firmware on your JLINK and to the flash programming files in the tool-chain and things will work.

    Start with one of the ADI provided examples and copy your work into it. That’s the best approach, and we’ll be in a better position to support you.

    As a general note, in case of further problems, post an example that “doesn’t work”. (You can attach files in this forum). IAR has many things to click and select to get things right!

  • Dear Patrick!

    OK, thanks for the suggestion.

    I have downloaded and installed the most recent version of IAR KickStart software for ARM. The situation is now significantly better for the first problem, but the second one remains.

    I can download the compiled program into the Flash or RAM of ADUC7024 and run it either from KickStart or, after Reset, from Flash.

    I can put breakpoints from KickStart into normally executable code for debug, but can not put breakpoints into interrupt code. Any hints?

    I still can not debug the interrupt code in KickStart simulator, since the simulator looks for interrupt vectors at the bottom of the memory space (address 0x00000 and on), and not at Flash or RAM area. The Flash or RAM area does not get mirrored into the bottom of the memory space either. I suppose this last is more a question for IAR than AD...

    Thanks again and I am going to fight some more.

    Dušan

  • Dear Patrick,

    The breakpoint was set at the very first statement of the interrupt code even before. I have managed to get it working, but I am not sure what I did. It suddenly started working, and I can not restore the old non-working state any more (I am quite happy with this.).

    __irq __arm void IRQ_Handler(void)          {           // IRQ Handler
            GP3SET =  0x00080000;                            // here is the breakpoint
            T1CLRI = 0;
            GP3CLR =  0x00080000;
            return;
    }

    __fiq __arm void FIQ_Handler(void)          {            // FIQ Handler
    int i;
            GP3SET =  0x00040000;
            T1CLRI = 0;
            GP3CLR =  0x00040000;
            return;
    }

    int main (void)  {
            int i;

           
            PLLKEY1 = 0xaa;
            PLLCON = 0x01;                                       // use external crystal, use PLL
            PLLKEY2 = 0x55;
           
            POWKEY1 = 0x01;
            POWCON = 0x00;                                     // Fclk = 41.78MHz
            POWKEY2 = 0xF4;
         
            GP3DAT = 0xff000000;                               // Configure port 3 as output - D
           
            T1LD = 4180;                                           // T1 load register, 16 bit
            IRQEN = GP_TIMER_BIT;                         // Timer T1 FIQ enable
            //FIQEN = GP_TIMER_BIT;                           // Timer T1 FIQ enable


            T1CON = 0xc0;                                          // T1 control register
            __enable_interrupt();                                   // Enable interrupts

           
            while(1)     {
                 GP3SET =  0x00020000;
                 GP3CLR =  0x00020000;
            };

    }

    I have also tested the suggestion about linker script file, and it corrects the situation. Now the system can simulate interrupts as well. I can only hope that the simulator behaves close enough to the hardware, as you mentioned in the reply.

    Thanks for the help. Sometimes a simple suggestion comming from an experienced person can change the situation. And reading manuals is so boring...

    Dušan

  • 0
    •  Analog Employees 
    on Mar 11, 2011 12:20 PM

    Dusan,

    Breakpoints on the ARM7TDMI are handled by the Embedded ICE, which is part of the ARM7TDMI.

    The mirroring of the flash of the ADuC702x is done externally to the ARM7TDMI, basically an address decoding matter.

    I suspect that you might be trying to set a breakpoint at 0x80018 and wondering why it does not hit when an interrupt happens.

    When the interrupt happens, the address 0x18 is presented to the breakpoint logic. This 0x18 address is where you need to set this breakpoint.

    In terms of the simulator, it probably is a question for IAR.

    Note that if you are not planning to use the REMAP feature – which allows you to map SRAM to address 0x0 – then you can easily change the linker script file that you are using to place the memory at 0x0 rather than 0x80000.

    It’s still the same flash resource, and it will match the standard ARM7TDMI which will make the simulator happy. It will address the breakpoint problem also.