In looking at https://service.z-wave.me/expertui/uzb- ... tml?hw=277, the bootloader filename is: UPD_bootloader_UZB500_from__05_17_to_9D04.bin (which you already knew).
Just checking...
I assume you've stopped the Z-Way firmware when you are trying to run the ZMESerialUpdater command:
ZMESerialUpdater serialapi_uzbupdate -b UPD_bootloader_UZB500_from__05_17_to_9D04.bin -d /dev/ttyACM0
Are you sure the bootloader upgrade failed? What is the output from: ZMESerialUpdater serialapi_uzbupdate -d /dev/ttyACM0
According to the version graph, once the UZB bootloader is at version 40196, you can upgrade to firmware version 5.26 (and that's the most recent you can go):
ZMESerialUpdater serialapi_uzbupdate -f UPD_FIRMWARE_UZB500_from__05_17__to__05_1a.bin -d /dev/ttyACM0
If the bootloader and firmware upgrades are not successful, then someone from the Z-Wave.Me team will need to step in to help you.
UZB Firmware Update from 5.07 to 5.27 fails
-
- Posts: 193
- Joined: 02 Mar 2020 22:41
Re: UZB Firmware Update from 5.07 to 5.27 fails
Hi , thank you for your answer:seattleneil wrote: ↑03 Jun 2022 18:32In looking at https://service.z-wave.me/expertui/uzb- ... tml?hw=277, the bootloader filename is: UPD_bootloader_UZB500_from__05_17_to_9D04.bin (which you already knew).
Just checking...
I assume you've stopped the Z-Way firmware when you are trying to run the ZMESerialUpdater command:
ZMESerialUpdater serialapi_uzbupdate -b UPD_bootloader_UZB500_from__05_17_to_9D04.bin -d /dev/ttyACM0
Are you sure the bootloader upgrade failed? What is the output from: ZMESerialUpdater serialapi_uzbupdate -d /dev/ttyACM0
According to the version graph, once the UZB bootloader is at version 40196, you can upgrade to firmware version 5.26 (and that's the most recent you can go):
ZMESerialUpdater serialapi_uzbupdate -f UPD_FIRMWARE_UZB500_from__05_17__to__05_1a.bin -d /dev/ttyACM0
If the bootloader and firmware upgrades are not successful, then someone from the Z-Wave.Me team will need to step in to help you.
for the -d output :
Device ready in:3.18809890747 seconds
FULL INFO
Openning port .............................. OK
SERIAL INFO
VERSION: 05 17 VENDOR: 01 15
ZME_CAPABILITIES
UID: 87 60 AD 99 95 9D A0 A7 0C CD 77 EF 44 86 63 15
VENDOR: 00 00 NODES: FF
FLAGS: 01 00 00 00 00 00 00 00 00 00 00 00 00
FIRMWARE CRC
BOOT: 72 78 FW: CD 4F
MISC
FREQ: EU
When i try to update the version:
./ZMESerialUpdater serialapi_uzbupdate -b UPD_bootloader_UZB500_from__05_17_to_9D04.bin -d /dev/ttyACM0
Z-WAVE Serial API Tool
Version:LWE0.9
by Z-WAVE>ME
-->
-->
-->
-->
Device ready in:5.55843901634 seconds
BOOTLODER
Openning port .............................. OK
Writing NVM data .............................. FAILED
Error 0 returned 1 for ACK
Error 1 Unknown exception:Can't write NVM data! at=4200
Thank you in advance
-
- Posts: 193
- Joined: 02 Mar 2020 22:41
Re: UZB Firmware Update from 5.07 to 5.27 fails
You've reached the limit of my understanding of the ZMESerialUpdater tool.
Does the log file (zme_updater.log) reveal why you're getting the error "Can't write NVM data! at=4200"? I run the ZMESerialUpdater as root. Could it be a permissions issue (I'm just guessing)?
If you're still stuck, the best I can do is suggest you send the relevant portions of the log file to @PoltoS and wait for him to respond. If it helps, here's the first 6 lines of what shows up in the log file when I run the following command on my Z-Wave.Me card (not the USB UZB): ./ZMESerialUpdater serialapi_uzbupdate -d /dev/ttyAMA0
Programmer starting on Linux.
ARGS:['./ZMESerialUpdater', 'serialapi_uzbupdate', '-d', '/dev/ttyAMA0'] VERSION:LWE0.9 MD5:--NA--
SILENT=True
>> {HEX, len = 5} 01 03 00 07 FB
<< ACK
<< {HEX, len = 45}
Good luck.
Does the log file (zme_updater.log) reveal why you're getting the error "Can't write NVM data! at=4200"? I run the ZMESerialUpdater as root. Could it be a permissions issue (I'm just guessing)?
If you're still stuck, the best I can do is suggest you send the relevant portions of the log file to @PoltoS and wait for him to respond. If it helps, here's the first 6 lines of what shows up in the log file when I run the following command on my Z-Wave.Me card (not the USB UZB): ./ZMESerialUpdater serialapi_uzbupdate -d /dev/ttyAMA0
Programmer starting on Linux.
ARGS:['./ZMESerialUpdater', 'serialapi_uzbupdate', '-d', '/dev/ttyAMA0'] VERSION:LWE0.9 MD5:--NA--
SILENT=True
>> {HEX, len = 5} 01 03 00 07 FB
<< ACK
<< {HEX, len = 45}
Good luck.
Re: UZB Firmware Update from 5.07 to 5.27 fails
seattleneil wrote: ↑05 Jun 2022 19:37You've reached the limit of my understanding of the ZMESerialUpdater tool.
Does the log file (zme_updater.log) reveal why you're getting the error "Can't write NVM data! at=4200"? I run the ZMESerialUpdater as root. Could it be a permissions issue (I'm just guessing)?
If you're still stuck, the best I can do is suggest you send the relevant portions of the log file to @PoltoS and wait for him to respond. If it helps, here's the first 6 lines of what shows up in the log file when I run the following command on my Z-Wave.Me card (not the USB UZB): ./ZMESerialUpdater serialapi_uzbupdate -d /dev/ttyAMA0
Programmer starting on Linux.
ARGS:['./ZMESerialUpdater', 'serialapi_uzbupdate', '-d', '/dev/ttyAMA0'] VERSION:LWE0.9 MD5:--NA--
SILENT=True
>> {HEX, len = 5} 01 03 00 07 FB
<< ACK
<< {HEX, len = 45}
Good luck.
Hi,
Please find enclosed the begin of the update "log" and the last six blocks:
Begin:
Programmer starting on Linux.
ARGS:['./ZMESerialUpdater', 'serialapi_uzbupdate', '-b', 'UPD_bootloader_UZB500_from__05_17_to_9D04.bin', '-d', '/dev/ttyACM0'] VERSION:LWE0.9 MD5:--NA--
SILENT=True
>> {HEX, len = 5} 01 03 00 07 FB
0 returned 18 for ACK
<< {HEX, len = 12} 01 0A 00 04 00 4E 02 98 40 C1 00 A4
>> ACK
>> {HEX, len = 5} 01 03 00 07 FB
0 returned 18 for ACK
<< {HEX, len = 12} 01 0A 00 04 00 4E 02 98 40 C1 00 A4
>> ACK
>> {HEX, len = 5} 01 03 00 07 FB
0 returned 18 for ACK
<< {HEX, len = 12} 01 0A 00 04 00 4E 02 98 40 BE 00 DB
>> ACK
>> {HEX, len = 5} 01 03 00 07 FB
<< ACK
<< {HEX, len = 45}
01 2B 01 07 05 17 01 15 04 00 00 01 FE 85 7F 88 CF 3F C0 47 FB DF FD E0 67 00 80 80 00 80 86 00
00 00 E8 73 00 80 0F 00 00 60 1A 00 1C
>> ACK
<< {HEX, len = 12} 01 0A 00 04 00 4E 02 98 40 BE 00 DB
>> ACK
SILENT=False
BOOTLODER
Status: Openning port
>> {HEX, len = 5} 01 03 00 07 FB
<< ACK
<< {HEX, len = 45}
01 2B 01 07 05 17 01 15 04 00 00 01 FE 85 7F 88 CF 3F C0 47 FB DF FD E0 67 00 80 80 00 80 86 00
00 00 E8 73 00 80 0F 00 00 60 1A 00 1C
>> ACK
Status: Writing NVM data Started
>> {HEX, len = 138}
01 88 00 2B 00 30 00 00 80 94 64 EC 66 51 F8 BD 14 13 4F 48 32 2D 3D C7 17 F2 D7 B5 E9 4B E8 8B
44 65 AE 72 BE BA 2E B0 19 FA BD 0F 76 E3 5E 03 FE 79 03 4E 5B 5F 8E 60 3A CA 35 65 95 CA D6 46
87 8E ED D6 42 73 BD 32 FB DE 04 C0 A3 6E 98 BA DF 5B CF A5 50 72 7C 8B B6 36 35 CF 00 0D FF 2E
E9 9F 7B 9A 75 27 1F B8 80 0D D1 50 5E 44 97 E8 DA 9E A8 96 53 7B 20 11 E8 EB 3C C7 AB D8 7F C7
94 DE 3E 16 99 03 AE 04 18 9E
<< ACK
Last blocks:
<< {HEX, len = 6} 01 04 01 2B 01 D0
>> ACK
>> {HEX, len = 138}
01 88 00 2B 00 38 00 00 80 65 92 CB 34 4C CA F1 26 C2 B0 B9 5F FD E6 AB CE 3B 51 FB C0 DA 40 4B
66 0C 57 10 57 E7 38 7E 03 5C 29 06 CE CD 75 E7 A9 54 51 F3 E5 79 D6 C3 91 3E B8 D4 C1 B1 7E 65
3D C1 E2 06 EF D5 0A 38 0E B4 25 C4 FD 08 3D 96 F7 CD 3A B8 E6 52 5B 5B E6 D5 0D 46 3B EB 44 A4
97 0E E9 D2 C4 2F 41 73 FA DC 00 D4 75 F2 CB C2 C2 ED E8 F1 07 B3 B8 4C EC 3E 2D B8 7F 6B BD 34
44 17 D7 AE 6E 0E C7 6B 06 89
<< ACK
<< {HEX, len = 6} 01 04 01 2B 01 D0
>> ACK
>> {HEX, len = 138}
01 88 00 2B 00 38 80 00 80 86 03 1E 8D 4B 38 AF 06 B4 31 56 28 88 86 15 B1 3E 21 2C 43 F6 BB D6
AD BC C0 B8 5F 1F 84 09 07 F5 10 17 5F 3E 37 65 BE DF 3D 36 74 4E 92 03 EB 15 CD A2 6D 1D 94 5F
28 FE FC BA 31 99 30 08 3D 24 3E 08 5D 93 0A 8D 21 DD F1 D0 DC DD 77 4B AB 6F 87 6B F3 75 09 42
FF D4 00 8D EF 33 90 DF 8F B4 7C 09 3F F0 0F 29 FE 8C 0B 35 A8 AD 9E 73 29 CF 6C 3A 91 DE A3 77
F4 83 C3 A5 99 FF 42 A2 D0 A2
<< ACK
<< {HEX, len = 6} 01 04 01 2B 01 D0
>> ACK
>> {HEX, len = 138}
01 88 00 2B 00 39 00 00 80 3A 10 75 DA FE 1A 59 1E 61 49 71 49 A7 12 8A 1F 8B 28 1E AD 1C D0 43
97 24 45 0B 09 65 00 CD A0 5D 22 C0 8C 86 20 B8 09 F4 E9 98 01 54 CA 65 09 7D 28 EC 5B 1B 56 99
CC 8B 86 18 D4 7F B5 D7 00 DE C4 40 AF 95 8F 90 35 57 59 A5 79 3D 9A 1A 37 C7 D7 CC AC 78 A9 E8
B7 79 73 04 1B 16 63 5F 15 7D 1E DD 5C 38 06 48 6F CE 52 64 DF F2 DE 2F 14 ED 06 EA AD 71 C2 2A
00 63 04 7D CB 80 DC 9B AA 60
0 returned 1 for ACK
1 Unknown exception:Can't write NVM data! at=4200
-
- Posts: 193
- Joined: 02 Mar 2020 22:41
Re: UZB Firmware Update from 5.07 to 5.27 fails
Well, it's not a permissions issue.
Out of curiosity, have you tried to update the firmware from the expert UI: http://[IP]:8083/expert/#/uzb? The expert UI method does not rely on the command line tool (and vice-versa). Perhaps the expert UI method will be successful.
The following document can be used to make sense of the ZMESerialUpdater log file: https://www.silabs.com/documents/public ... _8x_0x.pdf
Specifically, section 4.3.8.14 describes the error occurred after the tool issued a NVM buffer write command (0x2B) at offset 0x003900 for buffer size 0x0080. I'm puzzled why the error message was "Can't write NVM data! at=4200" instead of 3900. I'm guessing the chip tried to write the buffer and a timeout occurred after 1.5 seconds (see section 5.1 of https://www.silabs.com/documents/public ... -Guide.pdf). This could be a sign that the flash chip has a problem. If you don't want to wait for help from @PoltoS, you can try running the following command to dump the contents of the flash chip:
./ZMESerialUpdater serialapi_ripnvm -d /dev/ttyAMA0 > /tmp/UZB.dump
Ideally, the command/log file will tell you if there's a problem in reading offset 0x003900 (section 4.3.8.13 shows the command is 0x2A, so search for "2A 00 39 00 00 80" in the log file). If the dump command is successful, @PoltoS may offer advice on how to procced. If the dump command fails with the same type of error, chances are high the flash chip has a problem (this is another guess).
Unfortunately, this level of troubleshooting is beyond my understanding.
Out of curiosity, have you tried to update the firmware from the expert UI: http://[IP]:8083/expert/#/uzb? The expert UI method does not rely on the command line tool (and vice-versa). Perhaps the expert UI method will be successful.
The following document can be used to make sense of the ZMESerialUpdater log file: https://www.silabs.com/documents/public ... _8x_0x.pdf
Specifically, section 4.3.8.14 describes the error occurred after the tool issued a NVM buffer write command (0x2B) at offset 0x003900 for buffer size 0x0080. I'm puzzled why the error message was "Can't write NVM data! at=4200" instead of 3900. I'm guessing the chip tried to write the buffer and a timeout occurred after 1.5 seconds (see section 5.1 of https://www.silabs.com/documents/public ... -Guide.pdf). This could be a sign that the flash chip has a problem. If you don't want to wait for help from @PoltoS, you can try running the following command to dump the contents of the flash chip:
./ZMESerialUpdater serialapi_ripnvm -d /dev/ttyAMA0 > /tmp/UZB.dump
Ideally, the command/log file will tell you if there's a problem in reading offset 0x003900 (section 4.3.8.13 shows the command is 0x2A, so search for "2A 00 39 00 00 80" in the log file). If the dump command is successful, @PoltoS may offer advice on how to procced. If the dump command fails with the same type of error, chances are high the flash chip has a problem (this is another guess).
Unfortunately, this level of troubleshooting is beyond my understanding.
Re: UZB Firmware Update from 5.07 to 5.27 fails
Please try to upgrade using the Z-Way UI as suggested by seattleneil
Re: UZB Firmware Update from 5.07 to 5.27 fails
Hi, I tried without success and also did the same thing with another host machine ( first was a raspberry pi, used for year with the dongle, second is a intel haswell generation computer).
I have the full log from z-way if wanted.
Partial log:
....
[2022-06-07 11:26:16.967] [zway] Job 0x2b (Write bytes to extended EEPROM): Done
[2022-06-07 11:26:16.967] [D] [zway] Job 0x2b (Write bytes to extended EEPROM): success
[2022-06-07 11:26:16.967] [zway] Removing job: Write bytes to extended EEPROM
[2022-06-07 11:26:16.967] [D] [zway] SENDING: ( 01 28 00 2B 00 47 C0 00 20 98 D3 9D AF D5 93 DB 06 32 1F D8 20 D8 D8 64 94 B9 89 49 31 6C 02 B7 E6 4A 7E E9 93 9A 72 F6 0C B7 )
[2022-06-07 11:26:16.971] [D] [zway] RECEIVED ACK
[2022-06-07 11:26:16.976] [D] [zway] RECEIVED: ( 01 04 01 2B 01 D0 )
[2022-06-07 11:26:16.976] [D] [zway] SENT ACK
[2022-06-07 11:26:16.976] [zway] Job 0x2b (Write bytes to extended EEPROM): Done
[2022-06-07 11:26:16.976] [D] [zway] Job 0x2b (Write bytes to extended EEPROM): success
[2022-06-07 11:26:16.976] [zway] Removing job: Write bytes to extended EEPROM
[2022-06-07 11:26:16.976] [D] [zway] SENDING: ( 01 28 00 2B 00 47 E0 00 20 76 C1 0F D5 00 37 C2 D7 3E 62 DA 1E 63 9F 48 CF B0 66 2F 62 C8 42 CD 22 D9 32 14 DE 4F AE CB 21 03 )
[2022-06-07 11:26:16.981] [D] [zway] RECEIVED ACK
[2022-06-07 11:26:16.984] [D] [zway] RECEIVED: ( 01 04 01 2B 01 D0 )
[2022-06-07 11:26:16.984] [D] [zway] SENT ACK
[2022-06-07 11:26:16.984] [zway] Job 0x2b (Write bytes to extended EEPROM): Done
[2022-06-07 11:26:16.984] [D] [zway] Job 0x2b (Write bytes to extended EEPROM): success
[2022-06-07 11:26:16.984] [zway] Removing job: Write bytes to extended EEPROM
[2022-06-07 11:26:16.984] [D] [zway] SENDING: ( 01 0A 00 2B 00 2F FE 00 02 00 00 0D )
[2022-06-07 11:26:16.987] [D] [zway] RECEIVED ACK
[2022-06-07 11:26:16.991] [D] [zway] RECEIVED: ( 01 04 01 2B 00 D1 )
[2022-06-07 11:26:16.991] [D] [zway] SENT ACK
[2022-06-07 11:26:16.991] [zway] Job 0x2b (Write bytes to extended EEPROM): Done (data unchanged, since is identical)
[2022-06-07 11:26:16.991] [D] [zway] Job 0x2b (Write bytes to extended EEPROM): success
[2022-06-07 11:26:16.991] [zway] Removing job: Write bytes to extended EEPROM
[2022-06-07 11:26:16.991] [zway] Adding job: Start reflashing bootloader of Z-Wave.Me firmware for 5th generation Z-Wave chip
[2022-06-07 11:26:17.001] [D] [zway] SENDING (cb 0x05): ( 01 05 00 F4 06 05 0D )
[2022-06-07 11:26:17.004] [D] [zway] RECEIVED ACK
[2022-06-07 11:26:18.227] [D] [zway] RECEIVED: ( 01 04 01 F4 01 0F )
[2022-06-07 11:26:18.227] [D] [zway] SENT ACK
[2022-06-07 11:26:18.227] [zway] Job 0xf4 (Start reflashing bootloader of Z-Wave.Me firmware for 5th generation Z-Wave chip): Wrong checksum
[2022-06-07 11:26:18.227] [D] [zway] Job 0xf4 (Start reflashing bootloader of Z-Wave.Me firmware for 5th generation Z-Wave chip): fail
[2022-06-07 11:26:18.227] [I] [zway] Removing job: Start reflashing bootloader of Z-Wave.Me firmware for 5th generation Z-Wave chip
another strange point, i encountered a strange behaviour where the the version / status numbers are different ( extracted with the RPI):
the same issue with as with this one (https://forum.z-wave.me/viewtopic.php?p=89109#p89109):
The one with boot loader reported versions is 7278:
Device ready in:5.90655899048 seconds
FULL INFO
Openning port .............................. OK
SERIAL INFO
VERSION: 05 17 VENDOR: 01 15
ZME_CAPABILITIES
UID: 87 60 AD 99 95 9D A0 A7 0C CD 77 EF 44 86 63 15
VENDOR: 00 00 NODES: FF
FLAGS: 01 00 00 00 00 00 00 00 00 00 00 00 00
FIRMWARE CRC
BOOT: 72 78 FW: CD 4F
MISC
FREQ: EU
NVR Content
--------------------------------------------------------------------------------------------
Prog/erase lock : FF FF FF FF FF FF FF FF, Read back lock: FF
Rev 01, Cal 80, TXCal 17 13, SAW 0D 3C DE 05, Pin 01, CRC 9F 9C
NMV: CS 15, TYPE 02, SIZE 01 00, PSIZE 00 80 (EEPROM Unknown)
USB: VID FF FF, PID FF FF, UUID 12 34 56 78 90 12 34 56 78 90 12 34 56 78 90 12
--------------------------------------------------------------------------------------------
FACTORY ID: WEEK 255, YEAR 255, CHIP FF FF, SER FF FF, WS 255, HWREV: FF FF, CRC8 FF
elapsed 8.03518104553 seconds
the other strange one with FC8B:
Device ready in:3.01709508896 seconds
FULL INFO
Openning port .............................. OK
SERIAL INFO
VERSION: 05 17 VENDOR: 01 15
ZME_CAPABILITIES
UID: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
VENDOR: 00 00 NODES: 00
FLAGS: 00 00 00 00 00 00 00 00 00 00 00 00 00
FIRMWARE CRC
BOOT: FC 8B FW: 57 94
MISC
FREQ: EU
NVR Content
--------------------------------------------------------------------------------------------
Prog/erase lock : FF FF FF FF FF FF FF FF, Read back lock: FF
Rev 51, Cal 83, TXCal 15 CD, SAW 37 4D A3 D8, Pin E4, CRC E1 F8
NMV: CS 58, TYPE AC, SIZE D8 FD, PSIZE C8 47 (EEPROM Unknown)
USB: VID 22 DF, PID 4A 26, UUID AB 9F 6E 8E A4 DE 3C 03 3C 52 74 86 23 46 CF E9
--------------------------------------------------------------------------------------------
FACTORY ID: WEEK 164, YEAR 8, CHIP E3 ED, SER 3A B4, WS 28, HWREV: D3 D0, CRC8 AC
elapsed 5.12447500229 seconds
-
- Posts: 193
- Joined: 02 Mar 2020 22:41
Re: UZB Firmware Update from 5.07 to 5.27 fails
From the diagnostic information you provided, I see 2 separate problems.
Problem 1: The z-way-server.log file shows an error executing serial API command 0xF4. This is a proprietary command (i.e., the purpose is not public knowledge, although we can infer from the error message that the command does some sort of CRC check - perhaps part of the Z-Way license validation check). @PoltoS will likely be able to provide you with a more informative answer. The good news is that it looks like the expert UI method successfully updated the flash memory with the new bootloader data (unlike the ZMESerialUpdater tool which encountered "0 returned 1 for ACK, 1 Unknown exception:Can't write NVM data! at=4200" when writing the the flash memory). Although the bootloader update process got further using the expert UI method, the update failed when executing the command 0xF4.
Problem 2: "the other strange one with FC8B" - the output you provided from the ZMESerialUpdater tool seems non-sensical. Unplug the UZB from the USB port and plug it back in. With luck, that will get you back to where the ZMESerialUpdater tool reports the bootloader version is 7278. If you continue to see non-sensical NVR data, hopefully @PoltoS can tell you how to update the NVR data.
I suggest you wait for a reply by @PoltoS. I'm optimistic he can help you as you've provided very good diagnostic information.
Problem 1: The z-way-server.log file shows an error executing serial API command 0xF4. This is a proprietary command (i.e., the purpose is not public knowledge, although we can infer from the error message that the command does some sort of CRC check - perhaps part of the Z-Way license validation check). @PoltoS will likely be able to provide you with a more informative answer. The good news is that it looks like the expert UI method successfully updated the flash memory with the new bootloader data (unlike the ZMESerialUpdater tool which encountered "0 returned 1 for ACK, 1 Unknown exception:Can't write NVM data! at=4200" when writing the the flash memory). Although the bootloader update process got further using the expert UI method, the update failed when executing the command 0xF4.
Problem 2: "the other strange one with FC8B" - the output you provided from the ZMESerialUpdater tool seems non-sensical. Unplug the UZB from the USB port and plug it back in. With luck, that will get you back to where the ZMESerialUpdater tool reports the bootloader version is 7278. If you continue to see non-sensical NVR data, hopefully @PoltoS can tell you how to update the NVR data.
I suggest you wait for a reply by @PoltoS. I'm optimistic he can help you as you've provided very good diagnostic information.
Re: UZB Firmware Update from 5.07 to 5.27 fails
Looks like a broken flash
Re: UZB Firmware Update from 5.07 to 5.27 fails
Hi,seattleneil wrote: ↑07 Jun 2022 19:16From the diagnostic information you provided, I see 2 separate problems.
Problem 1: The z-way-server.log file shows an error executing serial API command 0xF4. This is a proprietary command (i.e., the purpose is not public knowledge, although we can infer from the error message that the command does some sort of CRC check - perhaps part of the Z-Way license validation check). @PoltoS will likely be able to provide you with a more informative answer. The good news is that it looks like the expert UI method successfully updated the flash memory with the new bootloader data (unlike the ZMESerialUpdater tool which encountered "0 returned 1 for ACK, 1 Unknown exception:Can't write NVM data! at=4200" when writing the the flash memory). Although the bootloader update process got further using the expert UI method, the update failed when executing the command 0xF4.
Problem 2: "the other strange one with FC8B" - the output you provided from the ZMESerialUpdater tool seems non-sensical. Unplug the UZB from the USB port and plug it back in. With luck, that will get you back to where the ZMESerialUpdater tool reports the bootloader version is 7278. If you continue to see non-sensical NVR data, hopefully @PoltoS can tell you how to update the NVR data.
I suggest you wait for a reply by @PoltoS. I'm optimistic he can help you as you've provided very good diagnostic information.
For the problem 2, it's not systematically visible, i'm with the good version now ( 7278 ).
For the problem 1, the write error with the Haswell Intel PC was not "0 returned 1 for ACK, 1 Unknown exception:Can't write NVM data! at=4200" but ... "0 returned 1 for ACK, 1 Unknown exception:Can't write NVM data! at=5200".