The ESP keeps its negotiated UART baud (921600) across a bootloader round
trip, hw reset or flash, while the AT32 restarts at the boot baud (460800)
and its baud-set request is then garbage to the ESP. The link stayed at
460800 and every BWM command failed until the module lost power.
Probe GET_UART_BAUD at both rates on boot and adopt the one the ESP answers
at; only run the set-baud handshake when it really is at the boot baud.
The critical-shutdown path in bwm_lowbatt_check() was reached whenever the
AW32001 System Status "power good" bit was clear. On this hardware that bit reads
"power fail" even while the board is USB-powered under HF load (hw status shows
power fail + ~400 mA discharge on PC USB), so a low pack could trip the latched
power-off - Gpio_ARM_Power_ON_Low() + while(1) - while USB keeps the MCU alive,
leaving it spinning.
Confirm the cable really is out via the dedicated VUSB sense pin (Gpio_VUSB_Read,
the same source WITH_PM5_AUTOOFF uses) before powering off; if USB is present,
clear the streak and keep running. Also print a reason before cut-off, and fix a
brace/formatting glitch on the trigger condition.
The idle-loop low-battery poll bwm_lowbatt_check() reads the BWM charger/gauge
over the bit-banged I2C, which busy-waits on the TMR5 free-running counter via
WaitUS()/WaitTicks(). A command handler that runs just before the poll can leave
TMR5 stopped through StopTicks() - notably the LEGIC probe in `hf search`
(LegicRfInfo() ends with switch_off(); StopTicks()). WaitTicks() then spins in
`while (GetTicks() < ticks)` forever and the device appears to hang, needing a
manual power-cycle, because WDT_HIT() is a no-op on AT32.
This became reachable by default at d35ddce2 (PM5 gained -DWITH_BWM_LOWBATT_BEEP).
The previous idle-loop I2C user, the power LED, was unaffected because RgbLedSet()
calls StartTicks() first. Do the same in the poll.
Both psk3 entries run the same demodulation as the psk2 entry beside them and
differ only in the constant given to test(). test() accepts a word only when
that word's own modulation field matches the constant, so the psk3 entry needs
a recovered word whose field reads 3.
Field 3 is 00011, so it needs two adjacent 1's. What this demodulation recovers
is the data's rising edges, and a rising edge needs a 0 before the 1, so no two
of them are ever adjacent. The words it produces can never carry field 3, and so
the psk3 entries can never match the case they were written for.
What they can do, however, is match on a demodulation error, and then detect
names psk3 and a block 0 word the tag does not hold.
psk3 is still reached, by ruling psk2 out from the broadcast period rather
than by demodulating for it - see t55xx_psk3_resolve().
Tags that only these branches matched now read as psk2, or as undetected
where no offset yields a plausible psk2 word, on the basis that a wrong
answer is worse than none if nothing about it tells you it is wrong.
Edited by a human.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The client demodulates psk2 and psk3 the same way, and against a psk3 tag
that demodulation keeps only the leading bit of every run of ones. A psk3
config word therefore always reads back as its psk2 neighbour, one bit out,
and detect structurally cannot tell the two apart from the waveform alone.
It said psk2 anyway. Worse, the data-block probe meant to settle it
confidently answered psk3 even for a freshly wiped psk2 tag, where a page
of zeroes has no adjacent ones under either modulation.
Report what is actually known:
- print "PSK2 or PSK3 ( ambiguous )" when the read fits both
- list the words block 0 could be, rather than printing one and relegating
the rest to a note
- weight the probe's evidence, so empty blocks settle nothing
- narrow that list with things the tag cannot hide - the subcarrier it
transmits on, and how many blocks it broadcasts, which constrains MAXBLK and
also rules out the sequence terminator
Where that leaves one word, block 0 reports it. Where it does not, detect
says so rather than choosing.
Edited by a human.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Niel Nielsen