hi
i bought a ulink2 today to debug an application i am building on AT91SAM7X256 and i should say i am sort of lost and disappointed. previously i was using the simulator to trace the application and it was working somehow fine except that some of the peripherals were not supported by the simulator and that debugger became rogue at times ruing off to some bizarre address in run time. I was thinking this all would go away once i could get my hand on a hardware debugger such as ULINK2. the code is compiled and i can download it to the microcontroller on chip flash using ULINK2 unless i don't really know the difference between compiling and downloading flash-sam-ICE, sram-sam-ICE, flash-ULINK and sram-ULINK. so that would be my first question, what are they and what's the difference between them? my second question would be that i can never download the sram section of either of these, it gives me a DLL error. when i download the flash i can't assign any more than just two breakpoints which i can live with but no matter i do (pressing F10, ctr+10, F11 or whatever) the microcontroller just keeps running in a free mode with no indication in the debug environment as what line it is executing and no parameter value being updated. i have been through the basic help of ULINK2 in keil and i have tried a verity of options all of them seemingly yielding the same result. is it normal? what's the point of using it then? just to get rid of sam-ba?
You seem to be going in endless circles with this stuff, why can't you get with Keil Support and work through your issues?
ARM7, it only has 2 hardware breakpoints.
You'd compile and load stuff in RAM so the debugger can insert software breakpoints (not hardware ones) easily. This would be SWI or BKPT type commands.
You'd have to build smaller projects that FIT in RAM. And use debugger scripts to load into RAM.
DLL Errors? What specifically do the errors say? This is the first step to understand what is wrong.
If you have one of the regular evaluations board, then your first step should be to get the serial port working so you can output to a terminal application, and get a feel for what's going on in the system. ARM7 systems are antiquated, there are a lot of current Cortex systems that have easy download to flash and 6 or so hardware break points.
The ATMEL parts might be limited in the debugability, it's been ages since I actively used SAM7 parts. I've definitely stepped through SAM9 code with ULINK and JLINK debuggers, but then all have a lot more SRAM or SDRAM.