The Feasycom BT1035 programming user guide's own pin table (§2.2, pin
34 SYS_CTRL) reads "Delay 100ms, pull high" -- the previous reset
sequence here asserted SYS_CTRL high at the very same instant as
RESET, with zero lead-in delay, racing the module's own documented
power-on requirement (the datasheet's §4.7 separately confirms
SYS_CTRL must be asserted >20ms before internal regulators even start
powering up). Rewrote resetAndInitOnce() to hold both pins low for a
100ms lead-in matching the guide exactly, then bring SYS_CTRL high,
then an extra 50ms settle margin before releasing RESET into a module
that's had a chance to actually power up first.
This is verified correct against the manufacturer's own documented
timing and is worth keeping regardless of its effect on any one
symptom, but it does NOT fully explain this project's intermittent
BT1035 boot failures ("no spontaneous UART bytes after hardware
reset"): a deep investigation session confirmed the same failure
still occurs, at the same rate, across genuine physical power cycles
(not just soft resets) with this fix applied, extended UART listen
windows (tested up to 10s vs the normal 3.5s), and independently
schematic-verified-correct GPIO pin assignments, UART TX/RX wiring,
AT command bytes, and shared 3.3V regulator sizing. Unlike the
Si4684 ARG1-offset bug earlier this session -- which failed 100% of
the time, deterministically, from a real code defect -- this failure
is non-deterministic across identical power-on sequences with
identical code, which does not match a firmware logic-bug signature.
Root cause remains open; see docs/si4684-rf-investigation-report.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0178rASQ6ZETPMUamvpoR2KR
micheleandClaude Sonnet 5
b675d985c9