@Bellmac
The function "rrgn" (copy region) dumps the entire space that's allocated to it in the region layout, that's including empty available space along with already written data. The unused space simply shows as empty FF's at the end of the file when a dumped BIN is viewed in a hex reader. If you were to remove all the extraneous FF bytes beyond the checksum the resultant saved file should then exactly match the bin file from the firmware RGN or GCD.

The firmware regions of your 1350 are not encrypted like the nonvol region. Regions 14 & 127, as most other regions of the flash memory (other than protected ones like region 5 for example) can be dumped fully and plainly read and manipulated in a hex editor. In fact a suitably modified fw file is accepted and used by a 1xxx device with a correct checksum written at the end of its usable data. Region 41 is quite different - even if first decrypted, its data modified, the checksum corrected, then re-encrypted to XOR before flashing back to the device, it will be partially overwritten appropriately by the device itself on the next successful boot cycle. Therefore, making any changes is pointless. The only time writing nonvol back to the device is worthwhile is when you have a 'clean' unadulterated backup from the past and you know or suspect that the region presently has poisoned data.

So you don't need to upload the 14 & 127 dumped files as you did with 41, you can check them yourself. Simply open them and the corresponding original BIN from the firmware in a hex editor (Hex Compare as shown below is perfect as you can open 2 files at once then use "Search > Go To First Difference"). They should be the same data, other than a whole lot of FFs trailing behind the checksum in the dumped file, i.e.: The original 14.bin from the fw is exactly 9,340,160 bytes (8.907470703125 MiB or 9121.25 KiB - that's mebibytes and kibibytes which uses binary factor 1024, not decimal 1000 used by MB / KB - megabyte / kilobyte). However as said, the dumped region bin file is much larger only due to the empty FFs trailing beyond the checksum - which is E7 in V6.30 fw's 14.bin (fw_all.bin). Removing all FFs behind the checksum in the dumped file (it is 16,777,216 bytes/16MiB/16384KiB) should result in identical data files with size of 9,340,160 bytes. Like mine, your dumped file comparison should have the first difference as the FF behind checksum E7. If not the same right up to there, it indicates corruption in region 14.

Spoiler: Hex Image
[Only registered and activated users can see links. ]

BTW, Windows rounds up and still stubbornly uses the (original and technically correct) binary form with factor 1024. For instance, 9121.25 MiB (9,340,160 bytes) is shown in Explorer as "9122 MB".

Please either report on your own comparisons of the dumped BINs or upload them so i can inspect them. Once that's established one way or the other, we can try other things. Provided this isn't a hardware problem (that's still very much on the cards), I honestly do think that there's maybe some serious corruption in either 14, 127 or 41 so if we rule out fw it only leaves nonvol as the villain. That still wouldn't fully explain why 14 & 127 can be dumped using "xrgn" but not overwritten with "rrgn" ... although a poisoned nonvol can do weird things. If we have to eventually erase 41 fully and the problems persist it only leaves hardware as the problem, as in a failing flash.

@VadimK
Good lateral thinking there. However it's not the answer, provided the file to be written to a region is smaller than the total region size it will succeed. It's actually the other way around where a file larger than the region's space may fail, even if only marginally bigger i.e. region 14's available space is 16,777,216 bytes and we try to flash a file of 16,777,217 size to it it'll likely fail but 16,777,216 or less will succeed.