Closed joemilbourn closed 6 years ago
Thanks! I am guessing the larger codeplug is for a slightly different radio, not the standard MD-380? But that larger codeplug has the RDT footer at the same location as the smaller one, it looks like the codeplug is right padded with several KB of 0xFF. I think G7RHV had some sort of subtle issue generating the codeplug for the MD380, and that's the original problem - or maybe he got a new radio and the RDT format is weirder than I thought.
The reason for the limit is the MD380 codeplug is very explicitly one size - I've only seen larger codeplugs on newer, different radio models (MD-2017, UV-380, ... ). Differently-sized RDT codeplug downloads might not fail, but my understanding suggests the larger codeplug is either not fully written, or not fully accessible to the radio.
For future readers, it fails with the size check in place because it uploaded the code plug including the RDT header data, meaning everything's offset from where it should be in memory and therefore corrupt data, from the point of view of the radio.
Calling
md380-dfu write codeplug.rdt
with a codeplug larger than 262709 bytes, or without the magic 'DfuSe' uploads the codeplug as raw bytes - result is a corrupt codeplug on the radio.To reproduce, see example codeplugs from G7RVH attached; uploading
TYT_East Anglia_2018_07_30.rdt
, size 257kbytes, works as expected, uploadingTYT_East Anglia_2018_09_01.rdt
, size 833kbytes, results in a corrupt codeplug.PR #883 adds a check for correct size and magic to
md380_dfu.py
warning and exiting if they're not as expected.Removing the size check and uploading the larger codeplug works as expected, but not included in the PR as I don't know the reason for the limit!
example_codeplugs.zip