I am a student using the school's copy of the Keil PK166 suite for a senior design lab. I have run into a problem when attempting to run code directly from the flash memory on a Phytec kitCON-167CR. When I reset the board, the program runs, but the interrupt service routines to not seem to be called. Is there some setting that I'm missing? My procedure: -Set up a project in Dave -Use template .uv2 file from HOT for C166CR -Insert and compile code configured for Phytec kitCON-167CR -Run flasht.exe (Infineon FlashTools) and download HEX code to the flash memory. -exit flasht.exe, switch S3 dip switch position 1 to the off position -reset board When the program runs, it executes code not contained in interrupt service routines. When the compiler is run in debug mode, or if I select "Run from address" in the FlashTools, then the interrupts work just fine. (I give the starting address of the main function when using FlashTools). I believe that I'm just missing a setting somewhere, something with the interrupt vector table? Any help you can provide will be greatly appreciated. -James Southard, Jr Senior EE Undergraduate University of South Carolina
Running your program from the address of main skips the startup code, which should initialize SYSCON, BUSCONx, DPPx, STKOV, STKUN, SP, CP, R0 registers as well as global and static local variables. So it's pretty surprising that your code works without that. Presumably, in this case it uses initialization of FlashTools. Probably, some settings in startup.a66 are wrong. Try looking in startup.a66. Also check if the interrupt vector table is in place. I can't see why interrupts wouldn't work with IEN=1, ILVL in PSW low enough to accept interrupts and interrupt vector pointing to the ISR. If there is a display in your target hardware, try printing the contents of some registers to see what's happening. Best luck! - Mike
I'm inclined to believe that the interrupt vector table is not in place, but I don't know how to check it, or what place it's supposed to be in. I just figured that I'm missing a configuration in Keil (as mentioned before I'm just using the template config that comes with the Hands-On-Training) I agree with the surprise that it works by starting the program at main()...but I guess it's not much different than running it from the monitor. Thank you for your feedback, and hopefully I can get this problem sorted out quickly.
If everything runs OK when you use the monitor but NOT when you use your program stand-alone (without the monitor), the problem is probably in your configuration (the stuff in the startup code). Find out if there are special things that must be set for the Phytec board. If you give them a call, they can probably give you the correct startup code for that board. Jon
Is the startup code usually found in something with a name similar to start*.a*? I always assumed that the .asm file that was given with the code generated by Infineon's Dave software contained the necessary startup code. Should I try including a start*.a* file in the project workspace (I think there are versions that came with the board)? Again, thanks for your help.
Well, the start*.a* didn't seem to help. Actually, at this point, the code will no longer run when it's executed from the starting address of main, so now I'm worse off than before. I guess I won't find an answer to this problem...
The startup file is usually 'keil\c166\lib\Start167.A66'. This file must be included in your project to be made. I always make a copy local to the project so changes to it will only affect a single project. The rub is that the monitor (uded during UV2 debugging) must also be configured using the 'keil\c166\monitor\Phytec KC167CR\Config.inc' file. If you change the project settings you should also change the monitor configuration and rebuild it. For this reason I also include a copy of the entire monitor project under the project directory tree. You should have your vectors based at 0x00'0000 in ROM (during debug you assign RAM as ROM). You can look at the addresses in the M66 file for the project after a build (turn on all output listing stuff in the project). DIATRIBE; The use of Dave has screwed up every project I've seen it used in. It is a tool which tries to make the user be able to produce code for a processor without understanding the idiosyncrsies of the processor. The code produced has everything global (a big no-no) and you now have to maintain an extra level of tools and configurations. If someone in the future changes one of the functions produced by Dave without using Dave, then someone else remakes the project in Dave, the changes may be gone and old bugs reappear (I've seen this often). Dave should only be used for simple experimenting on the processor, not code development. But if you expect to get a free lunch by not having to understand the processor, you're in for trouble. Best luck
Have you contacted Phytec to get their example programs? I know that they have created examples using the Keil tools with their boards. Without knowing what you are actually trying versus what you say you are trying, it's impossible for us to guess what might be the problem. My experience indicates that you probably have a startup code issue. That causes over 90% of the problems we see with the C16x devices--especially when you have a known working board. Jon
I have the hands-on-training from Infineon, but I haven't looked into the code samples from Phytec. Do the code samples cover running the program from the Flash? I believe it's a startup code issue as well and I'm going to look into it further. ->Scott: thanks for the comments. I'd like to point out that the only reason I've used Dave is that I'm using the Phytec board for a senior design project (Development time: 2 months in between a full-time load of classes). I would prefer to go without it, but I do not have the time to do so. (I prefer working without tools that abstract away understanding, but I don't have much time and probably won't work with the board again after I graduate). I'm going to try a few more things and post what is happening.