This forum was established for computer programmers, especally embedded programmers to ask/answer questions and share experiences in programming to make programming life less frustrating but more enjoyable.

We have been struggling here with what we think is a software initialization problem. Previously we were running a motor with no apparent problems but now we cannot seem to get a valid commutation sequence started immediately following release from reset.

We are using the SM320F2812 DSP to drive a DC brushless motor. Using the JTAG port we release from reset and initialize the registers. The EVA CAP inputs are configured to interrupt on either edge. We have hall effect devices on the motor. If A and B are high initially, and C is low, the DSP will have 2 interrupts pending. S/W runs thru the ISR 2 times and these interrupts will clear. Then we rotate the motor by hand until the next hall state. What are seeing is no response to the hall signal which was initially Low after reset on its' first rising edge. In this example, C. The DSP recognizes a state change on the CAP3 input ( Hall C) on the next edge (falling) and all subsequent edges. This is a minor issue, and probably no concern.

Previously, all I/O was initialized to a low state. When we did this, the DSP never recognized a state change on the hall input(s) which were initially low (in our example, C). Now, we are not initializing the I/O and this appears to have "fixed" the problem, except for the very first low to high transition.

According to the description of the CAP module operation, each CAP unit has a dedicated 2-level-deep FIFO stack. When the first edge transition is detected, the counter value of the selected GP timer is written to the top register of the FIFO stack, if the stack is empty (it is so in your case at the beginning). At the same time, the corresponding status bits are set to 01; when the second edge transition is detected, the newly captured counter value goes to the bottom register of the FIFO stack, meanwhile the corresponding status bits are updated to 10. The appropriate CAP interrupt flag is set by the second capture. A peripheral interrupt request is generated if the interrupt is unmasked. And more interrupts are generated on the following transition detections. That explains why you don't have interrupt at the first edge detection from low to high.

However, there is a way to trick it to have interrupt at the first edge transition, which is, preset the status bits to 01 by utilizing the write programming advantage of the capture FIFO status register.

This trick lets the CAP module to "believe" that there is already an entry in the FIFO. Subsequently, every time, including the first time, the FIFO gets a new value, a capture interrupt will be generated. Now, since I don't have the hardware to verify it, can you guys give it a try and let me know if that works?