Perry:
I looked all through your code and it looks to me like your problem may be a usage contention between global data variables that are accessed from both the interrupt context and from the mainline context. The obvious candidates I see for contention are:

bc_bit_count
bc_char
bc_char_temp
reset_ch

If I were to work to solve this problem here would be my approach. I would move all the code that interprets the results of shifted in bits into the interrupt routine and keep all of the control and state variables localized for access only in the interrupt context. I would then take the resulting "ASCII" characters and place them into a standard circular queue that has separate input and output indexes. With byte sized indexes a circular queue mechanism is a reliable means to bridge the gap between the interrupt context and the mainline code context.

It should be possible to fully drive the interrupt routine as a state machine off the transitions detected from the PS2 interface. To handle the time delay for your retry logic pulse of the interface I would leverage a short section of a timer interrupt to release the held clock instead of putting the delay in the PS2 interrupt routine. And then instead of throwing away that extra interrupt transition consider letting it be the trigger to get you back into the PS2 handler after the end of the pulse time. With a carefully thought out state machine design reentry to the interrupt routine should easily realize that the entry was due to the timer working the CLK.

It is my estimation that the amount of work to be done at almost all entries to the PS2 interrupt routine is rather small and should represent a low percentage of total CPU bandwidth. Even the state of realizing that the full scan code has been received then translating that to the "ASCII" character should be a relatively short time execution duration. What this means is that although the proposed interrupt service routine may look like it has a lot of code in it you should find that there is not a huge bandwidth hit. So that should easily meet your requirement to be doing other things in your code such as operating a keypad, UARTs, bit bang I²C and so forth.

Michael Karas