Hi, Has anyone had problems when debugging with the ULink USB adaptor? I'm using it on the Infineon XC164CS development board, which has the standard 'wiggler' interface, but I'm having a few problems particularly when using breakpoints. One of the problems I had was trying to locate the source of some stack corruption I was experiencing. Something was overwriting the end of the stack, which happened to be at address 0xC668. I set a breakpoint to stop the program whenever 0xC668 is written to. The program stops at my initialisation code as expected, but uVision 2 crashes when I run the code again. In this situation, I have to go through task manager to quit uv2.exe. Other problems wrise if I am stepping through some code like this:
if ( !led_output_ready() ) { do_something(); }
Hi Paul, don't know, whether I can exactly help you with your problem, but may be some hints can help you. I got problems in generally with versions up to V4.25. First successfull debug session I had with v4.26J. As I know in earlier versions the driver has some difficulties with timing. If you mention the "On-board-Wiggler" - did you disable for working with the ULINK ? The Wiggler is for direct using with the parallel cable only. If you try to OCDS-debugging via Wiggler-Interface, be sure to have disabled all other parallel port drivers. (This point costs me 3 days of time). Here I got similar experiences with sporadic crashes and very suspect timings. After disabling all went fine. If no Wiggler in use ( as above ) what are your settings of DIP-switches ? With ULINK itself I have good experinces, but I have to find out, that the DIP-switch settings as in the OCDS tutorial ( description) completely not works. I experimented with my own settings and now it works. At last - ( that may be my error ). I recognize some times at debugging, that the OCDS flash loader programs did not really reprogram the internal flash, so I debugged wrong code lines. ;-) As workaround I program with memtool - but debugging than goes fine. And there is one point - you should be sure too, that all is fine. I have got some messages about - that some boards have problems with the debug pins. Either the JTAG pins are not soldered in clean way (or absolutely not) - otherwise there was hint to use resistors for pulling (up/down) the JTAG pins, if trouble in communication. Hope some hints can help. Stefan
Hi Stefan, Thanks for your reply. I've managed to make some progress using different combinations of breakpoints and debug code. I did mention Wiggler, but this was a mistake on my part. I was using Wiggler until the ULink arrived, but neither connection method seems to be without its flaws. As for the actual physical connection, I think it is OK since debugging seems to fail only when performing certain activities, such as those mentioned in my first post, above. I will bear in mind your comments about using Memtool, it may make a difference when debugging in future. It is frustrating when a debugger causes your entire PC to crash - I'll have to invest in a CD of calming beach noises to play next time it happens! Thanks, Paul.
Hi Paul, thanks for answer. I tested a similar code like yours, but I got no crash results. I did a test with different PC's and OS. I tested with WIN98, WIN2K and colleaque did a test under WINNT4.0 (SP6). So may be that difficulties occur with XP or ME ? What about your driver settings for OCDS Driver XC16x ? I checked "Load application at startup" "Go till main()" Under 'restore debug session setting' "Breakpoints", "Toolbox", "Memnory Display" Under 'Settings' "KEIL ULINK" unchecked all --> 'CACHE OPTIONS' unchecked all --> 'RESET CONFIGURATION' ( last depends from your hardware ) Since I do not know your versions: If you have a option "OCDS break level" do not set to values less the highest possible, or better get a newer version. There were some difficulties with background debug process as I remember. This option is not available anymore with newer versions. BTW: Which STACK is overwritten ? If I hold the userstack internal via USERSTACKDPP3 than I place it at memory range 00Cxxxh. Do you deal with idata or sdata ? OK - this should not be relevant , but who knows ... Stefan