I am trying to debug a simple eCAN application that sends a
single CAN message 1x/sec, as described in Lab 9 of the TI
"Implementation Tutorial" for the F2812, using an ezDsp
board with Zwickau adapter board to complete the CAN port. I
configure my CAN engine with the InitECan() function that
ships with controlSuite.
The critical segment of this function is where it programs
the timing registers in the following manner:
1. Set bit CANMC.CCR.
2. Wait until bit CANES.CCE goes high, indicating that
CANBTC is accessible.
3. Program the CANBTC.
4. Clear bit CANMC.CCR.
5. Wait until bit CANES.CCE goes low, indicating that
CANBTC is not accessible.
When I first power up my ezDsp hardware, this function
always completes successfully. If I have a problem later on
in the debug session and reset my MCU with the CCS command:
Target/Reset/Reset CPU
and try to run again, the processor hangs in the
InitECan()-loop:
do {
ECanaShadow.CANES.all = ECanaRegs.CANES.all;
} while(ECanaShadow.CANES.bit.CCE != 1 ); // Wait for CCE bit to be set..
which is where it is waiting for permission to change the
CANBTC register.
If I:
- Bail out of the debugger,
- Remove all external circuits from the ezDsp board,
- Cycle power to the ezDsp,
- Restore external circuits, &
- Restart the debugger
it DOES run past this point, but that is a powerful amount
of effort to restart a debugging session. It also means (to
me) that the "Reset CPU" command does something less than a
hardware reset, and is going to be a royal pain in the
keister when I have the CAN engine working and am trying to
get higher-level functionality running.
This question has been posed--in assorted forms--by several
other posters to this forum, but none of them IMHO got an
answer.
If this is because the chip is designed to operate this way,
I would like for someone to just say so and I will modify
my methodology to cope with it.