<div dir="ltr"><div>Hi,</div><div><br></div><div>The fact that you've confirmed that the way I've modified the chirp driver should be enough is already a step forward!<br>We'll keep on looking at the firmware, especially why things work with the memory backup tool.</div><div><br></div><div>Thanks for your help!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 10 janv. 2024 à 00:07, Dan Smith via chirp_devel <<a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> I am part of a project which aims to create open source firmware to improve the features of the Radtel RT890 Radio and its clones (Ruyage UV58Plus / Iradio UV 5118 plus).<br>
> We use a custom version of the iradio_uv_5118plus.py driver which works, we modified the frequency limits, the modulations, added the scanlists...<br>
> In an attempt to remain compatible with the manufacturer's firmware we stored most of new settings outside of the original settings memory area, I tried integrating that area into the chirp image and it didn't go well...<br>
> The new memory area (0x3D5000) is located after the original settings area (0x3C1000).<br>
> My intention was to increase the value of END_ADDR and _memsize to download memory from the start of the original area to the end of the new area, then add an entry in _ranges to write the new settings.<br>
> During my tests, I obtain an image which is the desired size but its content cycle the original area (basically if I double the size, I have twice the original information concatenated).<br>
<br>
FWIW, I think your CHIRP changes are correct - meaning, you should be able to just extend the address that you read from to include the new area. However, the behavior you're seeing is exactly what I see when I read past the end of lots of radios that support address-based operations. I assume the radio has a sort of "modulo memory size" behavior implemented in the read command internally. Thus if you provide an address larger than the max it is expecting, you wrap around to the beginning.<br>
<br>
You could also check and make sure that the read command isn't wrapping around due to the actual width of the field. It looks like the driver reads blocks and uses a 16-bit field to do so, but also applies some READ_OFFSET value that is pretty large. So if the block you're trying to read is past the end of READ_OFFSET+blocknum, you might be wrapping back to zero.<br>
<br>
So, I haven't closely examined that driver and mentally applied your changes, but a quick glance makes me think that's all that should be required. Thus, I suspect there's something else going on in the radio, like some cloning code that needs to be changed, in order to read the later regions. The fact that you see the same behavior with an unmodified radio supports this theory, IMHO.<br>
<br>
--Dan<br>
_______________________________________________<br>
chirp_devel mailing list<br>
<a href="mailto:chirp_devel@intrepid.danplanet.com" target="_blank">chirp_devel@intrepid.danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" rel="noreferrer" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_devel</a><br>
Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" rel="noreferrer" target="_blank">http://chirp.danplanet.com/projects/chirp/wiki/Developers</a><br>
</blockquote></div>