Having had problems in the past trying to debug FastGPIO, I recently tried again.
I've just spent a considerable amount of time isolating what I believe to be another interesting (and frustrating) bug in the uVision debugger. I hope this may save someone else some time...
I'm using MDK v3.20 targetting an NXP LPC2142. When I try to initialise FastGPIO, the debugger shows some very odd behaviour. Basically, the FIO0DIR register appears to change its contents following execution of an instruction that does not reference it. I say appears because I am convinced this is a debugger bug rather than a hardware problem.
A fragment of my c source looks like this :-
// Enable FastGPIO on both I/O ports SCS |= (GPIO0M | GPIO1M); // Set masks FIO0MASK = ~CPLD_P0_OUTPUTS; FIO1MASK = DATA_BUS_MASK; // Set Port 0 designated bit directions FIO0DIR = CPLD_P0_OUTPUTS;
With optimisation set to Level 3, this results in the following generated code :-
97: SCS |= (GPIO0M | GPIO1M); 98: 99: // Set masks 0x00004FF4 4935 LDR R1,[PC,#0x00D4] 0x00004FF6 6A08 LDR R0,[R1,#0x20] 0x00004FF8 2203 MOV R2,#0x03 0x00004FFA 4310 ORR R0,R2 0x00004FFC 6208 STR R0,[R1,#0x20] 100: FIO0MASK = ~CPLD_P0_OUTPUTS; 0x00004FFE 4934 LDR R1,[PC,#0x00D0] 0x00005000 4834 LDR R0,[PC,#0x00D0] 0x00005002 6101 STR R1,[R0,#0x10] 101: FIO1MASK = DATA_BUS_MASK; 102: 103: // Set Port 0 designated bit directions 0x00005004 4934 LDR R1,[PC,#0x00D0] 0x00005006 6301 STR R1,[R0,#0x30] 104: FIO0DIR = CPLD_P0_OUTPUTS; 105: 0x00005008 4931 LDR R1,[PC,#0x00C4] 0x0000500A 43C9 MVN R1,R1 0x0000500C 6001 STR R1,[R0,#0x00]
Following single-stepping of the line at 0x00005000, which loads into R0 the base address for the Port 0 FastGPIO registers (0x3FFFC000), the FIO0DIR register (as shown in the peripheral dialog) changes to this same value (0x3FFFC000) !
When I subsequently single-step the line at 0x0000500C which should change the value in the FIO0DIR register, it is not shown to change. I can change it directly by editing it in the peripheral dialog.
This does not happen with optimisation set to Level 0.
Needless to say, when you can't depend on the debugger, debugging is made somewhat more difficult :-)
Can anyone else (Keil ?) confirm, refute or explain this behaviour ?
Regards,
David
It's been my experience that debugging with optimizations set to anything other than their lowest value (ideally they should be set to 'none' for debugging), that debuggers struggle a lot (when it comes to showing the user what they want to see). The generated code is more difficult to relate to the original source when optimizations are enabled, making it hard for the debugger to clearly show what's really happening. This problem exists across all tool vendors (i.e., it's not just a KEIL problem... it's a problem for everyone).
Hi Dave - I absolutely agree with everything you said,
Unfortunately, compilers (and developers) have a nasty habit of introducing problems when optimisation is turned on, and we have to be able to debug in those circumstances too.
However, in this particular instance, that is not the specific issue.
When the debugger purports to show the status of hardware registers and then arbitrarily changes what it is showing you when single-stepping an instruction that should not affect those registers, this, to me, suggests a more fundamental (quality) issue than just the optimisation level.
What I presented above is just one example. I have quite a few more where unrelated registers appear to change when they shouldn't. The whole FastGPIO area appears to be a minefield with uVision.
This isn't intended to "have a go" at Keil. The tools they provide offer some pretty useful and unique development and debugging features. However, the value of these is significantly diminished when you can't rely on them.
David.
David; I have the same problem. See the thread http://www.keil.com/forum/docs/thread11979.asp I have sent a report to tech support and they confirmed they could reproduce the bug with my stripped example. I have not heard from tech support. Please file another bug report to tech support with this info. Maybe we can get an answer. It is not hardware nor optimisation. It is a bug in the debugger program. Bradford
Thanks Al - glad to see I'm not alone.
I looked at the thread you mentioned. Coincidentally, I too am using the older uLink rather than a uLink2 - I wonder if that is significant ?
I did report a similar problem relating to FastGPIO and registers mysteriously "changing" more than a year ago, via my UK-based distributor, and never heard anything back from Keil. However, I'll try again...
Some interesting comments from Robert @ Keil in http://www.keil.com/forum/docs/thread11208.asp suggest that Keil were aware of the bug and believed it was fixed.
David; I am using Ulink2 and here is my tool set versions. I still have the problem. The step number on my NXP LPC2378 chip is BY. So, I think I have the latest of everything including the latest problem. I plan to call tech support again on Monday. I have used Keil software for quite a number of years and I have seen a problem corrected only to creep back into the code on a later version. Of course,I have never had that problem in my code ;-).
IDE-Version: µVision3 V3.60 Copyright (c) Keil Elektronik GmbH / Keil Software, Inc. 1995 - 2008
Tool Version Numbers: Toolchain: RealView MDK-ARM Version: 3.20 Toolchain Path: BIN31\ C Compiler: Armcc.Exe V3.1.0.919 Assembler: Armasm.Exe V3.1.0.919 Linker/Locator: ArmLink.Exe V3.1.0.919 Librarian: ArmAr.Exe V3.1.0.919 Hex Converter: FromElf.Exe V3.1.0.919 CPU DLL: SARM.DLL V3.20 Dialog DLL: DARMP.DLL V1.34 Target DLL: BIN\UL2ARM.DLL V1.37 Dialog DLL: TARMP.DLL V1.34
View all questions in Keil forum