Hello @stefan_zamfires ,
Oh, now i've got it! Well, during my debug process, before figuring out that the problem was related to the interrupts, I've changed the execution order of the receive vs transmit (master, slave) to execute first the slave block. So the data that needs to be transferred by the slave is buffered before the actual transmit happens.
Here you can see that in the left side (your initial model) the send is executed before the receive block while in the right side( the model that I've sent you) the receive block is executed first.
Now, SImulink allows you to change the execution order (also the order in which the code is generated) by setting a Priority to the block. To do that, you have to right click on a block, go to Block Properties and type the desired Priority.
Hope this helps,
Marius
Hello @stefan_zamfires ,
Even if I run the generated code on the REV B, I get the transfer both from master to slave, on the same connection you did. It looks like the RevD and RevB has the same dspi pins positions on both boards
Please have a look at the attached archive containing the generated code elf and mot file. The archive password is "dspi".
Hope this helps,
Marius
Hello @stefan_zamfires ,
Oh, now i've got it! Well, during my debug process, before figuring out that the problem was related to the interrupts, I've changed the execution order of the receive vs transmit (master, slave) to execute first the slave block. So the data that needs to be transferred by the slave is buffered before the actual transmit happens.
Here you can see that in the left side (your initial model) the send is executed before the receive block while in the right side( the model that I've sent you) the receive block is executed first.
Now, SImulink allows you to change the execution order (also the order in which the code is generated) by setting a Priority to the block. To do that, you have to right click on a block, go to Block Properties and type the desired Priority.
Hope this helps,
Marius
Hello @stefan_zamfires ,
I will respond to each point:
1. Yes, once we have the client confirms the changes are integrated into our toolbox and the next release contains them. We also have a patch page for each of the release ( not available yet, due to community platform migration) that contains all the changes. Well, the examples that come with the toolbox are tested and functional but for SPI, on MPC5744P we recommend using two boards, one configured as master, other as slave. In that scenario, the test passed. But thanks to your use case, we have now found the bug and solved it.
2. The view in the screenshots I've sent are available in newer matlab versions. I tried 2020a. It can be enabled from DEBUG > Execution Order. For older matlab version, pressing Ctrl+D will show the execution order in the upper right order of the each block.
3. Yes, I've mentioned in the previous response on how to change the Simulink priorities. When generating code, Simulink will take into consideration the priorities of the blocks. Also, this thread here https://community.nxp.com/t5/NXP-Model-Based-Design-Tools/MBDT-blocks-for-measuring-Idle-Time-or-Pro... explained by my colleague @constantinrazva explains how the C code looks like.
4. Yes, chapter 21, Interrupt Controller from the MPC5744PRM explains the interrupt core priorities. But there is a catch here. The blocks priorities that you set in the Simulink model in order to control the code generation order is different than the peripherals interrupts (asynchronous interrupts that the core handles) The RM explains how it handles two or more interrupts when occurs at the same time if they have same or different interrupt priorities. The problem here was that the Simulink executes all the step code in the PIT interrupt which priority can be set from the Main Config block. Now, the code is generated using the S32SDK. And this SDK implements all the transfer function communication using the interrupts mechanism, leaving all their priorities on default value. The problem was that the code was already executing the PIT interrupts (which had a higher priority) when the Slave interrupts triggered. This is a bug on our MBDT side which is fixed by replacing the tlc. file.
5. Well, the scenario you are using here is a testing scenario. You will only use the board SPI's as a master to communicate using an external slave. Many of our clients do this in their application and works, so I don't think you will be facing other issues regarding the SPI.
Hope this helps,
Marius
