SPI transfer in VLPS no longer working after SDK upgrade to 4.0.1

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SPI transfer in VLPS no longer working after SDK upgrade to 4.0.1

2,316 Views
Daniel_Wax
NXP Employee
NXP Employee

This customer started its code writing by using S32 DS 2018.  they used PEX to generate the pin code and then exported all the files into Linux where they also merged the SDK.  They did upgrade that SDK along the way to SDK version 3.0.1.  Somewhere along the way they there was a CAN driver bug in SDK 3.0.1 that caused them to look at upgrading to SDK 4.0.1.  However they are keeping the original PEX generated files and now things seem to be breaking.  WE had moved to this MEX format whaen we migrated S32DS to version 3.3 and its likley the way the MEX files integrate with the SDK 4.0.1 is different than how the PEX files integrated with SDK 3.0.1

 

This text below is thier description of an issue they are having with LPSPI/DMA but I have a feeling the issues might be larger than just this single one they have noticed. 

What are some options they have in order to use SDK 4.0.1 with the older PEX generated files?  Does the way the PEX integrates with SDK3.0.1 change drastically when moving to MEX/SDK4.0.1?

 

FROM CUSTOMER:

I am working on a project currently using S32K SDK 3.0.1 that I would like to upgrade to the current SDK, 4.0.1. In this project, an S32K148 MCU is acting as a SPI slave. The MCU is running FreeRTOS, with tickless idle enabled. When FreeRTOS enters low-power mode, the MCU code starts a SPI transfer with DMA and then enters VLPS. When the SPI transfer completes, the system wakes to process the received data. This works with SDK 3.0.1.

When I use SDK 4.0.1, the SPI transfers in VLPS fail. LPSPI_DRV_SlaveIRQHandler gets called, and the LPSPI1->SR TEF (Transmit FIFO underrun) bit is set, so the transfer fails. I'm transferring 25 32-bit words at a time (100 bytes), and it is always the 23rd word that doesn't get transferred.

What changed between the SDK versions? It doesn't seem to be something in the LPSPI driver, as a diff between those doesn't show a lot of changes, and none of the changes look like they'd cause this. The only change I am making is changing the base directory for the SDK in my Makefile; no code changes and I'm doing a full rebuild after changing SDK versions.

EDIT Some additional information:
If I reduce the transfer size to 88 bytes, it works fine with the newer SDK. The 100 byte transfers work occasionally (maybe 1 out of 10 times).

 

Labels (1)
0 Kudos
4 Replies

2,265 Views
nathand
Contributor II

I've narrowed the problem to the "power" module within the SDK - if I use the 4.0.1 SDK but replace the power module with the one from SDK 3.0.1 then it works.

0 Kudos

2,079 Views
DanhNguyenXuan
NXP Employee
NXP Employee

Hi @nathand .
I did try used default config of lpspi_dma_slave example with VLPS power mode and i transfer successful 100byte/100byte.

0 Kudos

2,028 Views
nathand
Contributor II

Thank you for following up on this. I've gotten pulled into some other projects (shortage of chips, looking at other options) and have not had time to get back to working on this SDK upgrade since things are working well enough with the previous version. Good to know that SPI does work in VLPS with the example code; I'll follow up here when I have a chance to get back to working on this.

0 Kudos

2,214 Views
DanhNguyenXuan
NXP Employee
NXP Employee
There are some difference of "power_manager" driver between RTM 3.0.1 and RTM 4.0.1:
  • BIASEN bit was implemented in RTM 4.0.1.
  • Minor change of POWER_DRV_SwitchVlprClk in RTM 4.0.1 could affect to system clock in VLPR mode.
The changes might impact to LPSPI performance. @nathand could you please provide more information about your project (clock configuration, code sequence...), then I will be able to check it more closely.
0 Kudos