S12G128 Project will not run correctly outside Debugger

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S12G128 Project will not run correctly outside Debugger

Jump to solution
808 Views
rayhall
Contributor V

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

Labels (1)
0 Kudos
1 Solution
578 Views
StenS
Contributor III

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

View solution in original post

0 Kudos
5 Replies
578 Views
rayhall
Contributor V

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.

0 Kudos
578 Views
rayhall
Contributor V

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.

0 Kudos
579 Views
StenS
Contributor III

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

0 Kudos
578 Views
rayhall
Contributor V

Sten,

I had just found this myself and was about to let everyone know.

A bad tradesman always blames his tools.

Ray.

0 Kudos
578 Views
RadekS
NXP Employee
NXP Employee

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!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos