Bootloader not starting after first boot after flash

[AbidingOhmsLaw]

Trying to flash openIPC to a Q-See QTN8037BC camera that has a Hi3518EV200 and a 16MB NOR, no SD card, the camera is new-old-stock and not been setup on any NVR

To install I followed the install instructions here:

https://openipc.org/cameras/vendors/hisilicon/socs/hi3518ev200?mac=62-df-0b-ce-42-1f&cip=10.0.0.161&sip=10.0.0.148&net=&rom=nor16m&var=lite&sd=

Backup went without issues and the flash of the new openIPC firmware completed without error, After entering the "reset" command I Immediately entered Ctrl-C several times to get into the bootloader to enter the "run setnor16m" command but is seems to be stuck in a boot loop only giving "System startup" over and over until power is removed. I tried to interrupt with different keystrokes but it looks like the bootloader is not even starting.

I copy/pasted the commands from the install one by one but with the only thing of interest being that I had to use the "tftp 0mx82000000 openipc-hi3518ev200-lite-16mb.bin" command rather than the "tftpboot 0x82000000 openipc-hi3518ev200-lite-16mb.bin" command.

My question is where do I go from here, does the HiSilicon chip have a way to recover and reflash? I do realize that is more of a support help rather than a source code bug or change request, and I did see that support channel is on Telegram but I do not have a Telegram account and it is not letting me set one up because it wont run on my de-Googled mobile, so let me know if there is another forum available.

This is the captured boot log of the unit prior to flashing openIPC
Q-See.txt

[openipc-ai]

Yes — the Hi3518EV200 has a hardware recovery route, and your camera is in exactly the state it was designed for. Details below, plus what I think went wrong, because I don't think this was your mistake.

Your camera is not in a boot loop — the bootloader is gone

System startup is printed by the SoC's mask ROM, before any bootloader runs. You can see the boundary in your own pre-flash log:

System startup          <- mask ROM

U-Boot 2010.06-svn112   <- bootloader, loaded from flash offset 0

Now the first line still appears and the second never does. The ROM starts, finds nothing loadable at flash offset 0, and resets. That's a blank/corrupt boot sector, not a bad kernel — a bad kernel would still have left you at a U-Boot prompt. It also explains why no amount of Ctrl-C helped: there is no U-Boot running to interrupt.

The image you downloaded was fine

I fetched the exact artifact you flashed and checked it:

$ curl -sL -o fw16.bin "https://openipc.org/cameras/vendors/hisilicon/socs/hi3518ev200/download_full_image?flash_size=16&flash_type=nor&fw_release=lite"

size            16777216 bytes
0x000000        ARM vector table, HiSilicon magic 0x12345678 at 0x3C
0x000000..0x022000   U-Boot (136 KB)
0x050000        uImage "Linux-4.9.37-hi3518ev200", 1875507 bytes, load/entry 0x80008000
0x350000        squashfs, 4954774 bytes
rest            0xFF

That is the correct 16MB layout (matches mtdpartsnor16m). So the file was good — the problem is that it never reached the flash.

Why a failed transfer silently bricks the board

The generated instruction block is:

mw.b 0x82000000 0xff 0x1000000
tftpboot 0x82000000 openipc-hi3518ev200-lite-16mb.bin
sf probe 0; sf lock 0;
sf erase 0x0 0x1000000; sf write 0x82000000 0x0 0x1000000

The first line deliberately fills 16MB of RAM with 0xFF. The erase and write then run unconditionally — there is no && after the transfer and the length is a hardcoded 0x1000000 instead of ${filesize}. So if the download doesn't land in that buffer, the last line still erases the whole chip and writes 16MB of 0xFF over your bootloader, and reports success while doing it.

Compare OpenIPC's own U-Boot env vars, which get this right:

uknor16m=mw.b ${baseaddr} ff 1000000; tftpboot ${baseaddr} uImage.${soc} && sf probe 0; sf erase 0x50000 0x300000; sf write ${baseaddr} 0x50000 ${filesize}
                                                                        ^^                                                            ^^^^^^^^^^

en/install-hisi.md in the wiki uses the same && + ${filesize} shape. Only the openipc.org block drops both guards. Filed as OpenIPC/website#55 — the generator lives there, not in this repo.

Two things worth checking on your side, since either would pin down which way the transfer went astray:

1. The address. You wrote tftp 0mx82000000 …. If that's literally what was typed rather than a typo in the report, U-Boot's hex parser stops at the first non-hex character, so 0mx82000000 parses as 0 — the file went to address 0 and the 0xFF buffer at 0x82000000 is what got written to flash.
2. The argument count. HiSilicon's combined tftp treats the three-argument form (tftp <addr> <file> <len>) as an upload, which is exactly what the backup step on that same page uses. If you carried that shape over to the flashing step, U-Boot would have sent 16MB of 0xFF to your TFTP server and left RAM untouched. Check whether openipc-hi3518ev200-lite-16mb.bin in your TFTP root is now all 0xFF.

Recovery

Every HiSilicon SoC's mask ROM listens on UART0 for a serial download handshake at power-on, before U-Boot. Nothing in flash can disable it — each System startup you're seeing is one of those windows opening. defib drives it.

Use the CLI, not the browser tool. hi3518ev200 needs a frame-blast handshake that the WebSerial build doesn't implement (OpenIPC/defib#121), so it will refuse the chip.

uv tool install defib     # or: pipx install defib

First, just get a console back. This writes nothing to flash — U-Boot runs from RAM:

defib burn -c hi3518ev200 -p /dev/ttyUSB0 -t

(the right U-Boot is downloaded from OpenIPC automatically; pass -f u-boot-hi3518ev200-universal.bin if you'd rather supply it yourself)

Start defib first, then apply power to the camera — the ROM's window is short.

Once you have the OpenIPC # prompt, you can flash properly. Or do the whole thing in one shot:

wget https://github.com/OpenIPC/firmware/releases/download/latest/openipc.hi3518ev200-nor-lite.tgz
sudo defib install -c hi3518ev200 \
  --firmware openipc.hi3518ev200-nor-lite.tgz \
  -p /dev/ttyUSB0 --nor-size 16

That burns U-Boot to RAM, breaks into the console, serves the kernel and rootfs over its own TFTP server, and verifies each partition with CRC32.

If you'd rather put the vendor firmware back, you have a backup:

sudo defib restore -c hi3518ev200 -i backup-hi3518ev200-nor16m.bin \
  --flash-type nor -p /dev/ttyUSB0

Validate that backup file before trusting it — whatever misdirected the flashing transfer could have affected the backup step too:

python3 -c "d=open('backup-hi3518ev200-nor16m.bin','rb').read(); print(len(d), 'bytes,', sum(b!=0xff for b in d), 'non-0xFF bytes')"

A healthy vendor dump is 16777216 bytes with several million non-0xFF bytes. If it's all 0xFF, the backup is empty and only the OpenIPC route above is available.

When you re-flash

After the image is written, run setnor16m is still the right follow-up — it exists in this U-Boot (printenv in #695 confirms it for hi3518ev200) and switches mtdparts to the 16MB layout with rootfs at 0x350000. Until you run it the board uses the 8MB defaults and won't mount its rootfs.

And prefer the guarded form of the flash sequence, which fails safe instead of erasing on a bad transfer:

tftpboot 0x82000000 openipc-hi3518ev200-lite-16mb.bin && sf probe 0 && sf erase 0x0 0x1000000 && sf write 0x82000000 0x0 ${filesize}

On support channels

Telegram isn't the only option — GitHub issues like this one are read, and this is a legitimate report rather than "just support": it surfaced a real defect in the generated instructions. There's also the wiki and OpenIPC/firmware Discussions.

[openipc-ai]

Quick update: the instruction generator is fixed and the change is live on openipc.org. Your report is what surfaced it — OpenIPC/website#55, fixed by OpenIPC/website#56.

The page now gives you this:

sf probe 0; sf lock 0;
tftpboot 0x82000000 openipc-hi3518ev200-lite-16mb.bin && sf erase 0x0 0x1000000 && sf write 0x82000000 0x0 ${filesize}

instead of what you were given:

tftpboot 0x82000000 openipc-hi3518ev200-lite-16mb.bin
sf probe 0; sf lock 0;
sf erase 0x0 0x1000000; sf write 0x82000000 0x0 0x1000000

The && means a failed transfer never reaches the erase, and ${filesize} bounds the write to what actually arrived. The same guard went into the U-Boot-only and the restore-from-backup blocks — the restore one especially, since that is the path people use when they are already trying to un-brick a camera.

None of that helps the camera you have in front of you, which still needs the defib route from my earlier comment. It does mean nobody else gets caught the same way.

Two things I'd still like to know when you get a chance, if the hardware hasn't gone in a drawer:

1. Is openipc-hi3518ev200-lite-16mb.bin in your TFTP server's directory now 16MB of 0xFF? If it is, your tftp uploaded instead of downloading, and the argument shape is the thing to fix rather than the address.
2. Did the defib recovery work?

The first one is genuinely useful to us regardless of how your camera ends up — it decides whether the note I added about tftp's third argument is the real fix or just a footnote. No rush, and no obligation.

[AbidingOhmsLaw]

@openipc-ai Thank you for the detailed information!

Using the defib tool I get the following error:

(mike) mike@mike-debian:~$ defib burn -c hi3518ev200 -p /dev/ttyUSB0 -t
Firmware: u-boot-hi3518ev200-universal.bin (cached)
Protocol: HiSilicon Standard
Port: /dev/ttyUSB0
INFO:defib.transport.serial_platform:Using standard SerialTransport for linux
Loaded profile: hi3518ev200
Using sendFrameForStart handshake for hi3518ev200
Sending 135452 bytes of firmware...
  Sending DDR step ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:04
INFO:defib.protocol.hisilicon_standard:SPL boundary detected (LZMA) at 0x4800 (18432 bytes); profile default was 0x3B00 (15104 bytes)
Recovery failed: Failed to send SPL
  Sending DDR step ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:04
⠸ Sending SPL      ━━━━━━━━━━━━━━━━━━━━━━━╺━━━━━━  78% 0:00:07

Failed: Failed to send SPL

As you can see it hangs at 78% on the SPL and fails, possibly due to a wrong address? Any suggestions?

[openipc-ai]

That's a defib bug, not your setup or your address. Thanks for pasting the full output — the numbers in it are enough to pin it exactly.

The 78% is a specific byte, not a random stall

The line above the failure is the important one:

SPL boundary detected (LZMA) at 0x4800 (18432 bytes); profile default was 0x3B00 (15104 bytes)

defib scans the U-Boot image for the compressed payload to work out how much of the front of the
file is SPL code. In u-boot-hi3518ev200-universal.bin (135452 bytes — same file you have, I
checked) the LZMA header sits at offset 0x4BB0, so defib decides the SPL is 0x4800 = 18432
bytes and sends it as 18 chunks of 1 KB.

The Hi3518EV200 loads that into SRAM at 0x04010500, and its SRAM ends at 0x04014000:

SPL load address	0x04010500
SRAM ends	0x04014000
room available	0x3B00 — 15104 bytes, 15 chunks
defib tried to send	0x4800 — 18432 bytes, 18 chunks

Chunks 1–14 fit, ending at 0x04013D00. Chunk 15 writes 0x04013D00..0x04014100 and runs off the
end of SRAM into the memory the boot ROM is using for its own stack. So:

14 of 18 chunks = 77.8%. That is your 78%.

Once that write lands, the boot ROM faults and drops back into download mode, which is why the
retry stopped in the same place instead of somewhere else.

Your profile is simply missing a ceiling that its siblings already have. We hit exactly this on a
Hi3520DV200 in May — same load address, same chunk 15, same 0x04014000 — and fixed it there
(defib#78) by giving that chip an SRAM limit. The
Hi3518EV200 never got the field.

On cabling — worth ruling out, but the evidence points elsewhere

Long or marginal UART wiring genuinely does break this protocol, and it was the first thing we
considered. Two things argue against it here:

• Your DDR init step and the first 14 SPL chunks all went through clean. A marginal link doesn't
  fail 14 chunks in and then fail at the same place twice; it fails at a different offset each time,
  and it usually disturbs the DDR step too.
• 78% is not an arbitrary point. It's the last chunk that fits in SRAM. That coincidence is very
  hard to get from noise.

If you want to settle it rather than take my word for it, add --debug and look at what the chip
sends back when the chunk fails:

defib burn -c hi3518ev200 -p /dev/ttyUSB0 -t --debug 2>&1 | tee defib.log

• no ACK ... after N stray bytes (last 0x20) — the chip answered with boot-mode markers. That's
  the boot ROM resetting itself, i.e. the SRAM overflow. Deterministic.
• silent timeout over and over, or stray bytes that are random values — that's the link. Then
  shorter wires, a different USB-UART adapter, and a common ground are the right things to try.

What you can do right now

The fix is a one-line profile change, so you don't have to wait for a release — install straight
from the branch:

uv tool install --force "git+https://github.com/OpenIPC/defib@fix/hi3518ev200-spl-sram-ceiling"

(or pipx install --force "git+https://github.com/OpenIPC/defib@fix/hi3518ev200-spl-sram-ceiling")

Then the same command as before — start defib first, then power on the camera:

defib burn -c hi3518ev200 -p /dev/ttyUSB0 -t

You should now see capping at SRAM limit in place of the old boundary line, and the SPL bar
should go to 100% over 15 chunks instead of stopping at 18.

To be straight with you about where this stands: I have no Hi3518EV200 on the bench, so I've
verified the arithmetic and the test suite but not the burn. 0x3B00 isn't a guess —
0x04010500 + 0x3B00 lands exactly on 0x04014000, and it's also the size HiSilicon's own HiTool
uploads for this chip, so the capped transfer is byte-for-byte what the vendor tool sends. But
you'd be the first person to run it on real silicon.

Whatever happens, the output is useful. Three ways it can go:

1. SPL reaches 100% and you get an OpenIPC # prompt. Fixed. Carry on with defib install as
   in my earlier comment.
2. SPL reaches 100%, then still "Failed to send SPL". The overflow is fixed but the truncated
   SPL isn't executing — that's what happened on the Hi3520DV200, and it means the problem is in
   how the image is built rather than in defib. Worth knowing.
3. Still 78%. Then I'm wrong about the ceiling and we go back to the cabling question with the
   --debug log.

The change is up as defib#126 and I'm holding it until
we hear how it goes on your board.

One loose end from last time, still useful whenever you get to it: is
openipc-hi3518ev200-lite-16mb.bin in your TFTP server's directory now 16 MB of 0xFF? That tells
us whether your original tftp uploaded instead of downloading, which decides how we word the
warning on the flashing page.

[AbidingOhmsLaw]

@openipc-ai

I reinstalled defib with the command you gave above and SPL still fails at the same spot, I tried a very short cable (6 in) and still the same and already using a common GND so I might need to get a new UART. The one I have is one that "Auto" detects the TTL voltage level without a way set it between 5v and 3v3 with a jumper. I've not had any issues with ESP32s and other micro-controllers but this is the only HiSilicon I've worked with so far. The debug log does indeed show silent timeouts at that point.

Firmware: u-boot-hi3518ev200-universal.bin (cached)
Protocol: HiSilicon Standard
Port: /dev/ttyUSB0
INFO:defib.transport.serial_platform:Using standard SerialTransport for linux
Loaded profile: hi3518ev200
Using sendFrameForStart handshake for hi3518ev200
Sending 135452 bytes of firmware...
DEBUG:defib.protocol.hisilicon_standard:send_firmware: profile=hi3518ev200 firmware=135452 bytes spl_override=False
DEBUG:defib.protocol.hisilicon_standard:sendFrameForStart: blasting 0xAA+HEAD(64, 0x04013000) for 30s
DEBUG:defib.protocol.hisilicon_standard:sendFrameForStart: ACK after 212 blasts
DEBUG:defib.protocol.hisilicon_standard:=== PRESTEP0 === address=0x04013000 data=64 bytes
DEBUG:defib.protocol.hisilicon_standard:HEAD: length=64 address=0x04013000
DEBUG:defib.protocol.hisilicon_standard:TX HEAD (14 bytes): fe 00 ff 01 00 00 00 40 04 01 30 00 51 9c
DEBUG:defib.protocol.hisilicon_standard:TX HEAD ACKed (attempt 1/16)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=1 payload=64 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (69 bytes): da 01 fe 04 e0 2d e5 24 00 9f e5 24 10 9f e5 00 10 80 e5 20 00 9f e5 20 10 9f e5 04 10 80...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:TAIL: seq=2
DEBUG:defib.protocol.hisilicon_standard:TX TAIL (5 bytes): ed 02 fd ba b0
DEBUG:defib.protocol.hisilicon_standard:TX TAIL ACKed (attempt 1/16)
DEBUG:defib.protocol.hisilicon_standard:=== DDR STEP === address=0x04013000 data=64 bytes
DEBUG:defib.protocol.hisilicon_standard:HEAD: length=64 address=0x04013000
DEBUG:defib.protocol.hisilicon_standard:TX HEAD (14 bytes): fe 00 ff 01 00 00 00 40 04 01 30 00 51 9c
DEBUG:defib.protocol.hisilicon_standard:TX HEAD ACKed (attempt 1/16)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=1 payload=64 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (69 bytes): da 01 fe 04 e0 2d e5 24 00 9f e5 24 10 9f e5 00 10 80 e5 20 00 9f e5 20 10 9f e5 04 10 80...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:TAIL: seq=2
DEBUG:defib.protocol.hisilicon_standard:TX TAIL (5 bytes): ed 02 fd ba b0
DEBUG:defib.protocol.hisilicon_standard:TX TAIL ACKed (attempt 1/16)
DEBUG:defib.protocol.hisilicon_standard:send_firmware: rehandshake before SPL
DEBUG:defib.protocol.hisilicon_standard:rehandshake: waiting up to 5s for bootmode markers
INFO:defib.protocol.hisilicon_standard:SPL boundary detected (LZMA) at 0x4800 (18432 bytes); profile default was 0x3B00 (15104 bytes)
DEBUG:defib.protocol.hisilicon_standard:=== SPL === address=0x04010500 size=18432 chunks=18
DEBUG:defib.protocol.hisilicon_standard:HEAD: length=18432 address=0x04010500
DEBUG:defib.protocol.hisilicon_standard:TX HEAD (14 bytes): fe 00 ff 01 00 00 48 00 04 01 05 00 dd c6
DEBUG:defib.protocol.hisilicon_standard:TX HEAD ACKed (attempt 1/16)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=1 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 01 fe 17 04 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=2 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 02 fd 70 82 11 20 00 3f 00 00 00 00 00 00 7d 00 00 00 70 83 11 20 00 3f 00 00 00 00 00...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=3 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 03 fc d8 83 11 20 00 00 00 00 00 00 00 00 fd 00 00 00 1c 82 11 20 10 10 10 10 00 00 00...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=4 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 04 fb 44 00 11 20 00 10 00 01 00 00 00 00 fd 00 00 00 48 00 11 20 00 10 00 01 00 00 00...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=5 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 05 fa 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=6 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 06 f9 48 00 8d e2 34 50 8d e2 0e 10 a0 e1 0f 00 85 e8 0d 00 a0 e1 8c 0c 00 eb 00 00 a0...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=7 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 07 f8 20 a1 07 00 00 00 05 20 a0 86 01 00 02 00 52 e3 13 00 00 0a 81 13 80 e0 1c 22 91...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=8 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 08 f7 0a 30 a0 e1 07 10 a0 e1 09 00 a0 e1 01 50 85 e2 83 ff ff eb 04 00 55 e1 f5 ff ff...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=9 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 09 f6 10 d0 8d e2 f0 8e bd e8 38 20 9d e5 34 10 9d e5 0c 00 96 e5 cb ff ff eb 02 00 57...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=10 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 0a f5 01 00 7c e3 6a ff ff 1a 09 91 84 e0 14 b0 89 e5 94 b0 89 e5 0a 10 a0 e1 04 00 94...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=11 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 0b f4 00 00 05 20 50 c0 90 e5 ac c1 a0 e1 06 c0 0c e2 04 00 5c e3 04 c0 a0 23 00 00 5c...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=12 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 0c f3 00 00 54 e3 18 00 00 1a 14 10 9d e5 70 30 91 e5 01 26 83 e3 01 36 c3 e3 70 20 81...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=13 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 0d f2 a0 30 81 e5 ea ff ff 0a 8f 3f 81 e2 20 c0 8d e2 00 00 a0 e3 02 e0 a0 e1 00 10 9c...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=14 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 0e f1 1c 11 72 80 02 22 a0 e3 04 10 92 e5 08 30 9f e5 00 20 a0 e3 06 00 83 e8 1e ff 2f...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=15 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 0f f0 04 30 90 e5 0c 20 90 e5 00 40 a0 e1 02 00 53 e1 09 00 00 3a 00 30 90 e5 01 18 a0...
DEBUG:defib.protocol.hisilicon_standard:TX DATA silent timeout (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:TX DATA silent timeout (attempt 2/32)
DEBUG:defib.protocol.hisilicon_standard:TX DATA silent timeout (attempt 3/32)
DEBUG:defib.protocol.hisilicon_standard:TX DATA silent timeout (attempt 32/32)
DEBUG:defib.protocol.hisilicon_standard:TX DATA FAILED after 32 retries
Recovery failed: Failed to send SPL
  Sending DDR step ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:10
⠋ Sending SPL      ━━━━━━━━━━━━━━━━━━━━━━━         78% 0:00:07

Failed: Failed to send SPL

Is there a UART that you know works well with HiSilicon SoCs?

[AbidingOhmsLaw]

@openipc-ai

Looking at both the backup file I made and the openipc-hi3518ev200-lite-16mb.bin file, both have data. In both there are some large areas of FF but there is data before and after so I assume they are ok.

[AbidingOhmsLaw]

Found a different UART with a different cable and still have the same result

defib burn -c hi3518ev200 -p /dev/ttyACM0 -t --debug 2>&1 | tee defib.log
Firmware: u-boot-hi3518ev200-universal.bin (cached)
Protocol: HiSilicon Standard
Port: /dev/ttyACM0
INFO:defib.transport.serial_platform:Using standard SerialTransport for linux
Loaded profile: hi3518ev200
Using sendFrameForStart handshake for hi3518ev200
Sending 135452 bytes of firmware...
DEBUG:defib.protocol.hisilicon_standard:send_firmware: profile=hi3518ev200 firmware=135452 bytes spl_override=False
DEBUG:defib.protocol.hisilicon_standard:sendFrameForStart: blasting 0xAA+HEAD(64, 0x04013000) for 30s
DEBUG:defib.protocol.hisilicon_standard:sendFrameForStart: ACK after 37 blasts
DEBUG:defib.protocol.hisilicon_standard:=== PRESTEP0 === address=0x04013000 data=64 bytes
DEBUG:defib.protocol.hisilicon_standard:HEAD: length=64 address=0x04013000
DEBUG:defib.protocol.hisilicon_standard:TX HEAD (14 bytes): fe 00 ff 01 00 00 00 40 04 01 30 00 51 9c
DEBUG:defib.protocol.hisilicon_standard:TX HEAD ACKed (attempt 1/16)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=1 payload=64 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (69 bytes): da 01 fe 04 e0 2d e5 24 00 9f e5 24 10 9f e5 00 10 80 e5 20 00 9f e5 20 10 9f e5 04 10 80...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:TAIL: seq=2
DEBUG:defib.protocol.hisilicon_standard:TX TAIL (5 bytes): ed 02 fd ba b0
DEBUG:defib.protocol.hisilicon_standard:TX TAIL ACKed (attempt 1/16)
DEBUG:defib.protocol.hisilicon_standard:=== DDR STEP === address=0x04013000 data=64 bytes
DEBUG:defib.protocol.hisilicon_standard:HEAD: length=64 address=0x04013000
DEBUG:defib.protocol.hisilicon_standard:TX HEAD (14 bytes): fe 00 ff 01 00 00 00 40 04 01 30 00 51 9c
DEBUG:defib.protocol.hisilicon_standard:TX HEAD ACKed (attempt 1/16)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=1 payload=64 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (69 bytes): da 01 fe 04 e0 2d e5 24 00 9f e5 24 10 9f e5 00 10 80 e5 20 00 9f e5 20 10 9f e5 04 10 80...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:TAIL: seq=2
DEBUG:defib.protocol.hisilicon_standard:TX TAIL (5 bytes): ed 02 fd ba b0
DEBUG:defib.protocol.hisilicon_standard:TX TAIL ACKed (attempt 1/16)
DEBUG:defib.protocol.hisilicon_standard:send_firmware: rehandshake before SPL
DEBUG:defib.protocol.hisilicon_standard:rehandshake: waiting up to 5s for bootmode markers
DEBUG:defib.protocol.hisilicon_standard:rehandshake: got 0xAA, no re-handshake needed
INFO:defib.protocol.hisilicon_standard:SPL boundary detected (LZMA) at 0x4800 (18432 bytes); profile default was 0x3B00 (15104 bytes)
DEBUG:defib.protocol.hisilicon_standard:=== SPL === address=0x04010500 size=18432 chunks=18
DEBUG:defib.protocol.hisilicon_standard:HEAD: length=18432 address=0x04010500
DEBUG:defib.protocol.hisilicon_standard:TX HEAD (14 bytes): fe 00 ff 01 00 00 48 00 04 01 05 00 dd c6
DEBUG:defib.protocol.hisilicon_standard:TX HEAD ACKed (attempt 1/16)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=1 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 01 fe 17 04 00 ea 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f e5 14 f0 9f...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=2 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 02 fd 70 82 11 20 00 3f 00 00 00 00 00 00 7d 00 00 00 70 83 11 20 00 3f 00 00 00 00 00...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=3 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 03 fc d8 83 11 20 00 00 00 00 00 00 00 00 fd 00 00 00 1c 82 11 20 10 10 10 10 00 00 00...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=4 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 04 fb 44 00 11 20 00 10 00 01 00 00 00 00 fd 00 00 00 48 00 11 20 00 10 00 01 00 00 00...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=5 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 05 fa 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=6 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 06 f9 48 00 8d e2 34 50 8d e2 0e 10 a0 e1 0f 00 85 e8 0d 00 a0 e1 8c 0c 00 eb 00 00 a0...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=7 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 07 f8 20 a1 07 00 00 00 05 20 a0 86 01 00 02 00 52 e3 13 00 00 0a 81 13 80 e0 1c 22 91...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=8 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 08 f7 0a 30 a0 e1 07 10 a0 e1 09 00 a0 e1 01 50 85 e2 83 ff ff eb 04 00 55 e1 f5 ff ff...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=9 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 09 f6 10 d0 8d e2 f0 8e bd e8 38 20 9d e5 34 10 9d e5 0c 00 96 e5 cb ff ff eb 02 00 57...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=10 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 0a f5 01 00 7c e3 6a ff ff 1a 09 91 84 e0 14 b0 89 e5 94 b0 89 e5 0a 10 a0 e1 04 00 94...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=11 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 0b f4 00 00 05 20 50 c0 90 e5 ac c1 a0 e1 06 c0 0c e2 04 00 5c e3 04 c0 a0 23 00 00 5c...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=12 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 0c f3 00 00 54 e3 18 00 00 1a 14 10 9d e5 70 30 91 e5 01 26 83 e3 01 36 c3 e3 70 20 81...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=13 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 0d f2 a0 30 81 e5 ea ff ff 0a 8f 3f 81 e2 20 c0 8d e2 00 00 a0 e3 02 e0 a0 e1 00 10 9c...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=14 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 0e f1 1c 11 72 80 02 22 a0 e3 04 10 92 e5 08 30 9f e5 00 20 a0 e3 06 00 83 e8 1e ff 2f...
DEBUG:defib.protocol.hisilicon_standard:TX DATA ACKed (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:DATA: seq=15 payload=1024 bytes
DEBUG:defib.protocol.hisilicon_standard:TX DATA (1029 bytes): da 0f f0 04 30 90 e5 0c 20 90 e5 00 40 a0 e1 02 00 53 e1 09 00 00 3a 00 30 90 e5 01 18 a0...
DEBUG:defib.protocol.hisilicon_standard:TX DATA silent timeout (attempt 1/32)
DEBUG:defib.protocol.hisilicon_standard:TX DATA silent timeout (attempt 2/32)
DEBUG:defib.protocol.hisilicon_standard:TX DATA silent timeout (attempt 3/32)
DEBUG:defib.protocol.hisilicon_standard:TX DATA silent timeout (attempt 32/32)
DEBUG:defib.protocol.hisilicon_standard:TX DATA FAILED after 32 retries
Recovery failed: Failed to send SPL
  Sending DDR step ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
⠸ Sending SPL      ━━━━━━━━━━━━━━━━━━━━━━━         78% 0:00:09

Failed: Failed to send SPL

[openipc-ai]

Neither of those runs had the fix in them. Please don't change anything else about your setup
until you've done one run that does — everything below is secondary to that.

Here's the proof, from your own log. Both attempts contain:

INFO: SPL boundary detected (LZMA) at 0x4800 (18432 bytes); profile default was 0x3B00 (15104 bytes)
DEBUG: === SPL === address=0x04010500 size=18432 chunks=18

With the fix loaded those two lines read differently — exceeds SRAM limit 0x3B00; capping at SRAM limit, and size=15104 chunks=15. Yours still says 18432 and 18 chunks. That is the old defib,
unchanged, doing exactly what it did before. So "SPL still fails at the same spot" is expected —
nothing about the failing code path was different in those runs.

Most likely cause: your prompt shows an active virtualenv ((mike) mike@mike-debian:~$). The
install put the new defib in ~/.local/bin, but an active venv's bin comes first on PATH, so
the old copy inside the venv is what ran. Check with:

command -v defib

Anything other than /home/mike/.local/bin/defib and that's what happened.

The one command I'd like you to run. The fix is merged now, so no branch name needed, and this
form builds and runs it in a throwaway environment that cannot collide with anything installed:

uvx --refresh --from "git+https://github.com/OpenIPC/defib" \
  defib burn -c hi3518ev200 -p /dev/ttyUSB0 -t --debug 2>&1 | tee defib.log

Start it first, then power on the camera, same as before. Then check the two lines above the SPL
transfer:

INFO: SPL boundary detected (LZMA) at 0x4800 exceeds SRAM limit 0x3B00; capping at SRAM limit
DEBUG: === SPL === address=0x04010500 size=15104 chunks=15

If capping at SRAM limit isn't there, stop and send me the log anyway — the fix still isn't
loaded and nothing else in that run tells us anything. It's the only thing I need from you.

The rest of this is context, and a correction I owe you.

Your log proves the chunk-15 theory byte-for-byte

I said the failure would be chunk 15 crossing the end of SRAM. Your log doesn't just fail at chunk
15, it fails at the exact bytes I'd predict. Compare the payload previews to the U-Boot file:

seq=14  1c 11 72 80 02 22 a0 e3 ...   = file offset 0x3400   → SRAM 0x04013900..0x04013D00  ✅ ACKed
seq=15  04 30 90 e5 0c 20 90 e5 ...   = file offset 0x3800   → SRAM 0x04013D00..0x04014100  ❌ dies
                                                                                ^^^^^^^^^^
                                                          SRAM ends at 0x04014000, 256 bytes in

Both match the file exactly (I diffed them). Chunk 15 is the first write that goes off the end of
SRAM, and it's the one that dies. Fourteen chunks ACK on attempt 1/32 — first try, no retries,
no stray bytes — and then chunk 15 gets 32 consecutive silent timeouts.

I was wrong about what "silent timeout" means

In my last comment I told you stray 0x20 bytes meant a chip fault and silent timeouts meant a
cable problem. That was too neat, and it sent you off testing cables. Sorry.

0x20 is what you get when the boot ROM notices the problem and restarts cleanly. A write into the
boot ROM's own stack doesn't always leave it well enough to do that — often the chip just stops
executing, and a chip that has stopped executing sends nothing at all. Silence after a clean run
of chunks is a dead chip, not a dropped byte.

And your own testing rules out the cable better than my check would have:

• 14 chunks ACKed on the first attempt each, zero retries anywhere in the log
• 32 consecutive failures at the same chunk — a marginal link would ACK at least once in 32 tries
• same failure on /dev/ttyUSB0 and /dev/ttyACM0, two different adapters, two different
  cables, including a 6-inch one
• common ground already in place

A bad link fails at a different offset every run and scatters retries through the whole transfer.
Yours is clean until one specific address and then absolute. That's not a wire.

About the UART

Your adapter is almost certainly fine. It delivered 14 KB into a boot ROM without a single retry;
that is not the behaviour of a bad adapter. The auto-level thing would worry me more if the early
frames were flaky, and they're perfect.

For the record, if you ever do want a spare, a CP2102 or FT232RL with an explicit 3.3V jumper is
the safe default — see equipment-flashing.
Avoid PL2303 clones for HiSilicon work. But I wouldn't spend money on this evidence.

Good news on your backup

You said both files have real data with 0xFF regions rather than being entirely 0xFF. That's what a
healthy dump looks like — the 0xFF areas are just unused flash. So your vendor backup is probably
viable, which means defib restore stays open as a fallback if you'd rather go back to stock. Keep
that file somewhere safe.

What to send back

Just the log from the uvx command above — with capping at SRAM limit in it, or with a note that
it wasn't there. Nothing else needed, and no hardware changes in the meantime please; a new adapter
would only add a variable to a run we haven't done yet.

Assuming the fix loads, three ways it can go:

1. SPL reaches 100% over 15 chunks and you get an OpenIPC # prompt. Fixed — carry on with
   defib install.
2. SPL reaches 100%, then fails at the TAIL frame. The overflow is fixed but the shortened SPL
   isn't executing, which would put the problem in how we build the ev200 U-Boot rather than in
   defib. That's a real finding and I'd open it upstream.
3. Still dies at chunk 15, with capping at SRAM limit present in the log. Then my ceiling
   number is wrong and I'll rethink it.

All three are useful to us. The one outcome that tells us nothing is another run of the old build.

If you'd rather stop poking at this, the 16 MB NOR chip can also be written directly with a CH341A
clip — slower to set up, but it bypasses the boot ROM entirely. Say the word and I'll write that
route up.

[AbidingOhmsLaw]

I am using venv so it was running the old one, I copied the new version into my venv.

Ran the uvx command after getting the correct version of defib, it completed and gave me a "Done!" message But I did not get a OpenIPC# prompt it went back to the "System startup" issue

The SPL boundary messages are there exactly as you showed above.

Here is the log

defib.log

[AbidingOhmsLaw]

As for the direct write to NOR via the CH341A. I'm keen to keep poking at this if it helps OpenIPC but nice to know there is a back up. Also I have 3 of these cameras and 2 are virgin, so if we totally brick this I got a couple more. I have macro pictures of the chips on the MB they sandblasted the HiSilicon chip but you can still make out some of it.