Well, thanks for the info, I'll see what I can do and post any progress here...
EDIT: the thing is getting weird... Installed cwiid and wmgui in Ubuntu 12.10 and managed to connect the regular wiimote and use all features (IR, accelerometer, buttons, EEROM, etc), except extensions. All user-portion from the EEPROM (around 4kb) that can be read while connected through bluetooth can be accessed and from the dump I got, all data that should be there is there and isn't corrupt (two sets of calibration data, working Mii data, etc). Using wmgui with the Wii Remote Plus worked too, and all features were acessible normally, the only weird thing is that a lot of "Invalid packet type" popped in the console while using wmgui with the Wii Remote Plus. So, I think it isn't necessary to use an EEPROM programmer to read the entire 16 kb of data, since that data isn't corrupt (as I wondered in the beggining). Does anyone know if there is something in the EEPROM that controls the packet format that the wiimote will use to communicate and that may have changed?
EDIT 2: the regular Wiimote now tries to recconect the last used device when pressing any button while it's disconnected, like how it worked before these problems...
EDIT 3: after many hours messing with some Linux tools, the regular Wiimote is working fine now. Can't say what I did exactly, but seems that after backing up the EEPROM area that can be accessed through bluetooth in wmgui, zeroing the entire area and restoring only the calibration data (and the misterious sequence of bytes present in the very end) did the trick. Tried the same thing with the Wii Remote Plus, but didn't work: in apps that seems to ignore the packet type (like wmgui and TransferMii -- they just throw an warning in the console) everything works. In Dolphin and GlovePIE it get connected, but after that nothing happens because it's sending the wrong packet type (I assume), and Dolphin/GlovePIE seems to ignore these packets...
EDIT 4: FINALLY got the Wii Remote Plus working again. tueidj was right, something wiped a few bytes of the EEPROM. Accordingly to WiiBrew, EEPROM address range 0x0000 to 0x1700 can be freely read/written by BT device that can communicate with the remotes. On a virgin Wiimote, in the beginning of that area we will have calibration values (unique to each Wiimote) and the rest will be entirely blank, except by a small sequence of bytes at the very end (starts in 16D3). Comparing the EEPROM dump of my regular Wiimote, the sample available at WiiBrew and the full dump done by Sparkfun, this area is always the same in different Wiimotes, and only 3 bytes have unique values:
Despite of the "Invalid packet type" warnings, wmgui still allowed me to freely read/write in the EEPROM of the problematic Wii Remote Plus. The EEPROM of that Wiimote had all data present in a virgin Wiimote (including its unique calibration values) plus some Mii data I saved to them. However, in the sequence of bytes present in the very end, I noticed that 4 bytes were missing (the ones marked with YY), instead of the common values, they were zeroed:
Since in that sequence of bytes only the XX's are unique to each device, I replaced the zeroed bytes (YY's) with the common data found in the other wiimotes and left the XX's intact. After writing them to the Wii Remote Plus, I disconnected it from the computer, pulled the batteries, put them back and reconnected. This time I didn't get any "Invalid packet type" warnings (YAY!) and now it's working fine in all apps I tested (including Dolphin and GlovePIE, like before this weird issue)
I really don't have any idea of what caused this wipe, but it isn't too hard to fix at all if this happens to someone else. This info may be useful for some dev too, after all, even in WiiBrew and some other sites the only info I got about this portion of the EEPROM is that it contains "unknown data"...
EDIT: the thing is getting weird... Installed cwiid and wmgui in Ubuntu 12.10 and managed to connect the regular wiimote and use all features (IR, accelerometer, buttons, EEROM, etc), except extensions. All user-portion from the EEPROM (around 4kb) that can be read while connected through bluetooth can be accessed and from the dump I got, all data that should be there is there and isn't corrupt (two sets of calibration data, working Mii data, etc). Using wmgui with the Wii Remote Plus worked too, and all features were acessible normally, the only weird thing is that a lot of "Invalid packet type" popped in the console while using wmgui with the Wii Remote Plus. So, I think it isn't necessary to use an EEPROM programmer to read the entire 16 kb of data, since that data isn't corrupt (as I wondered in the beggining). Does anyone know if there is something in the EEPROM that controls the packet format that the wiimote will use to communicate and that may have changed?
EDIT 2: the regular Wiimote now tries to recconect the last used device when pressing any button while it's disconnected, like how it worked before these problems...
EDIT 3: after many hours messing with some Linux tools, the regular Wiimote is working fine now. Can't say what I did exactly, but seems that after backing up the EEPROM area that can be accessed through bluetooth in wmgui, zeroing the entire area and restoring only the calibration data (and the misterious sequence of bytes present in the very end) did the trick. Tried the same thing with the Wii Remote Plus, but didn't work: in apps that seems to ignore the packet type (like wmgui and TransferMii -- they just throw an warning in the console) everything works. In Dolphin and GlovePIE it get connected, but after that nothing happens because it's sending the wrong packet type (I assume), and Dolphin/GlovePIE seems to ignore these packets...
EDIT 4: FINALLY got the Wii Remote Plus working again. tueidj was right, something wiped a few bytes of the EEPROM. Accordingly to WiiBrew, EEPROM address range 0x0000 to 0x1700 can be freely read/written by BT device that can communicate with the remotes. On a virgin Wiimote, in the beginning of that area we will have calibration values (unique to each Wiimote) and the rest will be entirely blank, except by a small sequence of bytes at the very end (starts in 16D3). Comparing the EEPROM dump of my regular Wiimote, the sample available at WiiBrew and the full dump done by Sparkfun, this area is always the same in different Wiimotes, and only 3 bytes have unique values:
Code:
16D0: 00 00 00 FF 11 EE 00 00 33 CC 44 BB 00 00 66 99
16E0: 77 88 00 00 xx 01 xx xx 00 00 00 00 00 00 00 00Despite of the "Invalid packet type" warnings, wmgui still allowed me to freely read/write in the EEPROM of the problematic Wii Remote Plus. The EEPROM of that Wiimote had all data present in a virgin Wiimote (including its unique calibration values) plus some Mii data I saved to them. However, in the sequence of bytes present in the very end, I noticed that 4 bytes were missing (the ones marked with YY), instead of the common values, they were zeroed:
Code:
16D0: 00 00 00 FF 11 EE 00 00 33 CC 44 BB 00 00 yy yy
16E0: yy yy 00 00 xx 01 xx xx 00 00 00 00 00 00 00 00Since in that sequence of bytes only the XX's are unique to each device, I replaced the zeroed bytes (YY's) with the common data found in the other wiimotes and left the XX's intact. After writing them to the Wii Remote Plus, I disconnected it from the computer, pulled the batteries, put them back and reconnected. This time I didn't get any "Invalid packet type" warnings (YAY!) and now it's working fine in all apps I tested (including Dolphin and GlovePIE, like before this weird issue)

I really don't have any idea of what caused this wipe, but it isn't too hard to fix at all if this happens to someone else. This info may be useful for some dev too, after all, even in WiiBrew and some other sites the only info I got about this portion of the EEPROM is that it contains "unknown data"...
Avell A70 MOB: Core i7-11800H, GeForce RTX 3060, 16 GB DDR4-3200, Windows 11 (Insider Preview)
ASRock Z97M OC Formula: Pentium G3258, GeForce GT 440, 16 GB DDR3-1600, Windows 10 (22H2)
ASRock Z97M OC Formula: Pentium G3258, GeForce GT 440, 16 GB DDR3-1600, Windows 10 (22H2)
