Qubo Dash Cam Pro X Stuck During Boot: SigmaStar SSC335R + W25N512GV SPI NAND

[Marcus3235]

Note: I am not a professional electronics/embedded engineer. Everything I've done so far has been learned through YouTube videos, datasheets/forums, and guidance from AI. I've been proceeding cautiously, measuring and documenting each step, and have deliberately avoided writing/erasing the NAND or making irreversible changes.

Qubo Dash Cam - SigmaStar SSC335R stuck at "Load BL from SPINAND"

Hi,

I'm trying to recover a Qubo dash camera that stopped booting. Qubo support told me the unit has gone bad and recommended replacing it, so I'm investigating the board and would appreciate some help from anyone familiar with SigmaStar/SPI NAND recovery.

Symptoms

When powered from a USB charger, power bank, or car USB port:

- Red LED flashes briefly.
- It then becomes solid red.
- Camera never boots.
- Holding the power button makes the LED disappear, but releasing it makes the red LED return.

Hardware identified

Main SoC:

SigmaStar SSC335R
STAR
SSC-335R
AM-315-298
232-88
ARM

SPI NAND:

Winbond W25N512GVEIG
WSON-8, approximately 8 x 6 mm

Other chips:

Realtek RTL8188FTV
IP6303 PMIC

There is also a microSD slot used for recordings.

UART

I found four test pads labelled:

R  T  V  G

Using a DT830D multimeter:

VBUS → GND = 5.02–5.03 V
V → G     = 3.35–3.37 V
R → G     = 3.25–3.26 V
T → G     = 3.25–3.26 V

I connected an FT232 USB-UART adapter at 3.3 V.

The working connection is:

Qubo T → FT232 RX
Qubo G → FT232 GND

R → RX produces no output.

UART settings:

115200 baud
8-N-1
No flow control

Full clean Tera Term boot output

This is the complete useful output I consistently get:

IPL g4b89453
D-15
SPI 54M
64MB
BIST0_0001-OK
Find CIS in block00
SPI 86M & SPI_CK driving
Load BL from SPINAND
Checksum OK

IPL_CUST g4b89453
Find CIS in block00
SPI 86M & SPI_CK driving
Find CIS in block00
SPI 86M & SPI_CK driving
Load BL from SPINAND

It remains at:

Load BL from SPINAND

indefinitely. I left it for approximately 7 minutes without any further useful output.

I also tried 921600 baud, but that produced no useful output. 115200 gives the clean boot log above.

What I have verified

The SSC335R is clearly executing IPL.

DDR appears to pass:

BIST0_0001-OK

The NAND is detected and the bootloader finds its CIS:

Find CIS in block00

The first loaded image reports:

Checksum OK

The NAND remains powered while the system is stuck:

Pin 8 VCC ≈ 3.35–3.37 V
Pin 3 /WP ≈ 3.36 V
Pin 7 /HOLD ≈ 3.36 V

I also checked the SPI pins against GND with the board unpowered. No obvious short was found on:

Pin 1 /CS
Pin 2 DO
Pin 5 DI
Pin 6 CLK

Programmer

I have a CH341B programmer and NeoProgrammer.

NeoProgrammer recognizes:

W25N512GV
3.3 V
512 Mbit
SPI_NAND
2048-byte page

The CH341B's 3.3 V output measures 3.29–3.30 V.

I have NOT connected the CH341B to the Qubo NAND yet, and I have NOT erased or written anything.

I also have a generic SOIC-8 clip, but it is not suitable for this WSON-8 package. I'm considering getting a proper WSON-8 8 x 6 mm probe/clip.

My current theory

The board is not completely dead. It gets through:

IPL
 ↓
DDR BIST
 ↓
CIS detection
 ↓
Load BL from SPINAND
 ↓
Checksum OK
 ↓
IPL_CUST
 ↓
Load BL from SPINAND
 ↓
HANG

I'm wondering whether the second-stage bootloader is corrupted or whether there is a NAND/ECC/bad-block/read issue.

I'm particularly interested in understanding exactly what SigmaStar means by "Load BL from SPINAND" at the IPL_CUST stage.

Questions

1. Does this log indicate that IPL_CUST is hanging while reading/loading the next bootloader from SPI NAND?

2. Could NAND ECC, bad blocks, or corrupted data cause this exact behavior?

3. What does the earlier "Checksum OK" actually validate?

4. Is there a known SigmaStar SSC335R bootloader/recovery process for this IPL/IPL_CUST format?

5. Can the W25N512GVEIG be safely dumped in-circuit with a CH341B?

6. Does the SSC335R need to be isolated from the NAND before connecting an external programmer?

7. If dumping it, should I preserve the NAND spare/OOB area as well as the 2048-byte data pages?

8. Are there SigmaStar tools or methods for inspecting/recovering the bootloader from this type of SPI NAND?

My priority is to make a complete backup of the original NAND before attempting any repair or reflashing.

Thanks in advance to anyone who can help interpret the boot log or suggest the safest next diagnostic step.

[CapLeaker]

Did it show some ailing signs or weird behaviour before this? There are many dash cams across different brands specially the past 5 or 6 years ago that do just that.
in Order to test the NAND you have to take it out, copy its contents, then write it full and write it full again and check. Is the battery or super capacitor still working?