| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Decode and packetize the Biphase Mark Coding (aka differential Manchester)
as used in the Universal Serial Bus Power Delivery Specification Revision 2.0
v1.1, then decode the packet content.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
|
|
(this PD is indeed stacked on top of SPI)
|
|
|
|
1. Show Frame Error on the Start bit
2. Don't overwrite framing errors with (valid) start/stop bit info
|
|
The new decoder stacks on top of the usb_packet PD. It adds one new
annotation row, and is able to save the decoded data as PCAP trace.
It has been successfully tested against all traces in sigrok-dumps and
some more traces.
|
|
|
|
|
|
USB low/full speed allows for frequency tolerance of 1.5%/0.25%. At
maximum packet size (sync + PID + data + CRC16) of 12 bytes/1027 bytes
this amounts to 1.4 bits/20 bits, so the decoder has to lock to the
actual symbol frequency to avoid any symbol misdetections.
The signal is sampled twice, once at the symbol center and once at
the expected edge position. Comparing the symbol at both positions gives
an indication if the current bit width is too low or too high. Adjust
accordingly.
|
|
In case CRC validation fails, an crc5-err/crc16-err annotation is issued,
instead of crc5-ok/crc16-ok, and the error is noted in the annotation
text.
|
|
There is a small typo in the rfm12 protocol decoder that I just noticed:
|
|
It seems the Python we ship along our Windows binaries does not
support u"..." strings, even though it's been a language feature
since Python 2. Remove the "u" prefix to avoid a syntax error.
Also, consistently use format "%.1f" at all scales.
This fixes bug #569.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The STM32F10xxx has two serially connected JTAG TAPs, the boundary scan tap
(5 bits) and the Cortex-M3 TAP (4 bits). See UM 31.5 "STM32F10xxx JTAG TAP
connection" for details.
Due to this, we need to ignore the last bit of each data shift (and we
currently ignore the 5 bits of the boundary scan tap).
|
|
The code was previously not decoding a bit for the first state change
to SHIFT-IR/-DR, which was incorrect.
|
|
|
|
The buttons are pressed if the respective bit is 0.
|
|
|
|
Instead of showing raw values in the annotations, calculate the
actual voltage (based on raw value, gain, and Vref) and use that.
|
|
|
|
- If LOAD goes low *and* LDAC is already low, the voltage is set
immediately.
- If LOAD goes low but LDAC is high, the value is only written into
an internal register, but the voltage is not changed (yet).
- If LDAC goes low, all four DAC voltages (DAC A/B/C/D) are set
according to the respective register values at the same time.
|
|
|
|
|
|
Previously the PD was blindly trying to decode any packet, no matter
whether it was too short (and/or bogus) or not, causing issues like this:
srd: Calling usb_packet decode(): IndexError: list index out of range
Such cases of invalid input are now handled better by emitting "UNKNOWN"
and "Invalid packet" annotations.
This fixes bug #186.
|
|
Thanks to Pavel Sukortsev for the bug report and fix.
This fixes bug #623.
|
|
In the current state the decoder can decode the following commands:
CMD0, CMD2, CMD3, CMD6, CMD7, CMD8, CMD9, CMD10, CMD13, CMD16, CMD55,
ACMD6, ACMD13, ACMD41, ACMD51.
Other commands (and more details for existing commands) will be added later.
|
|
|
|
|
|
|
|
|
|
|
|
No interpretation of register bits, nor attempting to decode packet contents,
but all shifted register addresses and long register memory regions are
decoded.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
|
|
|
|
Decodes reads/writes of registers. Understands resetting on chip select if
provided. Does not understand burst mode.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
|
|
Include their compatibility in the dropdown options too.
|
|
|
|
|
|
|
|
This is in preparation of making the PD more generic so it can support
a lot more xx25 series SPI (NOR) flash chips.
|
|
|
|
The code was trying to emit annotations before
self.register(srd.OUTPUT_ANN) was run.
This fixes bug #357.
|
|
Avoid decoding and outputting data from the SPI bus if the CS pin
hasn't been asserted. This avoids confusing both users and stacked
decoders which otherwise end up seeing traffic intended for other
chips (or just noise).
Note: The old behavior of decoding all traffic is still in place if
no CS pin has been wired up to the decoder.
This fixes bug #559.
|
|
|
