mesa 7i73 4x8 keypad problems on KEY8 input

I believe that (data at the end) is the configuration data.
(which is necessary as it does things like setup the clock source)

Can the PICKit3 be told that the configuration data is included in the hex file?

If not, maybe that can be setup by hand, as it's only a couple of options.

Hi, "the friend" here. First of all, thanks Peter, for your support. I've no experience in flashing PICs so far so I'm not sure what the problem is. When I open the hex files in the MPLAB IDE (v8.92) the first 0xffff bytes are 0xff and then the contents of the hexfile starts at offset 0x1000.
When opening the hexfile in a text editor I can at least verify that it does not start at offset 0 but at an offset 0x2000. The first line, for example, reads

:182000004440A8003420EF0060042000E0ECB70020022000E1ECB7008C

From left to right 0x18=24 bytes, offset 0x2000, record type 0x00 = data, then 24 data bytes and one byte checksum.

I'm not sure where the difference between 0x1000 and 0x2000 comes from. But when I read the firmware back with the programmer and save it as a hex file it starts at 0x0000.

:020000040000FA
:10000000D9043700B40900003C0C0000500C00007B

So I assume that maybe in the first 0xfff bytes is something like a bootloader or similar.
The only way I could get the firmware to run was using the lines up to offset 0x2000 from the original firmware read from the board before flashing and combining them with the lines from the file you sent. So when I read the firmware back I get the file I attached (the one named ...readback.hex). The firmware flashed that way runs, is recognized as firmware 16 by LinuxCNC and e.g. the analog inputs work fine, only the matrix_kb doesn't work at all. In the previous firmware 14 only the buttons in column 0 did not work (most probably as they are sampled first).

Regarding the configuration section, I believe it is handled correctly by MPLAB, at least it is read the same way. However it differs in one byte

7I73S16H1.HEX
:0200000401F009
:100000000F000000FF000000070000008300000058
:10001000C50000004000000007000000C300000011
:00000001FF

read back with MPLAB
:0200000401F009
:100000000F00000000000000070000008300000057
:10001000C50000004000000007000000C300000011
:00000001FF

I also noticed that the firmware flashed via upload-eth (named ...before-flashing.hex in the attached zip file) differs in several places from the firmware flashed with the programmer, although, both are version 16, I'm not sure if this is intentional.

I'll try flashing the firmware 14 again tomorrow at check if the matrix_kb buttons, apart from column 0 are working again.

Not sure what's going on, but if I read the memory image
with my programmer, all images (R14,R15,R16) start at 0

Yes, I think PICKit3 can do this. Reflashing the original V14 worked, so it already flashed those options there.
I'm optimistic that simply removing the first EOF will do the trick!
Maybe you should check why your software does generate wrong hex file format because his definitely is not according to official intel hex specification.
Some Tools might ignore the additional EOF and some don't.

Today I managed to modify the hex file as proposed above by removing the EOF lines are sorting the sections. This way I succeeded flashing and all buttons of the matrix keyboard are now finally working. Thanks Peter for the firmware.
I really wonder why all the tools, I also tried more modern versions of the MPLAB X IDE, are not able to properly read the original hex format.

Great news!

I also tried more modern versions of the MPLAB X IDE, are not able to properly read the original hex format.

Well actually those editors are reading it correctly. Data after the End-Of-File should not exist. A good Editor should just say sth. like "can't open file - wrong entry" or "do you want to ignore the error?"....
The Editor/Programmer PCW is reading does not read it correctly as it ignores the EOF Entry without saying so.
Wikipedia says:

 :00000001FF   End Of File: Must occur exactly once per file in the last record of the file.

But well - the initial problem is solved and I don't think I will put effort in fixing Microchip's tools or Toolchains.
@PCW: Please keep the EOF bug in mind whenever you send hex files made by the same toolchain.
Thank you for the fixed firmware!

Normally we would not use hex files at all because the standard way to update
would be over serial. I will look into why the serial update fails.