FS23 SPI Communication

[MihaiC]

Hi All, 

I have a custom board that uses an S32K144 MCU and FS2303 SBC. For time being I have a repeated reset and I'm not able to follow the instructions and disable the watchdog on SBC. 

I have an SPI connection between the MCU and the SBC that seems to work. I've used the SPI_PAL component and messages are sent accordingly with FS2303 datasheet , 32 bits where the 1st byte contains the address and red/write operation and the last byte CRC.

In order to program the SBS I need to know the current status of the chip but for some reason I get only 0s on my status request {0x06,0x00,0x00,0xB}. 

Investigating further I've notice that the reply I get from SBC is a reverse echo message. if the request is {0x01,0x02,0x03,0x04} the SBC will return {{0x04,0x03,0x01,0x01}}. 

The code will looks like 

uint8_t txBuffer[4] = {0x04, 0x03, 0x02, 0x01};
status_t status_read = SPI_MasterTransferBlocking(&spi1Instance, txBuffer, recvBuffer, 1U, TIMEOUT);

the status is STATUS_SUCCESS and in recvBuffer I get the reverse echo. 

Anyone has a clue what might be the issue here ? 

Thank you 

[ThijsK]

Also, the reason for the 4x 8-bit data format is that the PAL function has 8-bit send- and receive buffers, and we're trying to fool the SBC:

status_t LPSPI_DRV_MasterTransferBlocking(uint32_t instance, const uint8_t * sendBuffer, uint8_t * receiveBuffer, uint16_t transferByteCount, uint32_t timeout)

I can find code in the PAL to do 16- and 32-bit transfers via DMA and in the interrupt handler there is some pointer casting stuff going on fill the tx register with different sized data.

How to approach 'proper' 32-bit transfers, like the FS23 SBC requires? Ingnore the uint8_t* type and feed in uint32_t* type pointer and have lpspiState->bytesPerFrame = 4?

[ThijsK]

Mihai's HW developer chiming in here.

from the timing diagram in the FS23 datasheet I think I can deduce that CPOL = 0 and CPHA = 1, but the nomenclature is varies from place to place("first edge"/"second edge"), so it is tricky to wrap my head around sometimes.

clock source is SIRCDIV2 (8MHz/1)

which results in:
LPSPI0->CFGR1 = 0x00000003 (full duplex, CS active low, input sampled on delayed SCK edge, master mode)
LPSPI0->CCR = 0x01010106 (2 clock cycles of FCLK = 2/8MHz = 250ns SCK<->PSC delay, 3 cycles delay between tranfers, SCK divider = 6+2 =
LPSPI0->TCR = 0x40200001f (CPOL =0 , CPHA = 1, prescale from clock source to FCLK = 1, CS0, MSB first, continuous transfer enabled, 32-bit frame size) 

Are these settings correct? If not what are they and how should we have dedudeced them?

[TomasVaverka]

Hi,

What is the full part number you are using?
The A0 version is not programmed and the default communication is I2C (SPI_EN_OTP = 0).
Other versions may be programmed for SPI communication (SPI_EN_OTP = 1).

Yes, the FS23 uses SPI Mode 1 (CPOL = 0, CPHA = 1) and one SPI frame is 32 bits wide with the following arrangement:

I think that your SPI settings is correct, but I will let my colleague @danielmartynek who supports S32K MCUs confirm this. 

BRs, Tomas 

[ThijsK]

Were using a MFS2303BMBA3EP SBC connected to a FS32K144ULT0VLHT MCU

[TomasVaverka]

Hi,

OK, the MFS2303BMBA3EP is programmed for SPI communication.

I will ask my colleague @danielmartynek who supports S32K MCUs to follow up on this and review your SPI settings and code.

BRs, Tomas

[MihaiC]

We are now quite sure that the SPI communication at protocol level works as expected. Analyzing with an oscilloscope the signals  we pretty much confirmed that (See attached images). 

The issue that still stands up is that the response is not valid. The CRC of the response is not what we are expecting

Read 0x02 registry:

Request : {0x06 , 0x00 , 0x00 , 0x0B}

Response  : {0x46 , 0x00 , 0xAA , 0x2A}

Calculated CRC 0x85

Read 0x17 registry:

Request : {0x2E , 0x00 , 0x00 , 0x37}

Response  : {0x7F , 0x00 , 0x80 , 0x2A}

Calculated CRC 0x85

We can't actually trust the reply message payload. How can we move forward with this matter ? 

[TomasVaverka]

Hi Mihai,

I think that if you want to read e.g. the M_GEN_FLAG register (0x02) using SPI, you need to send: 0x04000008

Explanation:

Register address: 0x02 -> binary: 0000010
Read bit: 0 (since it is a read operation)
Control Bits: 0000000000000000 (16 bits of 0)
So first 3 bytes (24 bits):
Byte 1: 00000100 = 0x04
Byte 2: 00000000 = 0x00
Byte 3: 00000000 = 0x00
CRC calculation using a CRC calculation tool in FS23 GUI:

Hope it helps.

BRs, Tomas

[MihaiC]

Hi Thomas, 

this is exactly how we tried to read the values - and for M_GEN_FLAG (0x02) the SBS responds like this : 

on 1st request: 

Request : {0x04 , 0x00 , 0x00 , 0x08}
Response : {0x73 , 0x00 , 0x80 , 0x22}

followed by 4 times: 

Request : {0x04 , 0x00 , 0x00 , 0x08}
Response : {0x7F , 0x00 , 0x80 , 0x2A}

The CRC8 of the response is not valid. 

[ThijsK]

SPI register settings:

LPSPI0->VERID = 0x01000004
LPSPI0->PARAM = 0x00000202
LPSPI0->CR = 0x00000001
LPSPI0->SR = 0x00000001
LPSPI0->IER = 0000000000
LPSPI0->DER = 0000000000
LPSPI0->CFGR0 = 0000000000
LPSPI0->CFGR1 = 0x00000003
LPSPI0->DMR0 = 0000000000
LPSPI0->DMR1 = 0000000000
LPSPI0->CCR = 0x01010106
LPSPI0->FCR = 0000000000
LPSPI0->FSR = 0000000000
LPSPI0->TCR = 0x4020001f
LPSPI0->RSR = 0x00000002

sent message to read M_GEN_FLAG(0x02) = 04 00 00 08
received raw message = ff 00 00 55 :

When I read on each falling edge of SCLK:
MOSI = 0b00001000000000000000000000000100 = 0x08000004
MISO = 0b0101010100000000000000011111111 = 0x550000ff

seems like data bytes are sent in reverse.

[ThijsK]

When sending bytes in reverse, the data starts to make sense:

reading M_DEV_PROG_ID(0x01):
data out: 02 00 00 0d
data in: 51 21 03 e7

CRC is valid and payload data seems ok:

[ThijsK]

we're using MFS2303BMBA3EP SBC and a FS32K144ULT0VLHT MCU

[MihaiC]

Hi @TomasVaverka ,

we made some progress but the watchdog still block us. 

We've tried to setup the initialization sequence as described in the documentation but the writing of FS_I_WD_CFG (0x17) fails . 

On SPI we are sending the following command : 

We check the current status and the response is 0x310F  so the status is in INIT mode

Request: { 0x96 , 0x6C, 0x80, 0x6E }

and then after reading the configuration we receive the default value { 0x7080 }

Is there any prerequisites to change this config ? At some point I've tried to set go2init bit as well but doesn't seems to have any effect. 

Any clues ? 

[TomasVaverka]

Hi Mihai,

Our AN14129 (FS23 implementation and behaviors) provides an example of initialization sequence. Please follow all the steps recommended there. We also have the AN14041 (FS23 quick start guide) that describes SPI communication in detail.

Take a close look at these ANs, they should be fully sufficient for working with the FS23.

BTW, there is also available the FS23 SBC RTD at:

https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=SWFSXX-STDSW-D

BRs, Tomas

[MihaiC]

Hi @TomasVaverka ,

I'm keen to follow the guideline BUT whenever try to read a registry value through SPI in initial sequence the SPI replies not with the value but the exact message I'm sending. 

Example message to read FS_SAFETY_OUTPUTS (0x3F)

01111110 00000000 00000000 01001110 = {0x3F<<1 , 0x00, 0x00, crc}

where the 1st value is the address shifter one bit to left and leave bit 24 set to 0 for reading

And the reply I'm getting through SPI (or at least what SPI_PAL high level component returns is exactly the same content). 

This is the cause of my confusion. Thank you ! 

[TomasVaverka]

Hi Mihai,

Do you happen to have an oscilloscope or a logic analyzer to check if your SPI format and timing are correct?

Could you please try to read the M_VSUP_COM_FLG register?

• The SPI _REQ_I bit reports an invalid SPI access (wrong write or read, wrong address).
• The SPI _CLK_I bit reports an error in the number of SPI clock cycles.
• The SPI _CRC_I bit reports an error in the CRC.

BRs, Tomas

[ThijsK]

the reply from reading M_VSUP_COM is 0x0000 (full message is 0xFF000055)

[ThijsK]

I've repeated reading from M_VSUP_COM for different settings:
With CPOL = 0 and CPHA = 1 -> 0xFF000055
With CPOL = 0 and CPHA = 0 -> 0x7F00802A or 0x73008022
With CPOL = 1 and CPHA = 0 -> 1st time 0x7F00802A or 0x73008022, repeated reads are 0x7100802A
With CPOL = 1 and CPHA = 1 -> 1st time 0x7F00802A or 0x73008022, repeated reads are 0x7100802A

[MihaiC]

Hi @TomasVaverka , 

I don't have a logic analyzer available so for now I fully rely on what I receive in the software stack. And as the SPI calls fails I can't get the registry you've mentioned. 

I've tried SPI_PAL component first and on any request I got back my initial request on response which is weird. The status of the request was STATUS_SUCCESS. 

Then switched to LPSPI component where on my requests the status is also success, but the response buffer is filled in with 0xFF. 

My code looks something like : 

status_t status_read = LPSPI_DRV_MasterTransferBlocking(LPSPI_INSTANCE, txBuffer, recvBuffer, 32U,TIMEOUT); 

where in txBuffer I have the 7 bits address of registry and 0 for read , 2 zero values and CRC8 . 

read_status is successful, the call waits until recvBuffer is filled in, unfortunately with unusable content. 

Thank you !