I've opened up this issue to temporarily log various observed behavior that the ISP bootloader seems to exhibit. This mostly concerns ISP bootloader 3e0ebd0c440af5236d7ff8872343f85d found on SH68F90A (BYK916))
Exhibit 1 - no LJMP at 0xEFFB
When the device has firmware preloaded with no LJMP instruction at 0xEFFB, the first read cycle (magic_sauce) made through the ISP bootloader will cause it to add an LJMP 0x0000 at 0xEFFB. This will only be visible through a separate programming device (as a sinolink) since reading firmware through ISP will blank out regions 0xEFFB - 0xEFFD.
Writing the resulting dump from the read operation back without modification will cause the bootloader to overwrite the LJMP at 0x0000 and most likely brick the device.
Interestingly the bootloader does seem to detect that an LJMP 0x0000 is not valid and replaces that address to point back to itself - 0xF000. Unfortunately, this still causes the device to brick itself, because the bootloader code doesn't seem to have the necessary init routines. I have not verified this yet, but I assume it does not initialize the HRCLK/SYSCLK which should be necessary for USB peripheral operation.
I've opened up this issue to temporarily log various observed behavior that the ISP bootloader seems to exhibit. This mostly concerns ISP bootloader
3e0ebd0c440af5236d7ff8872343f85d
found on SH68F90A (BYK916))Exhibit 1 - no LJMP at 0xEFFB
When the device has firmware preloaded with no
LJMP
instruction at0xEFFB
, the first read cycle (magic_sauce) made through the ISP bootloader will cause it to add anLJMP 0x0000
at0xEFFB
. This will only be visible through a separate programming device (as a sinolink) since reading firmware through ISP will blank out regions0xEFFB - 0xEFFD
.Writing the resulting dump from the read operation back without modification will cause the bootloader to overwrite the
LJMP
at0x0000
and most likely brick the device.Interestingly the bootloader does seem to detect that an
LJMP 0x0000
is not valid and replaces that address to point back to itself -0xF000
. Unfortunately, this still causes the device to brick itself, because the bootloader code doesn't seem to have the necessary init routines. I have not verified this yet, but I assume it does not initialize the HRCLK/SYSCLK which should be necessary for USB peripheral operation.