The SAMBA boot code is stored in ROM on the 7X(C)256's. The GPNVM bit
(is it 2?) selects whether the ROM (default - GPNVM 2 erased), or
Application FLASH (GPNVM 2 programmed), is mapped in at 0x0000000 on
bootup. I can't remember if the ROM is mapped up somewhere higher up
in memory as well (and is therefore "visible" after the remap
instruction), but I'd be surprised if it isn't.

Now, if your installed application code has a means whereby it can
alter the GPNVM bit, (eg. via a command/password to a command shell
running on the serial port or whatever), you can jump back to the SAMBA
bootloader by simply clearing the GPNVM bit and resetting the micro.
You can get back to your application by using the SAMBA windows client
to reprogram the GPNVM bit and reset the micro (again!).

Failing that, if the SAMBA rom is accessible, and written in entirely
relocatable code, then you could possibly get away with a programmed
jump to the address and boot into SAMBA that way (assuming the ROM is
mapped into memory at run-time, AND that the rom based code doesn't
care what "base address" it runs from). You can then get back to your
application simply by resetting the micro.

Failing either of the above, THE ONLY WAY to get back to SAMBA is to
jiggle the power WHILE TYING THE ERASE pin (NOT the Tst pin!). This
WILL ALSO CLEAR your entire application flash and restore the GPNVM
bits to defaults, which says boot from SAMBA ROM on the next reset. You
WILL NOT be able to return to your application simply by flipping the
GPNVM bit because your flash has been erased! (However, you can of
course, re-download it using the SAMBA windows client).

"Device Initialization"

Initialization follows the steps described below:
1. FIQ initialization
1. Stack setup for ARM supervisor mode
2. Setup the Embedded Flash Controller
3. External Clock detection
4. Main oscillator frequency detection if no external clock detected
5. Switch Master Clock on Main Oscillator
6. Copy code into SRAM
7. C variable initialization
8. PLL setup: PLL is initialized to generate a 48 MHz clock necessary to use the USB
Device
9. Disable of the Watchdog and enable of the user reset
10. Initialization of the USB Device Port
11. Jump to SAM-BA Boot sequence
SAM-BA Boot
The SAM-BA boot principle is to:
– Wait for USB Device enumeration

"Краткий пересказ"

"У нашей темы скоро юбилей, 3000 просмотров."

Может найдутся и те кто создавал проекты на AT91SAM7X или те у кого есть такие же прогеры, причём как в рабочем состоянии, так и нет, а также клоны или ориги, не суть.
У нас к ним много вопросов
Хотя это конечно специфический прогер для автоэлектриков и эту тему бы создать на профильном форуме, но так как речь всё же идёт о программно аппаратном ремонте, то значит всё верно.
Я думаю что шансы выйти из тупика ещё есть, хоть и маленькие.

"Дело в том что я так понял у этого прогера-клона есть глобально две проблемы:"

Первая это перенапряжение по DCIN выше 5 вольт, впрочем как и у оригинала!
Вторая это обновление ПО с версии 1.34 до версии 1.36 именно на A021!

Так вот вторая прям массовая

Я посмотрел в HEX редакторе orange5.upd и дизассемблировал update7.exe
orange5.upd - Похож на закодированный архив с заменой заголовка HEX на OR5I, например с Rar!
update7.exe - Это похоже внешний апдейтер с функцией декодера+распаковщика на основе 7-Zip SDK.
Зашифровали архив, ну и ладно, защита авторских прав как ни как)))

Посмотрел вот это видео, т.к. в нем есть процедура обновления на версии 38CD
:

На замедленном воспроизведении видно что в основном все файлы в архиве рабочие, прошивок по крайней мере не видать
И это всё в совокупности наталкивает меня на мысль о том что это просто борьба с клонами со стороны разрабов!
Рискну предположить что они могут просто отключать микроконтроллер не меняя прошивку полностью!
И эту функцию они включили в новой версии ПО!
Я имею ввиду, то что прогер может отрубится просто при подключении к ПО 1.36, а не во время обновления, т.е. его блокирует новая версия программы!
Конечно может быть что обновление не видно потому что версия FW и так последняя.