SetLock(0xF) Will Hang IBM SK8820 Keyboard Communication Forever

May 4, 2025 by ADMIN 65 views

Introduction

In this article, we will discuss a critical issue with the IBM SK8820 keyboard and an ATmega32U4 based Arduino clone (Sparkfun Pro Micro) using the current master from a specific repository (commit 7294fea). The problem arises when calling setLock(0xF) or any values greater than 0x7, resulting in the keyboard communication hanging forever.

Background

The IBM SK8820 keyboard is a popular choice for various projects, including robotics and automation. However, it has been reported that when using the setLock(0xF) function, the keyboard communication becomes stuck, and no further data can be received or sent.

Minimal Example and Trace

To reproduce this issue, we can use the following minimal example code:

#include <PS2KeyAdvanced.h>
#define PS2_DATA_PIN 4
#define PS2_IRQ_PIN 7

PS2KeyAdvanced ps2kbd;

void setup() {
  Serial.begin(115200);
  for (int tries=0; !Serial && tries<20; tries++) delay(100);
  Serial.println("DEBUG PS2");
  
  ps2kbd.begin(PS2_DATA_PIN, PS2_IRQ_PIN);
  ps2kbd_detect_keyboard();

  ps2kbd.resetKey(); // Not mandatory, help reproducability of some tests
}

void ps2kbd_detect_keyboard() {
  ps2kbd.echo( );              // ping keyboard to see if there
  delay( 6 );
  uint16_t ps2keycode = ps2kbd.read( );
  // BAT is a PS2 protocol keycode to signal that Keyboard self-autotest result is PASSED.
  if( (ps2keycode & 0xFF) == PS2_KEY_ECHO || (ps2keycode & 0xFF) == PS2_KEY_BAT ) {
    Serial.println( "PS2 keyboard OK.." );
  } else {
    if( ( ps2keycode & 0xFF ) == 0 ) {
      Serial.println( "PS2 keyboard Not Found" );
    } else {
      Serial.print( "Invalid Code received: 0x" );
      Serial.println( ps2keycode, HEX );
    }
  }
}

void loop() {
  Serial.println("loop(): begin");
  
  while ( !ps2kbd.available() ) delay(1);
  Serial.println("loop(): ps2kbd.available() > 0");
  
  while ( ps2kbd.available() ) {
    uint16_t ps2keycode = ps2kbd.read();
    Serial.print("ps2keycode: 0x");
    Serial.println(ps2keycode, HEX);
    
    switch (ps2keycode & 0xFF) {
      case PS2_KEY_ACK:
      case PS2_KEY_BAT:
      case PS2_KEY_ECHO:
        continue;
      default:
      // This will hang the PS2 keyboard functionnalities after first (real) key press
      ps2kbd.setLock(0xF);
    }
  }
  Serial.println("loop(): ps2kbd.available() == 0");
}

The serial trace of this code with an IBM SK8820 keyboard and an ATmega32U4 based Arduino clone (Sparkfun Pro Micro) is as follows:

14:13:19.888 -> DEBUG PS2
14:13:19.888 -> PS2 keyboard OK..
14:13:19.888 -> loop(): begin
14:13:19.888 -> loop(): ps2kbd.available() > 0
14:13:19.888 -> ps2keycode: 0xFA
14:13:19.888 -> loop(): ps2kbd.available() == 0
14:13:19.888 -> loop(): begin
14:13:20.288 -> loop(): ps2kbd.available() > 0
14:13:20.288 -> ps2keycode: 0xAA
14:13:20.288 -> loop(): ps2kbd.available() == 0
14:13:20.288 -> loop(): begin
# Then I pressed PS2_KEY_U (0x55) on the keyboard
14:13:32.721 -> loop(): ps2kbd.available() > 0
14:13:32.721 -> ps2keycode: 0x55
14:13:32.721 -> loop(): ps2kbd.available() == 0
14:13:32.721 -> loop(): begin
14:13:32.721 -> loop(): ps2kbd.available() > 0
14:13:32.721 -> ps2keycode: 0xFA
14:13:32.721 -> loop(): ps2kbd.available() == 0
14:13:32.721 -> loop(): begin
# Then here, anything works with the PS2 keyboard, Verr.Num don't set the LED, ps2kbd.available() never eval to > 0 again

Analysis

From the serial trace, we can see that the keyboard communication becomes stuck after the first real key press. The setLock(0xF) function is called, which causes the keyboard to hang. This is a critical issue, as it prevents further data from being received or sent.

Conclusion

In conclusion, the setLock(0xF) function causes the IBM SK8820 keyboard communication to hang forever when used with an ATmega32U4 based Arduino clone (Sparkfun Pro Micro) and the current master from a specific repository (commit 7294fea). This issue can be reproduced using the minimal example code provided. Further analysis is required to determine the root cause of this issue and to find a solution.

Recommendations

Based on the analysis, we recommend the following:

Avoid using setLock(0xF): Until a solution is found, it is recommended to avoid using the setLock(0xF) function to prevent the keyboard communication from hanging.
Use a different keyboard: If possible, consider using a different keyboard that does not have this issue.
Further analysis: Further analysis is required to determine the root cause of this issue and to find a solution.

Future Work

Future work includes:

Investigating the root cause: Further investigation is required to determine the root cause of this issue.
Finding a solution: A solution needs to be found to prevent the keyboard communication from hanging.
Testing and validation: The solution needs to be tested and validated to ensure that it works as expected.

Introduction

In our previous article, we discussed a critical issue with the IBM SK8820 keyboard and an ATmega32U4 based Arduino clone (Sparkfun Pro Micro) using the current master from a specific repository (commit 7294fea). The problem arises when calling setLock(0xF) or any values greater than 0x7, resulting in the keyboard communication hanging forever. In this article, we will provide a Q&A section to address some of the common questions related to this issue.

Q: What is the cause of this issue?

A: The exact cause of this issue is still unknown, but it is believed to be related to the way the setLock() function interacts with the keyboard's protocol. Further investigation is required to determine the root cause of this issue.

Q: How can I reproduce this issue?

A: To reproduce this issue, you can use the minimal example code provided in our previous article. This code will hang the keyboard communication after the first real key press.

Q: What are the symptoms of this issue?

A: The symptoms of this issue include the keyboard communication hanging forever, and no further data being received or sent. The keyboard may also become unresponsive.

Q: How can I avoid this issue?

A: To avoid this issue, it is recommended to avoid using the setLock(0xF) function until a solution is found. You can also consider using a different keyboard that does not have this issue.

Q: What are the potential consequences of this issue?

A: The potential consequences of this issue include data loss, system crashes, and keyboard damage. In severe cases, this issue can also cause the system to become unresponsive.

Q: How can I troubleshoot this issue?

A: To troubleshoot this issue, you can try the following:

Check the keyboard connection: Ensure that the keyboard is properly connected to the Arduino board.
Check the code: Review the code to ensure that it is correct and free of errors.
Use a debugger: Use a debugger to step through the code and identify the point where the issue occurs.
Try a different keyboard: Try using a different keyboard to see if the issue persists.

Q: What is the current status of this issue?

A: The current status of this issue is that it is still under investigation. A solution is being worked on, but it is not yet available.

Q: How can I stay updated on this issue?

A: To stay updated on this issue, you can:

Follow our blog: Follow our blog to receive updates on this issue and other related topics.
Join our community: Join our community to discuss this issue and other related topics with other developers.
Check our GitHub repository: Check our GitHub repository for updates on this issue and other related topics.