Created attachment 725 [details] Reading word 0xf with command 0x86 I have been investigating some Catalyst CSI24C44P memory to achieve some routines in pic assembler and I'm helping myself with pirate and OLS, as software I use pulseview and my OS is gentoo ~amd64. Using pulseview with 4 channels of OLS to capture CE SK DI DO from CSI24C44P memory, with capture trigger high on CE line. All other commands work fine except READ 0x86 and 0x87. Instead of reading the D0 bit after clock pulse 8 it apparently reads it from the first clock tick. The memory is new and was recorded with rising values to facilitate testing. Use the TL866II programmer that supports it. Read in byte mode. $ minipro -p X24C44 -r- |hexdump -Cv Found TL866II+ 04.2.124 (0x27c) Reading Code... 0.01Sec OK 00000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................| 00000010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f |................| Read in word mode. $ minipro -p X24C44 -r- |hexdump -v Found TL866II+ 04.2.124 (0x27c) Reading Code... 0.01Sec OK 0000000 0100 0302 0504 0706 0908 0b0a 0d0c 0f0e 0000010 1110 1312 1514 1716 1918 1b1a 1d1c 1f1e In the attached capture, I read with the command 0x86 the last word 0xf whose value should read 0x1e 0x1f. I have used the 3WIRE mode of the pirate with the following command. 3WIRE[-/\-/\-/\-/\-/\-/\-/\_/\./\./\./\./\./\./\./\./\./\./\./\./\./\./\./\.] Greetings.
Have trouble reading the Xicor x24c44 datasheet, it appears to disagree with itself in the read command's description and illustration, and in the timing diagram. The protocol decoder's author provided captures which assume three eight-bit runs for the read command, but unfortunately did not provide a README with the captures so that his setup is unknown. Can you please provide the captures of the read operations (not screen images, but the recorded data) so that others can reproduce the issue? See other sigrok-dumps/ directories outside of spi/x2444m/ for typical docs. Would also be good to get more coverage on other commands than just write and read as of now. Can you either reference a better protocol description (less ambiguous, or more illustrative), so that the decoder's documentation can get improved? And can you contact the PD author about the read command length confusion? If the PD author's traffic is correct, that'd suggest that there are several kinds of x2444 protocols, which need to be told apart when the decoder is used. If the PD author's traffic is incorrect, and the instruction "byte" of the read command does not span 8 bits but only 7, then the x2444 decoder cannot stack on top of SPI. Your screen capture illustrates how the first data byte is warped, and the second won't decode since "it's incomplete". Fixing that (assuming that the protocol uses an odd 7bit length for one of its "bytes" would involve heavier surgery to the decoder implementation than simply shifting one bit. And who would even design such a protocol? This is strange.
Created attachment 726 [details] sigrok captures
First of all thank you for your answer :) Both Xicor and Catalyst in their datasheets indicate this perfectly and I have not read wrong. In the CAT24C44.pdf file on sheet 5 and in the Read section it reads: ////////////////////////////////////////////////////// Read ... ... When clocking data from the device, the first bit clocked out (DO) is timed from the falling edge of the 8th clock, all succeeding bits (D1–D15) are timed from the rising edge of the clock. ////////////////////////////////////////////////////// In the file X24C44.pdf on sheet 2-8 and in the READ section it reads: ////////////////////////////////////////////////////// READ ... ... D0, the first bit output during a read operation, is truncated. That is, it is internally clocked by the falling edge of the eigth SK clock; whereas, all succeeding bits are clocked by the rising edge of SK (refer to Read Cycle Diagram). ////////////////////////////////////////////////////// Xicor did so to deliberately get out of the standard. In both datasheets, in the READ diagrams, the 23 clock pulse corresponds to the reading of bit D15. So only with the read command 0x86 or 0x87 are needed 23 clock pulses and not 24 as with the write command 0x83. Therefore, it is not that the first byte has 7 bits, but that the D0 bit clocked with the drop of the eighth clock pulse, that's what it does that only 23 clock pulses are needed instead of 24 as it would normally be. Another difference is that while in 93xx memory the first bit obtained is the MSB D15 in these 2444 is on the contrary, the first bit obtained is the LSB D0 and that is also not being respected by the x2444m plugin. As seen in the write capture [0x83 0x1e 0x1f] it is being interpreted inverted and is noted as 0x78 0xf8, the same happens with the reading, is interpreting inverted. I attach a zip with the requested data captures and other useful data. Greetings.
Doesn't matter in which words it gets put. Whether the instruction "byte" ends after 7 bits, or whether the 16bit response overlaps with the 8bits instruction. Either phrasing results in an odd number of bits for the total frame: 23bits. Which is unexpected but can be by design as you mention. Did not want to "take away" from you that this is the protocol spec, just wanted to make sure that the difference between the previously submitted decoder implementation and the example capture gets inspected and evaluated. And if the decoder implementation is not correct, of course it needs to get fixed. There is no doubt about it. The endianess is just a matter of configuring the decoder. The defaults may not be suitable out of the box. That's a result of the stacking. Easy enough to adjust after assigning the decoder. Most SPI communication is MSB first, hence the default.
If the bit order of the X2444M/P decoder is changed to LSB, it is reversed for everything, data and commands, but the commands are in MSB and they show well, the data is in LSB and they show bad. I have sent an email to Stefan who is the one appears as the author in the header of the file /usr/share/libsigrokdecode/decoders/x2444m/pd.py, still not responding. I handle the memory without problems by sending the commands and forms indicated on the datasheets. I was only interested in that sigrok improve and be faithful so that it does not confuse no one who is going to use it. If I knew a little more about the context of the plugins, I would put myself in the task of modifying it. Thanks a lot Greetings.
OK, so the protocol design is "so interesting" that instructions are MSB first and their parameters or payload data is LSB first, and READ instruction length is shorter than any other instruction, or READ responses start already while the READ instruction still is being received? The initial PD author seems to not have been aware, but this can get fixed. Your use of an external programmer and your comparison to the vendor spec raise the certainty about the current PD implementation's being incomplete or incorrect. There are two alternatives: To not stack x2444m on top of SPI, and re-invent the parts that previously were provided by SPI. Or keep stacking on top of SPI but process BITS instead of DATA input (in addition to CS-CHANGE). In that case the SPI decoder needs to emit BITS as soon as they become available, not late when DATA gets emitted as in the current implementation. And x2444m needs to re-invent bits to bytes accumulation, but that is easy with Python and the common bitpack support which also supports different endianess. Not saying that you have to do this, unless your interest is strong enough to make it happen, and help yourself as well as other users. Just putting the information here for whoever takes that task. If you are interested, see what other decoders do for protocols that you are familiar with. Many idioms can be picked up that way. See e.g. sle44xx, parallel, or similar. See what spi exports (there is a huge comment at its top), and see how the current x2444m consumes that spi output (start reading the "upper" PD from its decode() routine and descending into calls).
In summary: A - All commands are MSB first. B - The word to write with 0x83 is LSB first. C - The word to read starts with D0 LSB first using the descent of the eighth clock pulse from the command 0x86 or 0x87, but for bits D1 to D15 use 15 clock pulses and bits are valid in the rise of those clock pulses. D - Keep in mind that with the 2444 there is no address pointer that increases automatically, each read or write command it must indicate which word of the 16 words is going to write or read. Use the TL866II programmer with the minipro free software and also use the ponyprog-3.1.2, they are both perfectly well behaved...it's my experience with them. ------------------------------------------------------------- In this regard, ponyprog source code has a differentiated handling called x2444bus. In microbus.h protected: int RecDataWordShort (int wlen, bool lsb = false); In microbus.cpp // Receive Data word with the first clock pulse shortened. // In case of the device doesn't leave a clock pulse to switch // from DataOut to DataIn after the command int MicroWireBus :: RecDataWordShort (int wlen, bool lsb) -------------------------------------------------------------- I would not stack on SPI, I would take what SPI serves me and modify it, it seems to me that touching SPI could be an unnecessary evil playing something that is known to work to add support to archaic memory types like these 2444 that are hardly used anymore. My project is to replace an old motorola microcontroller from a commercially manufactured equipment, no longer supported by its manufacturer, with a pic, so I have to adapt to using what is already designed about 20 years ago. Time is not a resource that I have left over, I think we are all the same but I will endeavor to understand how to do it and see what comes out, for now I'm reading from this link. https://sigrok.org/wiki/Protocol_decoder_HOWTO I think the PD X2444M/P should be marked in orange as not finished yet. Greetings.