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)
No offense, but ALL, yes ALL of the trash you hurtled at Keil here is due to your complete ignorance of the tool-chain. small tip: a project can have multiple targets, including ones that run in RAM...! I have complaints, too (thanks Keil for forcing em to write a FAT12 file system myself, because RL-ARM FlashFS cannot create such an image in RAM...) but your boil down to utter lack of knowledge. Have you actually read the manual?
...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...
what a fantastic claim. I'm holding my head now and thinking: "was I dreaming yesterday afternoon when I was debugging my 15000$ product or was it for real? Is my file system a product of my imagination (I admit there are still bugs!)..." Hell, if you insist on physical proof see here: sourceforge.net/.../ Developed with this debugger that "does not work".
Give me a break...!
The problem is, there are many manuals to read. Software should be intuitive. I can operate any Adobe tool without reading a manual. With KEIL, it is different. The uVision IDE for 8051 is easy to use. The ARM version now is much, much more complicated. For example, the uLink debugger manual does not describe how the debugger works. By default, the option "Download to flash" is not activated. The related description just confuses. And if I wonder to where the debugger downloads the code, if not to flash, I actually want to find an explanation in the manual.
It seems you didn't understand what I meant. The first thing I meant is, that the manuals are sometimes outdated. They describe things that aren't present anymore, like a jumper named JTAG. Second thing I meant is that there are example projects from KEIL for the MCB2300 and if I open, compile, upload and run the projects, they just don't work. For this, I don't need to read a manual.
For testing purposed I tried several of the example projects. None of them worked on the MCB2300. Since we are working on an embedded Ethernet project in our software department, we decided to use ARM with Ethernet (LPD2366) and the MCB2300 and Keil, because we know Keil since years. Because the NicheLite package did not work as expected, we found the uTasker project to be a replacement. But here it is the same: there is a hex file of a project, when uploaded to the board by FlashMagic it runs fine and I can access the website. If I open the project in Keil (there is a version for Keil and LPC Arm), I can compile and upload it through the debugger and it does not run correctly. Sure, the person who created the projected has tested it, but the difference here only is he might have had a different debugging hardware. So I set up the project to my debugger and my LPC model, it should actually work. But it does not.
By the way, why do you defend Keil? Are you an employee? Do you owe them?
Geez, this is not about Keil. I wouldn't complain if this were all free software and we only had to buy the hardware. But this is not free software. It has high prices and should the hell do its job. I can read x times through the manuals without any sense, if the damn tool chain does not do as expected. This is annoying. We don't have time to waste with problems like these. Time is money.
Do you think I enjoy seeing some tasks of the latest RTX locking up after 2-3 days of uninterrupted work? this is what you get with complex software (sometimes), and the developers at Keil are as susceptible as you and me to mistakes. be patient...
I did not have these problems when starting with Keil/ARM. The only problem I had, was that I had to wait a number of months to get simulation support for the LPC23xx chips. And after that, I had to wait further for a fix for correctly reading back fast-GPIO state using the JTAG interface.
I can't say I think the tools are non-intuitive. I got most if it working without the manuals. I often like to start out directly, and as step 2 - when I have some general knowledge about a product - pick up the manuals to see if there are features or limitations mentioned, that are not obviously observed by just using the tools.
Reading the manuals first often just requires a second pass through them because I'm not able to correlate some descriptions with the actual use until I have tried the product or already read the manuals once before.
A big problem when writing a manual is to write it in an order so the user has picked up the required background knowledge from earlier chapters. An example is a part of the manual that talked a lot about the use of a wizard. It took some time to realize that I could switch view for the startup file - either seeing the assembler source, or an input form. I'm so used to wizards being invoked as toolbar buttons or menu choices that I didn't think about looking for alternating views for open windows.
Maybe take a couple of seconds and look at the "The Insider's Guide To The NXP LPC2300/2400 Based Microcontrollers" from HITEX it helped me a lot when starting with ARM development.
But other than that getting from your description of how the board runs when uploaded with compiled application, I would guess that the target uC is not correctly selected/setup in startup file. LPC2378 instead of LPC2368 - where LPC2368 doesn't have external memory controller and if selected in startup file the board will not start properly.
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.
Geez, this is not about Keil.
You don't say. Seriously: you don't say anything to that effect.
So far everything you've written in this thread, from the Summary entry to the text itself, is quite clearly about Keil.
tool chain does not do as expected.
Expectations are a business involving two parties. One of them usually is a human being, i.e. you. It doesn't have to be the other end that's at fault if they fail to come true. Did it occur to you that maybe your expectations might be based on bad assumptions?
In other, words: you need to cool down, man. Get a hug from someone, grab a beer, or whatever usually helps.
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.
Gute Idee. Leider steht dem der Zeitdruck, Termine und Auftraege entgegen. Und das in einer Zeit, in der die Wirtschaftslage alles andere als rosig ist. Da kann man sich solche Spielchen einfach nicht leisten. Man steigt auch nicht mal eben so auf ein anderes Entwicklungssystem um, zumal man nicht sicher sein kann, dass dieses besser ist. Falsche Vorstellungen? Vielleicht. Wie gesagt, bis dahin, was wir uns vom ARM vorstellen sind wir ja noch gar nicht gekommen. Es hapert ja schon bei dem, was eigentlich laufen muesste.
I realize that you are under time pressure, but that is a problem on your side, not relevant to the Keil tools.
Yes, Keil has multiple versions of the development board. You could have it with 100-pin or 144-pin 23xx chips - if your board has a 100-pin chip, you will notice the second set of pads on the outside of the chip.
What happens if you do not try to build any code, but just download the precompiled examples?
About hardware breakpoints - when running in flash, you are limited by the support in the ARM chip. The JTAG interface is just an interface - the big part of the debugging is inside the ARM chip. This is a difference from a real emulator.
When debugging in RAM, then the JTAG interface can be used to replace instructions, allowing software-generated breakpoints.
The above isn't unique for Keil development with the LPC23xx chips. If you switched to Atmel AVR chips, you would find similar behaviour, but with the optional extra that the Atmel AVR tools would allow programming of software breakpoints in the flash too. Helps getting an extra breakpoint, but also helps greatly if the goal is to wear down the flash sectors. In the case of the Atmel AVR chips, each flash sector is tiny. The LPC23xx flash sectors are big. Big means big wear, since there will be way less wear leveling.
Not downloading to flash will just stop the download cycle - the debugger will assume that you already have the firmware downloaded. Either since a previous run, or that you have used FlashMagic or similar to program the chip.
The demo applications has - as already mentioned - more than one target defined. When you switch the build target to RAM, you will get the project settings optimized for RAM debugging. The memory regions specified in the project will not mention the flash - instead some of the RAM will be specified for use for code. The RAM target will also specify a debugger script, that will set the PC to the start of the RAM copy, instead of trying to start program execution from the reset vector. This step is needed, since the RAM target will not download any code into flash - the reset vector will have undefined contents.
In this case, you have lost a lot of time because you wanted to save time. Instead of doing things one step at a time, you went five steps ahead. Then you got lost, and angry about the tools. Having already taken 5 steps, you are now in a no-mans-land, where you do not know which of the five steps that where wrong.
It is always advantageous to take a bit of time to familiarize yourself with new tools before expecting to be productive with them. The play time will pay off in the end. It's the early shortcuts that will cost the most money.
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...
The demo applications has - as already mentioned - more than one target defined. When you switch the build target to RAM, you will get the project settings optimized for RAM debugging. I don't know what demo apps you are referring to, but most of the demo apps have only one target (either 'MCB2300' or 'MCB2300 board'), while "blinky" has a "LPC2378 Flash" target. This is the mess I was talking about. These are all demo apps in the /boards/keil/mcb2300 folder and the all have different target names. If I open the "blinky" demo from that folder with "LPC2378 Flash" target and change the controller type to LPC2368, compile it and want upload it, the flash uploader tells me "Could not load flash programming algorithms" (LPC_2000_IAP2_512.flx). Now you tell me this is all my fault?? The target dialogue has no option for which memory segment the code is compiled. The only difference is in the debugger dialogue, where you can select "Download to flash". But even if it was as you said and the demo apps would have two targets, then both targets should work and the compiler should do accordingly.
The different boards have their examples in different directories.
But when you open a Keil example for a specific board, then the project file contains one build target for running in flash, and one build target for debugging directly in RAM.
There is most definitely input boxes to specify the memory range to use for code and the memory range to use for RAM. Each target in the project file has its own set of all settings.