Fix PeakCAN listen-only configuration - #1104
Open
RMBmd wants to merge 1 commit into
Open
Conversation
Author
Hardware validation: PASSThe PeakCAN native listen-only fix has been compiled and validated on physical hardware. SavvyCAN commit: Results
Additional findings
ConclusionHardware testing confirms that the patch correctly configures and verifies native PCAN-Basic listen-only mode. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fix the Qt
peakcanconnection so that selecting Listen Only in SavvyCAN places the PEAK CAN controller into genuine hardware listen-only mode.SavvyCAN currently encodes listen-only as bit 0 of
QCanBusDevice::UserKey. The Qt PeakCAN backend does not consume that custom key, so the connection can still be initialized in normal active mode even though the SavvyCAN UI shows Listen Only.An active CAN controller can acknowledge frames and emit active error flags even when the application does not intentionally transmit CAN frames. This makes the existing behavior unsafe for passive capture and can interfere with timing-sensitive diagnostic or programming operations.
Observed behavior
The issue was identified with the following setup:
This indicates that SavvyCAN's listen-only selection is not reaching the native PEAK controller configuration.
Root cause
SavvyCAN currently performs the following configuration: