I am a student intern using an Infineon C167CS-l40M mounted on Phytec module phycore 167HSE. I have been using DAvE 2.1 r22 and Keil uvision3 v3.05. I am developing SW that will generate a PEC transfer on the negative clock edge to grab data one byte at a time from a memory location and send it out parallel port 2. I am generating the clock from T3OUT (P3.3) using GPT1 timer 3 in timer mode, reloaded from timer 4. This clock is then fed back into CC23IO (P8.7). The reason for this setup is that I will eventually be using this clock to time events on multiple controllers, but for now just testing it on one controller. Anyway, CAPCOM channel 23 is configured to capture the negative clock edge and initiate a PEC transfer that will move consecutive bytes of data from adjacent memory locations to be output through port 2. So far, the clock signal looks good on the scope, so that part of the code is working, but the CAPCOM interrupt is not being invoked, there is no PEC transfer, and when I go into debug mode and single step the program, it gets hung up and crashes right at the line P3 = 0x0000 in the IO.C file. I have included some of the code below, if anyone has any thoughts please post. Thanks! Dave from main.c
void Send_One_Shot(void) { msg_size = 3; tx_buffer[0] = 0xF1; // Node tx_buffer[1] = 0x06; // Command tx_buffer[2] = 0x01; // Parameter tx_buffer[3] = Checksum(msg_size); PECC0 = 0x0504; }
ODP3 = 0x0000; // load open-drain register P3 = 0x0000; // load data register POCON3 = 0x0000; // load output control register DP3 = 0x0000; // load direction register
P3 = (P3 & ~(uword)0x0008) | 0x0008; //set data register DP3 = (DP3 & ~(uword)0x0008) | 0x0008; //set direction register
PECC0 = 0x0501; // load PECC0 control register SRCP0 = _sof_(tx_buffer); // Point PEC data source pointer back to start of table DSTP0 = (int)(&P2); // PEC destination port 2
My guess is that when you write 0 to P3 you are configuring the RS232 transmit pin to an input which kills the debugger. -Walt
Walt, thanks for the reply...actually that code was generated by the DAvE program. In IO.c, It initializes the DDR to configure the pins as inputs, then in the GPT1.C file it adjusts P3.3 to be an output as needed for the T3OUT functionality of that pin. I did consider what you wrote and tried the following:
ODP3 = 0x0000; // load open-drain register P3 = 0x0008; // load data register POCON3 = 0x0000; // load output control register DP3 = 0x0008; // load direction register
I beleive that the RS232 transmit pin is P3.10 which you are configuring as an input. The debugger is RS232 based so if you render the transmit line unusable the debugger crashes. If you enable the ASC0 module in Dave, it should generate the correct initialization code for P3. My guess is that you have it disabled. -Walt
Walt, thanks again for writing...what you are telling me makes sense, so first, I undid the changes I mentioned above. Then I went ahead and enabled the ASC0 module using DAVE. I made sure 'enable module' was checked, and under the Control tab, I checked the box for 'Tx pin (P3.10) Selected'. Still, the program hangs at the same spot every time. I also deselected Tx pin just to see if any change, but no. I should probably also mention that the original version of this program was just the timer generated clock with no CAPCOM interrupt calling for a PEC transfer, and that version worked fine with no hangups. Also that program did not require the initialization function IO_vInit() [which calls IO.C] to run, so right now I tried disabling IO_vInit() & now the buggy behavior is gone, but not a solution since I need IO functionality to carry out the PEC transfer. Anyway, it's a start. I really appreciate your taking the time to answer my posts, if anything else comes to mind, let me know. In the meantime, I am going to focus on that IO_vInit() function.... Dave
If you use the monitor to debug your program, then your program ABSOLUTE MUST NOT change the settings of the serial port pins or of ASC0. Even if it reconfigures the serial port, it causes the debugger to lose the connection. The problem is that the serial port is already configured when your program runs. There is no reason to re-configure it. Jon
After much head scratching, I found that Walt's suggestion was right. Instead of messing with the ASC0 module, I just went into Port 3 settings in DAvE and set P3.10 to output (high) and P3.11 to input. Manually, I could have changed the initalization code to look like this:
ODP3 = 0x0000; // load open-drain register P3 = 0x0400; // load data register POCON3 = 0x0000; // load output control register DP3 = 0x0400; // load direction register