SPI device needs LSBit First

Author Message
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 73
Posted: 05:44am 25 Jan 2023      

The SPI on MMBasic only supports MSB first (Most significant Bit first).  The chip I am trying to talk to requires LSB first (Least Significant Bit first).  I simply reverse the order of the 8 bits I am writing and reading from the SPI.  But I can not get it to work??  I have never had any issues with the standard MSB SPI comms.  The chip is MODE 0 and 8 bits, so this is not the issue and I ensure SSEL pin goes low during SPI write or read. The chip is most significant byte first so this is not the issue either.

Is there any reason why just reversing the 8 bits in each byte would not work over the MMBasic MSBit SPI to emulate LSBit comms??
Just know enough to get me in trouble, but not quite enough to get me out.
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 7133
Posted: 07:54am 25 Jan 2023      

More info needed. Which SPI device, which version of MMBasic. What is your bitswap algorithm
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 73
Posted: 12:30am 30 Jan 2023      

Thanks Peter,
I am using the STM32H743ZIT6 or STM32H743ZIT6U chips with ArmmiteH7V5.50.11 or ArmmiteH7V5.07.00b16

The Chip I am trying to talk with is a MAXQ1061 Cryptographic co processor.

"The MAXQ1061 can act as an SPI slave device. Characters conveyed over the SPI bus are transmitted least-significant bit first, using SPI Mode 0. SPI supports bitrates up to 1Mbps. Clock settings are CPOL=0 (Clock low when inactive), CPHA=0 (Data valid on clock leading edge)"

This is the bitswap algorithm I wrote  TxPayload%() MSB in TXData%() LSB out.

for x% = 1 to ByteLength% 'Chip requires LSBit first
       TXData%(x%)=0
       for y% = 0 to 7
         TXData%(x%) = TXData%(x%)<<1
         TXData%(x%) = TXData%(x%) or (TxPayload%(x%)<<(63-y%))>>63
       next y%
     next x%


Attached are PDFs of the MOSI + CLK DSO image and MISO + CLK DSO image of the response from the chip.

The chip response is not what is expected.

MAX1061 MOSI + CLK.pdf

MAX1061 MISO + CLK.pdf
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 73
Posted: 01:32am 30 Jan 2023      

Forgot to state the data sent to chip

Hex to chip TxPayload%()
AA 00 F2 00 07 80 13

LSBit sent first TXData%() - BIN sent to SPI Write function
01010101 00000000 01001111 00000000 11100000 00000001 11001000

Hex Response from chip with 10 bytes read after converting back to MSB
55 00 00 00 00 00 00 00 00 00

I get lots of different incorrect responses from the chip depending on what command I send or often no response at all.

The problem is either a protocol issue or a SPI communication issue.  The protocol has been checked, the CRC calculation checked, just running out of ideas??

I am currently waiting on technical support from analog.com, but they takes weeks to even reply.

The chip is under an NDA, so I can not sent you the full data sheets.

John
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 73
Posted: 12:43am 31 Jan 2023      

Hi Peter,

On bytes 2 and 5, why does the MMbasic SPI write function pulse the MOSI high almost immediately after the rise of the 8th clk when the first bit of the next byte is a 0.  If the SPI slave device has any delay after seeing the rising CLK it would incorrectly read the 8th bit as 1 instead of 0.  I would have thought that the MOSI should stay at the logic level of the 8th bit for a short time and then change to the logic level of the first bit of the next byte before the next 8 CLK cycles.

This chips SPI slave is limited to just 1Mhz so it might be a bit slow.
I have tried slower rates of 10kHz, but this probably does not change when this pulsing high of the MOSI line occurs after the 8th CLK.

John
Bowden_P
Senior Member

Joined: 20/03/2019
Location: United Kingdom
Posts: 137
Posted: 12:10am 01 Feb 2023      

Hi John,
While I don't have any experience with the Armmite's SPI interface, I suspect it is very similar to other 'Mites in the family.

I have used the SPI instructions in MMBASIC to communicate between a Micromite Explore 28 or a Micromite Plus Explore 100 and a variety of ADC, DAC, Load Cell, or PIC16F microprocessor chips reliably. While some claim to have an SPI interface, they may be better described as "SPI like" in a lot of cases.

I have found that talking to a Microchip MCP3204 ADC for instance, requires MMBASIC Mode 0 :-

SPI open 30000,0,32                     ' 30KHz, Mode 0, 32 bits.

but for a PIC16F1776 with the SPI peripheral CKE and CKP both = "0", MMBASIC Mode 1 is required :-

SPI open  30000,1,8                     ' 30KHz, Mode 1, 8 bits.


I hope this may help rather than confuse !

With best regards, Paul.
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 7133
Posted: 07:55am 01 Feb 2023      

I wouldn't worry about the MOSI pin as its level is undetermined except at the relevant clock edge.

My advice FWIW is to bit bang the interface in Basic using subroutines that interface like the inbuilt commands. That way you have total control of the signals. Once you have that working you can go back to the H/W interface
Edited 2023-02-01 18:03 by matherp
retepsnikrep

Senior Member

Joined: 31/12/2007
Location: United Kingdom
Posts: 130
Posted: 10:29am 01 Feb 2023      

I fell down a pothole for days with SPI using a PIC which had slew rate control on by default and hidden in the depths of the register datasheet.

It fell over at any sort of decent speed as the pulses looked like a sinewave!!
Turn off slew rate control and enable hard switching and nice square pulses.
Martin H.

Senior Member

Joined: 04/06/2022
Location: Germany
Posts: 270
Posted: 05:28pm 01 Feb 2023      

  HardingJohn said  The SPI on MMBasic only supports MSB first (Most significant Bit first).  The chip I am trying to talk to requires LSB first (Least Significant Bit first).  I simply reverse the order of the 8 bits I am writing and reading from the SPI.  But I can not get it to work??  I have never had any issues with the standard MSB SPI comms.  The chip is MODE 0 and 8 bits, so this is not the issue and I ensure SSEL pin goes low during SPI write or read. The chip is most significant byte first so this is not the issue either.

Is there any reason why just reversing the 8 bits in each byte would not work over the MMBasic MSBit SPI to emulate LSBit comms??

How about usig an Array?


Dim byte%(255)
For f%=0 To 255
 l%=f%
 For n%=0 To 7
   Byte%(f%)=Byte%(f%)<<1
   inc Byte%(f%),(l% And 1)
   l%=l%>>1
 Next n%
Next f%

'test
cls
For f%=0 To 255:Pause 200: Print f%, Bin$(Byte%(f%),8):Next


so you can send the mirrored value out of the Array Byte%()

Cheers
Mart!n
ville56
Regular Member

Joined: 08/06/2022
Location: Austria
Posts: 47
Posted: 09:10pm 01 Feb 2023      

Had a similar problem, Peter Mather came up with an, for me, ingenious solution for swapping bits within a byte real fast. Look at the URL belowfor details

Bit swap in byte

hope this helps a bit,
Gerald
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 73
Posted: 01:38am 02 Feb 2023      

Thanks for everyone's Bitswap solutions.  This will help with reducing the encryption and decryption times for TLS1.2 connections.
Once of course I can get a valid response from the chip.
Thanks Peter, I will try a bit bash solution instead of MMBasic's SPI write and Read functions.