L9965A/L9965T FPGA HIL: CRC10, wake/fault tones and reset reply semantics
Hello ST team and community,
ST Online Support recommended asking here after reviewing the product documentation. I am developing a battery-management hardware-in-the-loop (HIL) prototype and would appreciate authoritative protocol details and guidance on the remaining chip behaviors.
Project context
An Arty Z7-20 FPGA models ten independent 16S battery modules and ten logical L9965A CMUs, split across two VIF endpoints with five CMUs each. An STM32H753 is the external controller, communicating through real L9965T transceivers and a planned external isolated receive/drive front end. The FPGA is not connected directly to the analog ISO pins and does not replace the L9965T. Physical interoperability testing is still pending while hardware is being assembled.
Implemented and tested in simulation: NORMAL-mode 40-bit single reads/writes, global/selective broadcasts, enumeration, standard cell-voltage bursts and CRC6 checked against ST's firmware calculator. The CMUs also implement coherent conversions and native cell UV/OV thresholds and latched flags. This is a functional subset, not complete chip emulation or hardware qualification.
Documents reviewed: L9965A/L99BM218 DS15021 Rev 2 (February 2026); L9965T DS14987 Rev 3 (July 2026); AN6387 Rev 3 (October 2026); UM3628; and STSW-L9965FW v1.0.0. Community searches have not located a confirmed answer to the following.
1. Compressed-burst CRC10 — missing verified wire definition
DS15021 section 5.10.2.3/Table 62 describes compressed packet fields and a 10-bit CRC. Where are its polynomial, initialization, shift direction/reflection, final XOR, covered-bit sequence, padding and transmitted bit order specified? Please clarify FAULT/status coverage and interaction with CRC6. Could ST provide complete transmitted compressed packets of at least two lengths, including expected CRC10 values? The host driver's decompression helper appears to process values after L9965T decoding; it does not establish the on-wire CRC10 calculation.
2. Short/long VIF tones — missing numerical waveform definition
DS15021 Table 63 and DS14987 sections 5.8.3.7–5.8.3.8 describe wake/fault/cyclic tone reactions. What are the exact zero-bit counts, bit rates, pulse cadence/polarity, receiver tolerances, idle/termination rules and repetition/recovery timing? Please clarify detection and forwarding during an ordinary frame, chain wake from DEEPSLEEP/CYCLIC_COUNT and fault/cyclic tone generation. The stated wake propagation latency does not appear to define the tone itself. Please distinguish these waveforms from the MCU's SPI wake command and cyclic scheduling interval. We have not assumed that an ordinary 40-bit all-zero frame is a valid tone.
3. Address-changing writes and software reset — immediate answer semantics
If an addressed write changes VIF_ID from 2 to 7, does its immediate answer use old ID 2 or new ID 7? After the second software-reset key (0x1E following 0xE1), does the device answer using its old ID, reset ID 0, or not answer? When do reset side effects and forwarding gates take effect relative to the answer? The host write helper does not appear to validate the returned device ID, so that alone does not settle this question.
4. Remaining documented chip functions — reference and conformance guidance
These functions are on our implementation backlog; we are not claiming they are undocumented. Are there recommended application notes, reference transactions, expected register traces or conformance tests covering:
- balancing commands, PWM/timers, fault inhibition/resumption and silent balancing;
- GPIO/NTC temperature acquisition, busbar/VBS and sum diagnostics;
- watchdog expiry, GO2SLP/deep sleep, cyclic wake, retained configuration and reset domains;
- ADC redundancy, gain adjustment, BIST/EIS and diagnostic fault reporting;
- NVM operations, configuration CRC/ECC and failure/status behavior;
- SPI/I2C controller peripherals and their observable register behavior?
We can build behavioral models from the published descriptions, but would like independent expected sequences/results, particularly for firmware initialization and recovery. Which self-tests/status checks does ST's recommended startup sequence require before normal voltage acquisition? Is there a complete register/reset/retention and timing reference beyond the public datasheet and firmware package?
5. Custom endpoint and physical interoperability
Are there supported reference circuits, electrical test procedures, silicon-revision errata or known-good captures for an FPGA VIF endpoint communicating with a real L9965T? In particular, guidance on driver release/turnaround, coupling, receive thresholds and timing margins would help our planned hardware qualification.
If additional VIF specifications or conformance vectors require restricted access or an NDA, please identify the document and access process. Answers to individual questions are welcome; exact document sections or known-good bit sequences would be especially helpful. We can provide concise repository-owned simulation traces, clearly labeled as simulation, without posting licensed ST firmware source.
References:
https://www.st.com/en/power-management/l9965a.html#documentation
https://www.st.com/en/power-management/l9965t.html#documentation
https://www.st.com/en/embedded-software/stsw-l9965fw.html
Thank you.