S32K144 LPSPI Peripheral Chip Select

[gramirezv]

Hi,

I want to use the SPSPI on the S32K144, but I don't can't figure out how to transmit data to a specific peripheral using the Peripheral Chip Select 0 - 4 lines.

For example I want to use LPSPI2, so I'm using the lpspi_s32k14_config block.

Since I want to use the LPSPI2 I select "Instance 2" 

And the Advanced configuration allows me to select the Peripheral CS (in this case let's say I want LPSPI2_PCS2), so I select "Peripheral CS = 2"

But when I want to set the lpspi_s32k14_master_transfer block, I only have the option to select the Instance.

In this case I selected Instance 2

But what about using the other Peripheral CS on the same instance. Let's say I want to transmit to the Peripheral 0 for Instance 2?

If I duplicate the lpspi_s32k14_config block and change the "Peripheral CS = 0", I get this error:

Error duplicating of the LPSPI2 configuration block 'main/LPSPI_Config_COMM_CPU '. The block should be only one

How can I control each Peripheral Chip Select for any given LPSPI instance?

Thank you,

[gramirezv]

Hi constantinrazvan.chivu‌,

After checking out the LPSPI as Master one instance and the four PCS; I started testing the LPSPI now in Slave Mode, and I'm using two S32K144EVB boards and I'm utilizing two LPSPI instances as Slave. I'm using the "Dedicated slave select lines scheme" as described in page 1439 of the S32K1xx Series Reference Manual, but in this case I'm using only two SPI Slaves.

So I wired the two S32K144EVB as follows

I didn't want to use LPSPI1 because some pins are shared with the onboard SBC used for CAN, so I choose to utilize LPSPI0 and LPSPI2 and wired them as shown in the picture from the whiteboard.

I found the following while doing the S32K144EVB_COMM side (2 LPSPIs):

• My first issue I found was on the PCS3 lines for this two specific instances, the microcontroller used on the S32K144EVB has the same pin for both LPSPI0_PCS3 and LPSPI2_PCS3 defied as PTA15. But that's ok, at least for this test I'm using only PCS0 on both LPSPI0 and LPSPI2, which are PTB0 and PTA9 respectively. But when I wanted to build the software I got the following error: 
  So, since I already knew that the conflict was on PCS3 (which I'm not using), I disabled the "Diagnostics" for the LPSPI on the MBD_S32K14x_Config_Information block. But for Slave mode, you'll be using only one of the available PCS lines on any given interface.
• My second issue, and the most important I think, is when I connected the SOUT lines from LPSPI0 and LPSPI2 from the S32K144EVB_COMM (Slave) to the S32K144_CL (Master) board. I wasn't getting any valid data to the Master from the Slaves, analyzing the SOUT signal on an oscilloscope found that the line was being pulled down. Digging out in the S32K1xx Series Reference Manual I noticed the field OUTCFG on register CFGR1, if 0b - Output data retains last value when chip select is negated, else if 1b - Output data is tristated when chip select is negated. So I looked into the generated code and noticed that the OUTCFG is being set as 0 (LPSPI_DATA_OUT_RETAINED) in function LPSPI_SetPinConfigMode inside LPSPI_DRV_SlaveInit.
  So I imported the generated C code into S32 Design Studio for ARM and changed the following code inside the LPSPI_DRV_SlaveInit function:
  
  (void)LPSPI_SetPinConfigMode(base, LPSPI_SDI_IN_SDO_OUT,
                  LPSPI_DATA_OUT_RETAINED, true);
  to
  (void)LPSPI_SetPinConfigMode(base, LPSPI_SDI_IN_SDO_OUT,
                  LPSPI_DATA_OUT_TRISTATE, true);
  So, this solved the problem. After confirming my hardware teammate this was causing the SOUT lines to be in conflict and needed to be tristated when PCS not active.

So after all the above I'd like to make the following suggestions:

• On the lpspi_s32k14_config block, when "Role" in the General tab is selected as "Master" to give the option to select how many PCS are to be used either 1,2,3 or 4 of them, so we are able to use LPSPI0 and LPSPI2 (with the constraint of not using PCS3 for one of them) without having to disable the diagnostics for this module.
• On the lpspi_32k14_config block, when "Role" in the General tab is selected as Slave to give the option to use only one PCS line and give the option select which PCS line to use, this will prevent the similar problem as the point above when using LPSPI0 and LPSPI2 in as slaves the same model.
• Also on the lpspi_32k14_config block, when "Role" in the General tab is selected as Slave to give the option to select the Output config register field for the given LPSPI interface as Slave, to be either LPSPI_DATA_OUT_RETAINED or LPSPI_DATA_OUT_TRISTATE (OUTCFG = 0 or 1). So we have the option to use the "Dedicated slave select lines scheme" and control the data flow from one Master to up to four Slaves with independent PCS lines.

I hope all of this makes sense, and please let me know if more information is needed.

Best regards and thanks again for the outstanding support.

Gustavo

[constantinrazva]

Hello gramirezv‌,

First of all thank you for the detailed explanation you gave and for digging in. Great job on not only finding the cause, but even a fix for the OUTCFG issue - really appreciate your effort!

Now about the 2 issues:

• 1. OUTCFG - the important issue in my opinion - our team (MBDT) only provides a  Simulink <--> SDK interface; we are not managing the codebase for the SDK itself, so I can't change the LPSPI_DRV_SlaveInit function myself, but I will talk to the respective team and present them your findings. For the time being you can make the changes you proposed into the source file located in 

src\S32_Platform_SDK\platform\drivers\src\lpspi\lpspi_slave_driver.c

       This is the location from where the file is copied when generating a project - so if you want to make a permanent change, this is the place to do it.

• 2. We will take your feedback under consideration for our next release - our consistency checks have the purpose of doing some static analysis on the model in order to avoid possible issues when running on the hardware. So in the case of LPSPI we want to have a way to tell the user there might be a problem with his current setup. Probably we'll put a checkbox in the LPSPI Configuration block for the user to select the CSs he's going to use, and only check those pins for collision with others used in the model. We'll think of  what other options we have.

And again - thank you for your feedback and suggestions!

Kind regards,

Razvan.

[gramirezv]

Hi constantinrazvan.chivu‌,

I'm glad to be of some help here, this community is a great resource. Our plan is to use the S32K144 for our projects so I'll be testing some more things in the following months, so I'm pretty sure I'll be around here asking for help.

For item 1, I understand what you say, and I think I'll modify the lpspi_slave_driver.c file so OUTCFG is always tri-stated.

For item 2, I agree on the consistency checks for static analysis and it makes sense, but it would be great if we could have the flexibility so select any given set of PCS lines.

Best Regards,

Gustavo

[constantinrazva]

Hi gramirezv‌,

Please ask anytime you're having trouble/any issue regarding MATLAB/Simulink or our toolbox. Looking forward to hearing other suggestions from you.

Kind regards,

Razvan.

[constantinrazva]

Hello gramirezv‌,

First of all, thank you for pointing this out. It is indeed a limitation in our current implementation for S32K14x as you said. I have opened a ticket internally (https://jira.sw.nxp.com/browse/AST-1245 ) and we will have this fixed in our next release for this platform - but this will be somewhere mid-2019.

Can you give me some details on what you are planning to do? If you really need to go over this current limitation, I can think of 2 ways for dealing with this:

1) a workaround where you set the CS pin to a pin you don't actually use and set the CS by using the GPIO write blocks, so you manually set/clear the CS pin right before the transmission starts. This way you can make a subsystem that will act as a setCS(desired_cs) function that reads a global variable(desired_cs) and only sets/clears that CS. In this manner, you can call this subsystem, send something to a slave, call this subsystem again and send to another slave data. One more thing you'll have to worry about in setting the CS is the desired polarity.

2) if you want we can provide a hotfix where we add the CS to the transfer blocks and manage all that you need in our code generation, thus changing our library. In this case, would you be willing to provide us some feedback for the testing done on your part? Because when we do a hotfix we generally only do bugfixes, as we can not fully test new features added in this stage.

Best regards,

Razvan.

[gramirezv]

Hi constantinrazvan.chivu‌, thanks for your reply.

We have 3 SPI slave devices (a DAC, a FPGA and another S32K board) that we need to communicate to using the same LPSPI interface on the S32K, so I need to have control on the peripheral I'm sending the data over SPI.

Since this is a design that we want to carry for more than one project, I'd like to take advantage of this feature and utilize the dedicated LPSPI PCS lines for the given interface, so in the future when the new release of the MDB Toolbox happens we would be able to integrate the simulink blocks without having to modify our hardware or carry the control of the alternate setCS functionality; because, if I understood correctly, I won't be able to utilize any of the PCS outputs from the LPSPI interface. At least not the ones defined on the  lpspi_s32k14_config block, on the "pins" tab, I'm I right on this assumption?

If that's the case I think I'd like to have your option 2) as Plan A, meaning that I'd like to get the HotFix to include this functionality and I will provide feedback on my testing back to you. If we do go this route, how long you think would it take to get the HotFix? I'm asking not for rushing you, but because our team is working on the PCB, and they need to know if they have to move the CS for the SPI peripherals. Depending on this, I think we can take a decision if going this route or going with Plan B.

Plan B, being your option 1) as utilizing other output pins and setting these as CS for our peripherals. Also, I'd be great if you could confirm that we can use any of the PCS pins defined in the "pins" tab on the  lpspi_s32k14_config block, or if we need to find another three unused digital pins.

Thanks a lot for your assistance and prompt response I really appreciate your time.

Best Regards,

[constantinrazva]

Hello gramirezv‌,

In both cases you can use the pins from the Pins tab in the LPSPI Config Block. I think there was a confusion when I've said   'set the CS pin to a pin you don't actually use'  . Let me give you an example for this workaround so it's more clear: let's say you use an instance of LPSPI that has the following pins available for PCS:

   - pcs0: A1,A2

   - pcs1: B3,B4

   - pcs2: C5,C6

You can select to use A1,B3,C5 for your design. In Simulink, you'll have to call GPIO Write for A1,B3,C5, depending on which slave you want to talk to, but if you select in the LPSPI Config block to use PCS0 with A1 as the option, whenever you will send something, it will automatically select the A1 (and clear/set it, depending on the polarity selected). So if you want to manage by your own the slave selection, in the config block you'll have to select A2 or B4 or C6, pins that you'll not really use in your design. This pin will just be a dummy that is active whenever you're sending something via that specific SPI instance. So you'll add to the downsides of this approach the fact that you use a pin as a dummy.

But the good thing is that if you use the hotfix I'll provide, you won't have to use that dummy pin or do your own slave selection management. I will provide this hotfix in a day or two and post it here first.

Kind regards,

Razvan.

[gramirezv]

Hi constantinrazvan.chivu‌,

Thank you for the clarification, now I get it how it would work. Yes, the hotfix will make my life simpler :smileywink:.

I appreciate your quick response and support on this issue.

Best regards,

Gustavo

[constantinrazva · Accepted solution]

Hello gramirezv‌,

You can find attached here the hotfix I was talking about. Now you can use all CS pins, by selecting in the transfer block  whichever slave you want to send to. The only downside is that in this current hotfix we initialize all 4 PCS pins from the LPSPI instance you want to use. So if you only want to use one, you'll still have 3 extra pins initialized. In your example you are using all of them, so that's no problem. In the future release we'll provide a mechanism to select which you want to use in the configuration block and only initialize those, but that would have meant other disruptive changes to our library, so we decided to leave it out of this hotfix and add it to the next release.

Could you confirm that everything is working on your end too?

Note: for this hotfix you'll have to replace the following files (preferably after saving a copy of the old ones):

- lpspi_s32k14_config.tlc move to {TOOLBOX_ROOT_DIR}\mbdtbx_s32k14x\mbdtbx_s32k14x\blocks\lpspi folder

- lpspi_s32k14_master_transfer.tlc move to {TOOLBOX_ROOT_DIR}\mbdtbx_s32k14x\mbdtbx_s32k14x\blocks\lpspi folder

- lpspi_s32k14_slave_transfer.tlc move to {TOOLBOX_ROOT_DIR}\mbdtbx_s32k14x\mbdtbx_s32k14x\blocks\lpspi folder

- mbd_s32k14_ec_toolbox.mdl move to move to {TOOLBOX_ROOT_DIR}\mbdtbx_s32k14x\mbdtbx_s32k14x folder

- mbd_s32k14_lpspi_get_pin_info.p move to {TOOLBOX_ROOT_DIR}\mbdtbx_s32k14x\mbdtbx_s32k14x\mscripts\lpspi folder 

- mbd_s32k14_lpspi_transfer_sdk_params.p move to {TOOLBOX_ROOT_DIR}\mbdtbx_s32k14x\mbdtbx_s32k14x\mscripts\lpspi folder 

Kind regards,

Razvan.

[rathi_tg]

Hello,

Presently I am using S32k144 and I have to collect data from different slave on same SPI Instance but I am unable to figure out how do I control the CS .

Will the Hotfix Support S32k144 as well.

My directory: :C:\NXP\MATLAB\NXP_MBD_TOOLBOX\Toolboxes\NXP_MBDToolbox_S32K1xx\mbdtbx_s32k14x\mbdtbx_s32k14x\mbd_s32k14.tlc

There is no such path mbdtbx_s32k14x\mbdtbx_s32k14x\blocks\lpspi folder

Please guide me to do so 

Regards 

Gopal Rathi

[gramirezv]

Hello constantinrazvan.chivu‌,

I tested the hotfix you sent me for selecting the PCS lines independently and is working as expected.

I setup a quick test program with the S32K144 with LPSPI Instance 0 as Master at 100000 bps. And I see the PCS0 - 4 lines being activated accordingly.

Once again thank you very much for your support.

Best regards,

Gustavo

[gramirezv]

Hi constantinrazvan.chivu‌,

Thanks for providing me the hotfix, that was really fast. I will do some testing, and I will post back my findings.

Best regards,

Gustavo