LD2402 Firmware v3.3.5 — Manual Save-to-Flash (0x00FD) Fails for Parameter 0x003F When Set via 0x0007

Viewed 30

Module: HLK-LD2402
Firmware: v3.3.5 (confirmed via command 0x0000, "Read firmware version")

Issue
Parameter 0x003F (Gate 15 micro-motion threshold) writes successfully via command 0x0007, updates the live operating value, and reads back correctly. But the save-to-flash command (0x00FD) fails every time 0x003F was set via the manual 0x0007 command. Notably, this address can be persisted to flash — a value set via the automatic threshold generation command (0x0009) for this same parameter survives a power cycle correctly. The failure is specific to the manual set-then-save (0x0007 -> 0x00FD) sequence for this one address, not a general inability to store it in flash.

Reproduction

  1. Enter config mode (0x00FF).
  2. Write parameter 0x003F via command 0x0007.
  3. Read back 0x003F (0x0008) -- new value confirmed active.
  4. Send save command 0x00FD.
  5. Module returns Save Failed -- a fast, explicit rejection (~4s), not a timeout or dropped response.
  6. Exit config mode (0x00FE).

Control test A -- same procedure with parameter 0x001F (Gate 15 motion threshold), or any other gate threshold: save succeeds, value persists across power cycle.

Control test B -- a value for 0x003F set via automatic threshold generation (command 0x0009) persists correctly across a power cycle, confirming the address itself supports flash storage.

Confirmed

  • Write to 0x003F via 0x0007: succeeds
  • Read-back of 0x003F: correct
  • Manual save (0x0007 -> 0x00FD) with only 0x003F pending: fails
  • Manual save with 0x003F + 0x001F pending together: fails
  • Manual save with any other parameter, including all Gate 0-14 thresholds together: succeeds, persists
  • A value for 0x003F set via 0x0009 (auto threshold generation) persists correctly across a power cycle

Not yet tested

  • Save with 0x003E + 0x003F pending together via 0x0007
  • Save after restoring 0x003F to factory default via 0x0007

Reproducibility: 100% for the manual set-then-save failure -- reproduced across multiple independent test runs and gate combinations. Deterministic, not intermittent.

Root cause assessment: UART transport, protocol implementation, and the RAM write path all function correctly. The defect appears isolated to the manual parameter-save routine's handling of address 0x003F specifically -- since the same address is provably writable to flash via the automatic threshold generation command, this looks like a difference in how the two code paths (0x0009's internal commit vs. the explicit 0x0007 -> 0x00FD sequence) handle that particular parameter ID, consistent with an address-range/boundary check present in one path but not the other.

Ask: Please confirm whether this is a known issue, and whether a firmware update exists that resolves it.

Firmware update request

If a firmware revision newer than v3.3.5 exists that addresses this (or any other) known issue with the LD2402's parameter save routine, please share the update file and any release notes/changelog covering the fix. If v3.3.5 is the latest available, please confirm that as well so we know not to keep looking for a newer build.

2 Answers

Just use 0XFD to save instructions, no need to use 0X3F instructions anymore

Gate 15 parameter save (0x003F) — both suggested fixes retested and reproducibly fail

Thank you for the two follow-up responses. Since they gave two different, mutually exclusive answers, I tested both directly against real hardware (firmware v3.3.5, confirmed via 0x0000) rather than assume either was correct. Results:

Test 1 — "Just use 0xFD normally, no need for 0x3F handling":
Entered config mode, wrote parameter 0x003F via 0x0007 alone (no special sequence), sent 0x00FD. Result: write succeeds (confirmed via immediate read-back), but 0x00FD is explicitly rejected — same fast (~4s) rejection as originally reported. 100% reproducible.

Test 2 — "Write gate 14 (0x003E) + gate 15 (0x003F) together in one 0x0007 frame, then one 0x00FD":
Same result. Both values write to RAM correctly (confirmed via read-back), but the single 0x00FD is still explicitly rejected.

What does work, verified across a real power cycle: set 0x003F via 0x0007, wait ~200ms, read it back via 0x0008, set the same value again via 0x0007, then exit config mode (0x00FE) without ever calling 0x00FD. This is not documented anywhere I've been given, but it's the only procedure that has ever actually persisted the value through a power cycle.

Given two different official explanations have now both failed empirical testing, I'd like to ask directly:

Is there an internal engineering explanation for why 0x00FD specifically rejects a pending write to 0x003F, that doesn't match either explanation given so far?
Is the read-back-then-rewrite-then-exit-without-saving procedure above actually the documented/intended one, or did I arrive at an unintended workaround for a real bug?
Given the OTA file bundled with your config tool (2402_335_OTA.bin) matches our module's version exactly, can you confirm there is no newer firmware in your internal pipeline that changes this behavior?
Happy to provide a raw byte-level capture of the working sequence if that helps engineering reproduce it on your end.

There are no restrictions on the two instructions, both can be used. Can you please check which instruction was sent specifically?