Pause key gives wrong code. setLock(.) doesn't work in setup()

[pensigma]

I'm using V1.0.9 and when I press the Pause key it gives me 6 (PS2_KEY_L_SHIFT) instead of 5 (PS2_KEY_PAUSE).
In PS2KeyAdvanced.cpp line 674 I see
return PS2_KEY_PAUSE + _FUNCTION;

Is there a reason for the + _FUNCTION that results in 5 + 1 = 6?

Also, if I put in setup() the following:

keyboard.begin( . );
keyboard.setLock(PS2_LOCK_NUM);

When the Arduino is initially powered up, the Num Lock doesn't turn on until I press a key on the keyboard.
I also tried setLock(PS2_LOCK_NUM) and resetKey() inside loop() but they don't work either until a key has been pressed on the keyboard.
resetKey() can also cause a hang unless a key has been pressed beforehand.
I can replicate the issue by turning the Arduino off then on.

[techpaul]

First of all WHICH "Arduino" are you using as that is one of over 30 boards historically.

I'm using V1.0.9 and when I press the Pause key it gives me 6 (PS2_KEY_L_SHIFT) instead of 5 (PS2_KEY_PAUSE). In PS2KeyAdvanced.cpp line 674 I see return PS2_KEY_PAUSE + _FUNCTION;

Is there a reason for the + _FUNCTION that results in 5 + 1 = 6?

That is a mistake should NOT be adding _FUNCTION

Noted for next relaase

Also, if I put in setup() the following:

keyboard.begin( . );
keyboard.setLock(PS2_LOCK_NUM);

When the Arduino is initially powered up, the Num Lock doesn't turn on until I press a key on the keyboard. I also tried setLock(PS2_LOCK_NUM) and resetKey() inside loop() but they don't work either until a key has been pressed on the keyboard. resetKey() can also cause a hang unless a key has been pressed beforehand. I can replicate the issue by turning the Arduino off then on.

WHY are you trying to drive the keyboard SO quickly it takes over 500 ms for the device to power up then send the PS2_KEY_BAT response to say it has powered up correctly (BAT = Basic Assurance Test). So you are trying to send things when the keyboard is not ready EVEN if in loop(). You need to wait to see is keyAvailable and it is an 0xAA (PS"_KEY_BAT) if powered up at same time as Arduino. Note the data iis sent at a clock speed of 10 to 17 kHZ VERY slow serial comms.

Try a delay( 800 ) before sending anything.

No doubt it gets itself rsorted when a key is pressed.

Extract from document PS"Keyboard.pdf installed in /Arduino/Libraries/extra

~~
Reset:
At power-on or software reset (see the "Reset" command) the keyboard performs a diagnostic self-test referred to as BAT (Basic Assurance Test) and loads the following default values:

• Typematic delay 500 ms.
• Typematic rate 10.9 cps.
• Scan code set 2.
• Set all keys typematic/make/break.

When entering BAT, the keyboard enables its three LED indicators, and turns them off when BAT has completed. At this time, a BAT completion code of either 0xAA (BAT successful) or 0xFC (Error) is sent to the host. This BAT completion code must be sent 500~750 milliseconds after power-on.
Many of the keyboards I've tested ignore their CLOCK and DATA lines until after the BAT completion code has been sent. Therefore, an "Inhibit" condition (CLOCK line low) may not prevent the keyboard from sending its BAT completion code.

[pensigma]

I'm currently trying this on an Arduino Nano.

I tried adding delays, although I'm not sure if I did it correctly, for example:

delay(2000);
keyboard.begin( . );
delay(2000);
keyboard.setLock(PS2_LOCK_NUM);

What did work is removing line 246 in PS2KeyAdvanced.cpp:
_ps2mode |= _PS2_BUSY; // set busy

Not sure if that's the best way to fix it though.

[techpaul]

The basic problem is the Nano and Nano Every have NOT been tested and operate DIFFERENTLY in handling interrupts to Uno, Due and other processors. Some processors like ESP32 have to have special conditions added as it works only as CHANGE interrupt not FALLING_EDGE, so gives two icalls to ISR. On the Nano there could be many things happening to do with interrupts or not at change of direction, or multiple edges or many other issues.

You only really need a delay AFTER the begin() to ensure interrupts are setup in readiness to receive data and not start transmitting whilst it should or is in **MIDDLE ** of receiving.

See example advcodetest for detecting initial keyboard responses that has worked on OTHER boards.

See following regarding other processors and issues

#23

https://github.com/techpaul/PS2KeyAdvanced/blob/master/README.md
Especially sections

• Platforms known to have been tested on
• IDE Configuration

https://github.com/techpaul/PS2KeyAdvanced/blob/master/extra/Porting.md

#21
#22

As you obviously have not configured for Compiler ALL warnings you have missed the warning message saying use at your own risk.

The documentation states what boards have been tested on, and the documentation gives you clues on handling for your particular quirks and suggesting ways to fix for any unsupported board.

[pensigma]

The board I'm using goes under ARDUINO_ARCH_AVR so there's no warning:

#if defined( ARDUINO_ARCH_AVR )
#define PS2_SUPPORTED           1
#define PS2_REQUIRES_PROGMEM    1
#define PS2_CLEAR_PENDING_IRQ   1
#endif

Out of 5 keyboards I tested, there is one keyboard that works without needing to delete line 246 in PS2KeyAdvanced.cpp.

Anyway, it works now with the two changes I mentioned, so I'll leave it at that.
Thanks for your replies.

[techpaul]

Your fix ONLY works SOME of the time and WILL create problems elsewhere at times when you try send a command when a code byte is being received. It only works at the moment for that particular code sequence and external events.

Doing what you are suggesting stops the internal TX/RX barrier.

The actual fix you need is line 451 changed from

          _ps2mode &= ~_TX_MODE;

TO

          _ps2mode &= ~(_TX_MODE + _PS2_BUSY);

[pensigma]

Great, thanks for that. Looks like it's fixed now

[techpaul]

The fixes will be in next release and add Nano as tested board

[pensigma]

Sorry I spoke too soon. I changed line 451 but I forgot to uncomment line 246.
When line 246 is added back, the issue remains.

To be clear, this issue happens when the board (and the keyboard) is first powered on.
Also, one keyboard (out of 5) I tested works without changing PS2KeyAdvanced.cpp (no change to line 246 or line 451).

[techpaul]

First thing to say line 246 must be there to delay transmissions whilst receiving. Line 451 ensures after each byte of transmission code can check if more to send (will set busy again) or allow receive.
This was the reason you had to wait for a keypress to send.

Please note if any differences between keyboards (even age/batch numbers)

As one out of 5 keyboards work without modification to code, we have some form of timing issue either in how commands are sent or in handlking power up sequence correctly.

List of tests (on one working and one not working keyboard)

1. Ensure your setup routine does

keyboard.begin( . );   // First item in setup()

.. do other stuff or 
delay(1000);            // to allow PS2_KEY_BAT  or other status to be received
keyboard.setLock(PS2_LOCK_NUM);

2. Does working keyboard work with unmodified and line 451 modified code?
3. Do examples SimpleTest and advCodeTest work as expected with more than one keyboard?
4. Examine line 507 and 509

// Essential for PS2 spec compliance
// set clock low for 60us
delayMicroseconds( 60 );

The delay maybe on edge for keyboards and/or CPU frequency. I have not seen a problem on 84 MHz and faster with this delay, one person on very old keyboard had an issue with this delay. Increase delay to at least 80 microseconds.

The library works fine with my fairly recent keyboards here.

When we have fix I can consider a new release.

[pensigma]

The keyboards are all different. The one that works (Microsoft Basic Keyboard 1.0A) is not the newest. I should say that it works around 90% of the time, as I've now encountered a few times when it didn't work. I've tried another keyboard of the same model and it also works, so at least it's consistent.
I've also tried two more newer keyboards (Dell SK-8110 and eMachines KB-0511) and they didn't work.

Ensure your setup routine does

It's set up like that for the test. However, PS2_KEY_BAT was never received from any keyboard, including the working one. If resetKey() is invoked after the board has booted up and running, then PS2_KEY_BAT is received.

Does working keyboard work with unmodified and line 451 modified code?

The working keyboard still works with line 451 modified.

Do examples SimpleTest and advCodeTest work as expected with more than one keyboard?

SimpleTest works fine with the keyboards.
advCodeTest also works because opening up the serial monitor resets the board (but not the keyboard).
If I use advCodeTest and modify line 162 from
delay( 6 );
to

delay(1000);
keyboard.setLock(PS2_LOCK_NUM);

then turn OFF then ON the board (and the keyboard as it's powered by the board), the Num Lock doesn't light up. If I then open the serial monitor, it resets the board and the Num Lock lights up.

Examine line 507 and 509

Changing the delay to 80us or higher doesn't make a difference. It's actually never executed due to the if statement on line 555:

if( _ps2mode & _PS2_BUSY )
  return -134;

The _PS2_BUSY flag has been set by line 246, stuck on receive.

Perhaps an easy fix is to prioritise TX, and to cancel any RX by pulling CLOCK low as already done on line 510.

[techpaul]

Having spent three days in bed with a flu like illness I have comeback and reviewed the code and issues more thoroughly.

In PS2KeyAdvanced.cpp line 674, should have set a code code with PS2_FUNCTION to signify NON-printing keycode -

return PS2_KEY_PAUSE + PS2_FUNCTION;

Line 451 modification is an extra safety mechanism and should stay.

The fact that some keyboards "work" 90% of the time suggests other problems, saying the problem is becasue it is locked in RX mode is looking at the result not the root cause.. Giving priority and override to TX is not the way to handle Half Duplex communications, which are always done as Listen Before Talk to ensure line is idle to avoiding two ends driving at same time and causing hardware failures and/or synchronisation issues or lost data.

When using advCodeTest, many SENDING functions are tested so if you perform on your PS2 keybaord typing a key the library receives the code and actions it sending data to the keyboard and receiving responses. So doing the following will get responses

    R = Reset       Send reset command to keyboard and get responses
Should respond with AA

    E = Echo        Send protocol ECHO command (0xEE) and get same back
Should respond with  EE

    I = ReadID      Read the keyboard ID code ( should 2 bytes 0xAb 0x83)
    S = Scancode    Get current Scancode set in use on keyboard should be 2
Should respond 02

    T = Typematic rate Set to slowest Rate and delay
    G = Current Lock Get the current lock status (num, scroll, caps)
Depends on what lock keys have been pressed

    B = Break codes Toggle if receiving break codes is on or off
    N = No repeat   Ignore repeats of make codes for Shift, Ctrl, ALT, ALT-GR, GUI

You may see FA (PS2_KEY_ACK) to some commands as acknowledge of command sent.

Note pressing NUM, CAPS or SCROLL Lock keys causes the library to handle the setting of LEDs and codes for the keys

ALL functions listed in advCodeTest (including lock keys) should be tested using good and bad keyboard.

The fact that PS2_BUSY is set is an aspect of having got glitches in most probably the CLOCK line and started an RX (default state), when the next REAL interrupt comes along due to a real key press then the glitch removal timeout occurs clearing the bitcounts and resynchronising the communications status.

Most likely the problem is HARDWARE related, creating extra glitches and interupts to confuse the library, some hardware tests -

1. Check for ANY form of loose connection between Nano and PS2 socket and the socket itself, for ALL wires.
2. Check each keyboard (unplugged from Nano) with a multimeter that the Clock and Data Pin have at least 1k ohms to 10k ohms between signal line and the +5V pin. There may be different values depending on polarity of meter leads but both ways should be more than 1k
3. Check length of wiring and where it runs as this could also be interference and pickup in the signals, some of this may be pickup form noise on power rails.

I am looking at code for any better traps for glitches to be made, one possible is in test.

[pensigma]

In PS2KeyAdvanced.cpp line 674, should have set a code code with PS2_FUNCTION to signify NON-printing keycode

Got it thanks.

Giving priority and override to TX is not the way to handle Half Duplex communications, which are always done as Listen Before Talk to ensure line is idle to avoiding two ends driving at same time and causing hardware failures and/or synchronisation issues or lost data.

Ok I don't know much about the PS2 protocol, and was hoping I won't need to. But reading the included "PS2 Keyboard.pdf" regarding keyboard to host communication states "The host may inhibit communication at any time by pulling the Clock line low for at least 100 microseconds."

Also I noticed _PS2_BUSY is checked in send_next() then proceeds to send_now(). Between send_next() and send_now() _PS2_BUSY may have been set by ps2interrupt(). The same issues with variables like _bitcount set in send_now() before detachInterrupt().

ALL functions listed in advCodeTest (including lock keys) should be tested using good and bad keyboard.

All the functions listed for advCodeTest work with both good and bad keyboards.

The fact that PS2_BUSY is set is an aspect of having got glitches in most probably the CLOCK line and started an RX (default state)

Yes, it's due to the interrupt being triggered in all but the two Microsoft keyboards. So using something similar to the PS2_CLEAR_PENDING_IRQ trick will result in the other keyboards working, but the Microsoft keyboard not working (when the board is first powered up).
However, if the board is reset, the interrupt is not triggered (with any keyboard).

The older keyboards have between 1k and 10k ohms between the various pins mentioned. The newer ones are out of range (greater than 2M ohms), including the Microsoft keyboard.

[pensigma]

Upon further investigation, it seems the Microsoft keyboard worked because it was sending more data than just 0xAA when it was first powered up. It was sending Scroll Lock ON, Scroll Lock OFF (what was caught anyway), which to PS2KeyAdvanced is like a key being pressed:

Value 102 - Status Bits 1  Code 2
Value FA - Status Bits 0  Code FA
Value FA - Status Bits 0  Code FA
Value 8102 - Status Bits 81  Code 2
Value FA - Status Bits 0  Code FA
Value FA - Status Bits 0  Code FA