Our embedded SW generates serial pole reports. Most of them are a response to a PC access to the device (the PC talks to the device, who listen to the incoming message, which requests an information that is written to the serial pole byte and then read by the PC).
This works perfectly.
However, the device also generates asynchronous reports through the serial pole, reporting unexpected events in the device (for example: error situation).
This serial pole message is not a response to a PC request, but rather a pop-up report.
The PC software is written in a way that it can handle both answers to its requests and pop-up messages, all in the serial pole.
However, and here is our problem, when the pop-up messages are enabled, sometime a serial pole data that we are writing into the TNT4882 is not read by the PC.
(for a example, a given pop-up message is lost, or a given answer to a PC request is lost).
We have carefully checked our embedded code and it is 100% (or as close it can be to it) that we do write the lost byte into the serial pole register. This means, it is not a problem of managing the messages in the embedded device. It is also not a problem in the PC side.
It seems to us that due to a wrong code to the TNT4882 (details below), we are wrongly writing twice to the TNT4882 serial pole register, thus overwriting a previous written byte, before the PC has the time to read it.
We have of course wrote the code in a way that this should not happen (meaning, we are monitoring flags to verify that the serial pole byte is empty, before writing a new byte to it), but maybe we have done mistakes here.
We have checked our logic, by writing a byte to the serial pole (by the embedded device) and avoiding reading it by the PC. Indeed, our flags logic prevented us from writing the second byte in, as we expected. But this was a static test. We are afraid that maybe when all the process is running at high speed, sometimes the is a timing problem, and we are wrongly overwriting the serial pole data before it was read.
Here is our relevant code segments:
if ((TNT_In(R_spsr)&B_pend) == 0)
{
ucVal = (unsigned char) GetCurrSPByte () ;
if(ucVal != 144)
{
// set the serial poll value, and set attention
TNT_Out(R_imr0,B_glint) ;//|B_stbo) ;
TNT_Out(R_auxmr,F_reqt) ;
TNT_Out(R_spmr, ucVal) ;
}
else
{
// clear the serial poll value, and clear attention
TNT_Out(R_imr0,B_glint) ; //|B_stbo) ;
TNT_Out(R_auxmr,F_reqf) ;
}
}
All the above is of course exceuted in endless cycle cy the embedded SW.
ucVal is the byte we need to report, while GetCurrSPByte() routine is a manager of our buffer of reports to send. It works properly and as I said, we have debugged that the lost ucVal is written to the serial pole.
We are afraid that the mail if() may fail, assuming that the PC is monitoring the serial pole continuously.
Is it possible that we will enter the above if(), write a byte to the serial pole, and in the next (or other) cycle will enter it again, writing the next byte to report, before the PC has complete the process of reading the first byte (so it will be lost)?
