problem with transfer parameter into subroutine

A lot of people make use of send and receive buffers, and limit the ISR to just pick up the next byte to send, or store the just received byte.

An RTOS task or a super-loop (mor likely choice for a C51) then scans the receive buffer for commands and/or answers to process, and fills the transmit buffer with commands and/or answers to send.

This makes the ISR lightning-quick. In some situations, it can be meaningful to let the ISR have a minimal state-machine, to have it look at start-of-message or end-of-message if the data is transmitted in packet form. But in general, it is advantageous to keep the ISR short. Then you don't have to think about interrupt response times and if there will be need for nested interrupts.

Another thing: you can compute the CRC a byte at a time, or wait until you have a full message. With a really fast processor, it may not matter, but at lower processor speeds a byte-at-a-time algorithm can speed up the response time by reducing the time from the reception of the last byte until you have fully decoded and accepted it and are ready to send back an answer.

From your example, I'm not really sure if your CRC is evaluated a byte at a time or a packet at a time.

The name seems to imply a full packet, but does the parameter then point out which - of many received and cached messages - message to compute the CRC for?

A lot of people make use of send and receive buffers, and limit the ISR to just pick up the next byte to send, or store the just received byte.

An RTOS task or a super-loop (mor likely choice for a C51) then scans the receive buffer for commands and/or answers to process, and fills the transmit buffer with commands and/or answers to send.

This makes the ISR lightning-quick. In some situations, it can be meaningful to let the ISR have a minimal state-machine, to have it look at start-of-message or end-of-message if the data is transmitted in packet form. But in general, it is advantageous to keep the ISR short. Then you don't have to think about interrupt response times and if there will be need for nested interrupts.

Another thing: you can compute the CRC a byte at a time, or wait until you have a full message. With a really fast processor, it may not matter, but at lower processor speeds a byte-at-a-time algorithm can speed up the response time by reducing the time from the reception of the last byte until you have fully decoded and accepted it and are ready to send back an answer.

From your example, I'm not really sure if your CRC is evaluated a byte at a time or a packet at a time.

The name seems to imply a full packet, but does the parameter then point out which - of many received and cached messages - message to compute the CRC for?

I use send/receive buffer for serial command handler, but like I said it is different for SPI case. When master processor query data through SPI, my C51 need to have the data ready. If I use send/receive buffer for SPI, that just means I have to put more delay to query each byte of data, which is not desired for my application.

I do use mini state machine for this SPI ISR routine right now. It is kind complicated error checking/hand shaking processing, but I am still not comfortable with the long term reliability.

Your idea on CRC calculated by byte is an excellent one. I will change to that, and maybe if I break my CRC routine into this big ISR instead of calling it as a subroutine at the end can eliminate my problem.
thanks,

Just to close the issue. The problem is caused by the size of my data. The data memory of this chip is 2k. My original way of designing SPI command structure is to include everything into one structure. And the command array is fairly big, so my data is bigger than 2k. The compiler did not complain, but I think they just overwrite each other during my debug session.

I solved the problem by separating command structure into several structures, some of them can be set as constant and reside in code space.

Thank you all for the help.