I have found that my project will not run correctly outside the debugger .
The problem relates to communication with the PC software. The PC software can initially connect, but goes offline after a few seconds as requests for more data are not meet. With the P&E Micro USB Multilink connected there is never a problem.
This also happened to me with another project. What is the point of a debugger if it does not give real world results. I find this very stressful as I have shipped product to the other side of the world, only to find it does not work.
I have attached the project.
Also is there some way to program the S12 without using a debugger. I would rather do my debugging by testing in the real world then use something that does not give real results.
Ray.
Original Attachment has been moved to: CAN_EGTamp.zip
Solved! Go to Solution.
I would not so easily blame the debugger! It is due to the use of the debugger, but it is not a bug in the debugger, it is a bug in your program! When you use the debugger, the EEPROM is also erased as default when you reprogram your processor, meaning that you will call the LoadStrucData()-function, and that is the only place where the rdata-struct is initialized! So when you start your application without the debugger, the EEPROM is already initialized, meaning that the rdata-struct is not initialized, defaults to zero and that is what you see!
Sten
I have found what it is doing wrong, but cannot see why. This function only works correctly in the debugger,
//----------------------- Send Real Time rtdata -------------------}
void sendRealTimeData(void)
{
rtdata.error = errCan;
rtdata.crcCnt = CalculateCheckSum((uint8_t *)&rtdata, sizeof(rtdata));
SCI0_Send_Packet((uint8_t *)&rtdata, sizeof(rtdata));
}
24 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF C2 // Correct in debugger
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 // Wrong outside debugger
Ray.
In the fuction above the SCI0_Send_Packet((uint8_t *)&rtdata, sizeof(rtdata)); is sending 0x00 rather then the actual struct values. Why would it do this. I can only think that there is a big bug in the Debugger and should never be trusted.
Is this a stack problem ?
Ray.
I would not so easily blame the debugger! It is due to the use of the debugger, but it is not a bug in the debugger, it is a bug in your program! When you use the debugger, the EEPROM is also erased as default when you reprogram your processor, meaning that you will call the LoadStrucData()-function, and that is the only place where the rdata-struct is initialized! So when you start your application without the debugger, the EEPROM is already initialized, meaning that the rdata-struct is not initialized, defaults to zero and that is what you see!
Sten
Sten,
I had just found this myself and was about to let everyone know.
A bad tradesman always blames his tools.
Ray.
Hi Ray and StenS,
Thank you for sharing the root cause.
In fact I shortly looked at Ray’s code, but I miss that point.
General note:
When code works correctly with debugger and do not work in normal mode, typical root cause is inappropriate using of registers which could be written just once or if they cannot be written in normal mode. Typical case is multiple writes into CPMUCOP(COPCTL) register or write into TCNT register.
Special care has to be also taken for chip configuration registers like PKGCR or MODRRx. They also could be written just once therefore we should avoid to use bit manipulation commands like PKGCR_PKGCR0=0; and use only byte/word writes.
Have a great day,
RadekS
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------