I am trying to get a UART on a Dahua DH-IPC-HDW3666EMP-S-AUS however the output I'm getting seems very different to the other posts here on the forum.
I located the four pin UART connector and have figured out which pins are TX (data from device), GND and +3.3V, however when I power up the device I see DH-Boot instead of U-Boot:
Holding down any keys (space, *) while powering on the device has no effect. There is no Linux console after the above messages either.
The only thing that's odd is that I am getting my keypresses echoed back to me even when the device is powered off. I've only seen this before when the TX and RX lines are shorted, however checking them with a multimeter shows they are not connected. So I'm not quite sure what's happening there. It happens regardless of the baud rate I set so it looks like an electrical issue rather than a software/configuration issue. Often once the device boots the characters no longer echo back the same, and come back as boxes (extended characters) which suggests some kind of electrical interference.
I've tried with two USB to UART devices (one based on PL2303 and another on ARK3116) and they both behave the same way.
Has anyone else gotten a UART on one of these more recent devices (ones with the new web UI I guess) and if so, what kind of behaviour did you see?
I located the four pin UART connector and have figured out which pins are TX (data from device), GND and +3.3V, however when I power up the device I see DH-Boot instead of U-Boot:
Code:
$Tch SpiNand
Load 0x00000080 to 0x00100000,size=30332
Key hash pass!
Imgsign pass
Jmp 0x00100000
Info: write leveling start
Info: write leveling done
Info: dqs gating start
Info: dqs gating done
Info: read train start
Info: bypass read train done
Info: write train start
ddr init done
simple ddr test
swap
ddr_clk: 599500
cpu_clk: 1000000
enc_clk: 400000
DDR32bit done!
B: Nov 8 2022 22:05:30
chip id is 0x0x7FB3804C
mac io keep 3.3v
PreImgHeaderBase = 0x0010FE78
SpiNand : Scan Uimg @0x00100000
use 2 plane to read
Load 0x00100040 to 0x12000000,size=220784
rdbuf 131072 131072
SMC_loadPartition ReadPage ret 0
SMC_init crc done, start_addr 0x00200000 size 0x0000159C crc 0x0459CD82
SmcReadNandID id = 0x7F7FE4A1
SMC_nandInit set Fudan-Micro FM25S01A, id 0x000000A1 0x000000E4
SMC_init done
Jmp 0x12000000
DH-Boot ver001.001.001-svn10383 (Nov 08 2022 - 22:05:05 +0800)
SMC_init nand Fudan-Micro FM25S01A, id 0xa1 0xe4
SMC_init done
NAND Flash Init.
SMC_getNandInfo nand Fudan-Micro FM25S01A
id=0xa1 e4
id_cnt=2
spare_size=64
page_size=2048
page_cnt=64
blk_cnt=1024
plane_cnt=1
bits_per_cell=1
luns_per_target=1
ntargets=1
ecc_bitlen=1
ecc_perlen=512
ecc_addr=0xc0
ecc_bitmask=0x30
ecc_errmask=0x20
rx_width=4
tx_width=1Holding down any keys (space, *) while powering on the device has no effect. There is no Linux console after the above messages either.
The only thing that's odd is that I am getting my keypresses echoed back to me even when the device is powered off. I've only seen this before when the TX and RX lines are shorted, however checking them with a multimeter shows they are not connected. So I'm not quite sure what's happening there. It happens regardless of the baud rate I set so it looks like an electrical issue rather than a software/configuration issue. Often once the device boots the characters no longer echo back the same, and come back as boxes (extended characters) which suggests some kind of electrical interference.
I've tried with two USB to UART devices (one based on PL2303 and another on ARK3116) and they both behave the same way.
Has anyone else gotten a UART on one of these more recent devices (ones with the new web UI I guess) and if so, what kind of behaviour did you see?