Hello Community,
I’m using a Logic 8 Pro analyzer to monitor the SPI communication between MCU and a SPI device.
The SPI device supports up to 112 bits per transfer and I really want to use 112 bits bit transfer. but I’m limited by the logic 8 pro which supports up to 64 bits per transfer. Is there a way to increase this parameter.
Any help is appreciated
Hello @Roy22,
since the analyzer source code is available from Github:
you should be able to change all necessary things in the source code and recompile, like “Available options in settings” at spi-analyzer/src/SpiAnalyzerSettings.cpp at aa80836ca6952379c6e9b16af206cbde1a889271 · saleae/spi-analyzer · GitHub
But…
The maximum amount of data in a framev1 to be returned by the analyzer is two-times U64 (mData1 and mData2, each U64)…
So this would mean, that you kind of need to split your analyzer (assuming you need MISO and MOSI at the same time…)…
You basically would have to use two analyzers, one for MOSI and one for MISO and maybe combine them into one frame via an HLA…
The other option might be to return only a FrameV2 frame…
This would be around here somewhere…
But I think that that would require you to clean the spiAnalyzer of any frame v1 behaviour and make it only return FrameV2 frames… not sure thought…
Cheers
Niels Göran
What device? And, you say ‘up to 112 bits’ – will it always be exactly 112 bits, or only sometimes?
A good ‘general’ setting is 8 bits per transfer, as it groups the data into ‘bytes’ and allows a variable number of 8-bit byte transfers per frame. If you just want all these 14 bytes (14 x 8 == 112) concatenated into a single hex ‘string’, then you could implement your own high-level analyzer (HLA) on top of the standard SPI one and configured with 8 bits per transfer.
The key to grouping these transfers into an overall ‘frame’ is to also capture & configure the chip select signal/channel.
As @ngblume indicates above, you can also tweak the SPI analyzer itself on GitHub, but the >64-bit transfer size will be challenging to resolve. It may not be worth the effort anyway, if your total SPI frame length is not always exactly 112 bits long.
An HLA could build up a hex string of ‘up to’ 112 bits, while the LLA would want to output frames ‘exactly’ 112 bits long. For example, if set to 8 bit transfers, I believe the existing analyzer only decodes the first 8 bit transfer of a 15-bit frame. The remaining 7 bits wouldn’t be decoded at all (i.e., no bubble text overlays, nor added arrows on the SCLK sample edges).
Good luck!
Hi @ngblume
Thank you for the reply I’ll definitely look into it