We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello!
I've been using Keil IDE for 8051 since years and it always worked fine. Now I need to work with ARM processor. Since I'm new to it, I wanted to start with the examples. I got the MCB2300 board v4.0 with uLink 2 and, of course, the appropriate Keil ARM IDE with RV.
1. In all the documentation it tells about the JTAG jumper to be set for uLink - but there is no JTAG jumper
2. When I open the example project "blinky", the target is set to LPC2378, though the MCB2300 has LPC2368. The abstract.txt says, there is a target called "mcb2300 flash", but it's actually named "lpc2378 flash".
3. In the target settings, it already selected ULINK debugger, which is set to 1MHz speed, though the online step-by-step guide says it should be set to 200kHz
4. Compiling the project works fine, but going to debug reports error "memory mismatch, address: 0x0, value: 0x0, expected: 0x18" - this looks like there was no code. Is it required to create a hex file and if so, why is this not activated in the target options? I thought these are ready-to-run projects.
5. After activating "Create hex file", it still shows the error, but enters debug mode and the disassembly windows shows more than zeros
6. The code is running instantly, at least the JTAG interface says so. But there is no LED bar or character display on the LCD. The little beeper produces low, high frequency noise. Looking into the code (as far as I understand the ARM assembler) tells me, it is not correct. Resetting the target to 0 and going stepwise lets the debugger jump to address 0xfffffff3 after a few steps. So the debugger does not really work. If I let the the code run after reset and stop it, it halts at 0x0000000C, going in a loop to 0x00000014. Not really a working code...
7. Opening example projects with abstract.txt in it gives error "abstract.txt contains a invalid path". Huh? Since when can a text file contain a path?
8. At least, example project EasyWeb compiles and uploads to the MCU. But then it says "Can't stop the ARM device - check JTAG cable". Hilarious! There is a hardware debug tool with a reset line and it can't stop the controller! Even I manually reset the whole board by unplugging the USB cable and inserting it again, the flash uploader gives the same error. Sure, it is possible that the cable is broken, but board and uLink are quite new and the cable has only beed unplugged a several times.
Now I wonder how this can be possible. I mean, it can't be the way to read hundreds of pages and books just to be able to setup Keil! Why must every tiny piece of software have thousands of settings? An ARM controller might be more complex than a 8051, but from the IDE it is still the same. Setup, project, compilation, debug.
This is a hardware/software package that costs some hundred or even some thousand Euros. I simply expect it to work! I mean, what else can occur if not even small example projects work?
(By the way, selecting a different country still shows the american flag on the preview)
If it was only that... I don't know if Keil has released different versions of the MCB2300 with different LPC models, but ours has the 2368. Also, the example projects are more or less simple demonstration software that doesn't use external memory management etc. But, like I wrote above, I took a project from uTasker that is available as hex file for LPC23XX, ergo not specifically for the 2368, and this runs fine. Taking the code project as it is, opening it in Keil, setting the processor type in config.h and compiling it - does not run correctly (the tasks don't seem to be initialised). Debugging the code annoys me with error requesters like I could only set two breakpoints when debugging in Flash and unlimited when debugging in RAM. So I deactivated "Dowload to flash", assuming this would result in RAM debugging, but after two breakpoints I couldn't set another one. Is this because of the debugger or is JTAG not capable of doing more? I often cursed the Hitex DProbe we use for the 8051, because the Hitop software is also a PITA, but compared to this it is heaven. The Keil debugger is not able to perform true step-by-step code processing.
Debugging the code annoys me with error requesters like I could only set two breakpoints when debugging in Flash and unlimited when debugging in RAM. So I deactivated "Dowload to flash", assuming this would result in RAM debugging, but after two breakpoints I couldn't set another one. Is this because of the debugger or is JTAG not capable of doing more? I often cursed the Hitex DProbe we use for the 8051, because the Hitop software is also a PITA, but compared to this it is heaven. The Keil debugger is not able to perform true step-by-step code processing.
Err, what?!?!?!?! how is this related to Keil , exactly?!?! Hardware breakpoints are implemented using an EmbeddedICE logic point to detect an instruction fetch from the appropriate address. This works in all cases, even if the program being debugged modifies itself as it executes, or if the code is in ROM. However, it completely ties up one of the two available EmbeddedICE logic point units.
Thanks for telling me. Now I see that the controller is the reason. How could we imagine to have a fully functional development system which saves time and effort with just switching to a controller with a JTAG interface? You read everywhere that this is called "integrated debugging". This is not debugging, this is a joke. Anyway, the Keil debugger is a part of the IDE, it controls the interface (uLink). It should at least be able to perform step-by-step code execution, no matter what controller I have. If required, it should be supported by hardware to circumvent the limitations of the controller. In german, the word "ARM" means "poor" and that's what this chip is...