You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently uFlash hexelifies by adding an “extended linear address record type" entry right before the python script starts. The unhexlify function relays on this entry to be immediately before the script, which might not be explicitly declared a second time if the hex file was created or extracted using different methods.
For testing purposes I am attaching a hex file where the data between start of address 0003xxxx and 0x0003e000 is present as such, without a double :020000040003F7 entry: ubit_flash.txt (just rename from txt to hex).
The text was updated successfully, but these errors were encountered:
Right, so I just noticed that #16 has been submitted already to cover this.
I haven't had a chance to look at this properly but it feels slightly over engineered? Unless it's trying to do much more than this, I think all we need to do is traverse the hex file, find all :020000040003F7 entries and then from that line search for the address offset E000 (so a line starting with :10E00000) before any other “extended linear address record type" entry is found.
Does the PR also add the intelhex package dependency? I personally quite like uFlash to be a portable module.
Currently uFlash hexelifies by adding an “extended linear address record type" entry right before the python script starts. The unhexlify function relays on this entry to be immediately before the script, which might not be explicitly declared a second time if the hex file was created or extracted using different methods.
For testing purposes I am attaching a hex file where the data between start of address
0003xxxx
and0x0003e000
is present as such, without a double:020000040003F7
entry:ubit_flash.txt (just rename from txt to hex).
The text was updated successfully, but these errors were encountered: