Hello NXP Community,
I've recently been stuck with SPI Interrupt by the receiving data from slave. The problem is what I want to trigger subsystem by the interrupt from received data. But in the NXP MBD Toolbox for MPC57xx v.3.0.0, I cannot find this type of interrupt in the SPI_ISR block, only END_OF_TRANSFER_ISR is available. At the same type, there is DSPI_Receive_Trigger in old version 2.0.0 of MBD, as well as DSPI_ISR block with 5 possible sources of interrupt and even examples with mentioned above interrupt.
What's reason to remove DSPI_Receive_Trigger in v.3.0.0 and how this functionality can be performed in the current case? Any suggestions are appreciated.
The shortest answer I can give - in 2.0.0 we wrote the drivers ourselves, while in 3.0.0 we used the NXP SDK drivers. Unfortunately even in the latest version of the SDK we only have SPI_EVENT_END_TRANSFER event available.
Thank you for your answer. I hope in new NXM MBD for MPC57xx this interrupt as well as earlier used functions will be returned...
And one more question about realization SPI receive data interrupt. Is it possibly to create model with different blocks (from v.2.0.0 and v.3.0.0 blocksets). I've tried to modify example from MBD v.3 - dspi_master_mpc574p just by adding DSPI_Receive_Trigger in the model. And this model has been successfully compiled and uploaded on evaluation board, but I cannot see in FreeMaster or with external data logger how execute that part which I added (since original part was working). For me it seems like what block from v.2 just commented.
Unfortunately you can not use blocks from v2 and v3 in the same model - all the drivers, startups, linkers etc. from v2 will not be copied and used at compilation or vice-versa. That is the first problem that will occur. I'm sorry that you do not have access to those interrupts, but my hands are tied - as long as we switched to using the official SDK for MPC57xx and they only expose that at the DRV level, that is what we'll let the user have control over. But there are more upsides for switching to the official SDK - the most compelling one maybe being that it is more reliable, so it isn't a downgrade, but an upgrade, with a few downsides.
If you can't work without that interrupt, one thing you could try is generate the application from Simulink and export it to S32Design Studio (I can walk you through this process if you are not sure how to do it). Once you get all your application there, you can modify manually this SPI interrupt part - you could bypass the driver if you choose to. I know this is not the best solution, but at the time being it is an option so you don't get stuck.
Please let me know if you have further questions on this topic or others.