This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Interrupts not running when executing code on reset (kitCON167-CR)

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

Parents
  • 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

Reply
  • 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

Children
No data