SPI setup on MPC5744P EVB

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

SPI setup on MPC5744P EVB

Jump to solution
3,321 Views
stefan_zamfires
Contributor II

Dear all,

I am trying to setup SPI on the MPC5744P EVB Rev D board with MBDT. I tried the following:

1. MPC5744P slave, S32K144 (EVB) master

2. MPC5744P slave, ATmega328P master with an Arduino board

3. MPC5744P slave with same MPC5744P as master using two instances of SPI on the micro as per the picture attached.

Pin connections of the two instances are as per the model description captured in the attach.

Phase is set to 1st edge and polarity active low for both instances.

Variables recv and slave are set to volatile and send to ExportedGlobal.

Model runs at 100ms.

I have a feeling I am missing something and I'm not sure what.

Can someone give me a hand with this please?

Thank you in advance,

Stefan

Labels (1)
0 Kudos
1 Solution
3,148 Views
mariuslucianand
NXP Employee
NXP Employee

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. 

 

mariuslucianand_0-1601451884885.png

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

View solution in original post

15 Replies
3,315 Views
mariuslucianand
NXP Employee
NXP Employee

Hello Stefan,

Are you using the blocking mode or the non-blocking mode for SPI transfer with the MPC5744P? I can't figure it out from the screenshot. If you are trying with the blocking mode, can you please give it a try with non-blocking?

Waiting for your response,

Marius

0 Kudos
3,294 Views
stefan_zamfires
Contributor II

Hi Marius,

Thank you for the quick reply. 

I have double cheked and the Transfer Mode = Non-Blocking for both SPI instances.

I have attached the model, the flash file (+map) and a picture with the board setup for your reference.

Many thanks,

Stefan

0 Kudos
3,267 Views
mariuslucianand
NXP Employee
NXP Employee

Hello @stefan_zamfires ,

The problem you are facing is caused by the interrupts used for data transfer, regardless of your configuration. 

To solve the issue and get a successful communication I've added a couple of lines of code in the attached file, so please replace it in the {MBDT Intallation Path}\mbdtbx_mpc\blocks\spi  spi_mpc_config.tlc.

 

Hope this helps,

Marius

0 Kudos
3,252 Views
stefan_zamfires
Contributor II

Hi Marius,

Thank you for the reply and the file. I have replaced it an it didn't do the job unfortunately.

Are you able to replicate the setup at your end and try to get the SPI going?

Cheers,

Stefan

0 Kudos
3,245 Views
mariuslucianand
NXP Employee
NXP Employee

Hello @stefan_zamfires,

Yes, it works on my side. I will sent you later the model an the mot file alongside with my setup description. Please check the pins connection.

 

Regards,

Marius

0 Kudos
3,210 Views
mariuslucianand
NXP Employee
NXP Employee

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 

mariuslucianand_0-1601207942067.png

image.png

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

0 Kudos
3,202 Views
stefan_zamfires
Contributor II

Hi Marius,

Thank you for the test and the files. I have tried your code and it works on my setup as well.

I have even deleted the slprj and _rtw files from the folder you sent, re-built and flashed and the SPI works. It doesn't look like a problem with the build toolchain, but rather a problem with my initial model.

I tried comparing them manually and can't spot any difference. Can you see any difference? I'm just trying to figure out what exactly the problem is.

Nevertheless, I can now start growing my application model starting from your model. So thank you very much for enabling this.

Cheers,

Stefan

0 Kudos
3,180 Views
mariuslucianand
NXP Employee
NXP Employee

Hello @stefan_zamfires

Well, the problem that causes that is not related to the Simulink block, it is related to the generated code. The problem was fixed once the mbd_spi_config.tlc has been replaced. I am glad that you asked this, so let me explain:

In order to achieve the time-driven property for the Simulink, we use a PIT timer to trigger the Simulink step generated code. So all the step functions are executed inside the PIT Channel 0 Interrupt. For the code that accesses the peripherals, the generated code calls the  S32SDK functions, so no register bits are set directly from Simulink. Now, the S32SDK uses interrupts for the SPI in order to send or receive frames, so the problem was that when we were inside of the step interrupt, we were waiting for the other interrupts to be triggered. But the priorities for the DSPI interrupts were lower than the PIT interrupt for frames to be transferred. 

What the patch does, it increases the priorities for the SPI interrupts used by the SPI peripheral.

I hope this clarifies the fix!

Marius

 

 

0 Kudos
3,167 Views
stefan_zamfires
Contributor II

Hi Marius,

Thank you for the clarification on the ISR priorities. 
It still doesn’t answer the question why if we have the same Simulink model, the generated code is different. In my mind the generated code will be different only if the Simulink models are different. 
please bear in mind I have replaced the tlc file in the relevant folder with the one you sent and generated code from my model, flashed and saw no SPI comms.

I also generated code from your model, same tlc file, and your code worked.

The question I am trying to answer is why, with the same tlc with the right ISR priorities set, the code generated from my model doesn’t do SPI, whereas the code generated from your model does, having in mind both models are the same.  

Cheers,

Stefan

0 Kudos
3,149 Views
mariuslucianand
NXP Employee
NXP Employee

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. 

 

mariuslucianand_0-1601451884885.png

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

3,122 Views
stefan_zamfires
Contributor II

Hi Marius,

Thank you for your reply.

I have tested my model with new priorities and now I can see the SPI comms.

However I think this is not a trivial change, neither the one for ISR priorities in the tlc file. I guess spotting these things comes with experience.

I think the problem is solved now and I thank you very much for your support. I would like to ask a few more questions, they are still related to the topic in question, but are not strictly about the problem:

1. Can we make sure we capture these changes in the next release of the toolbox? It would be good if the examples for SPI at least were fully functional straight out of the box.

2. The view in the screenshots you sent, where you can view the Information Overlays and the Execution Order of different block is quite useful. Is there a way I can bring it up for my model too?

3. You mentioned you can change the order of code generation, how do you do that? Is it also by changing Priorities in the block Properties?

4. How can I figure out how high the priority of my SPI ISR can be? Is there any information about how to manage the ISR priorities in the Product Manual of the procesor or an Application Note? If I wanted to change priority to 9 for example, how do I know that is not taken already?

5. Also wondering if there are other changes to the model that I should be aware of?

Thank you,

Stefan

3,117 Views
mariuslucianand
NXP Employee
NXP Employee

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.

mariuslucianand_0-1601542125308.png

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

 

3,099 Views
stefan_zamfires
Contributor II

Hi Marius,

Thank you very much for the information. Very useful, much appreciated.

I will be using the board as a slave actually. It will fulfil the role of a sensor and will be subject to master requests.

Thanks again for all your time and support.

Best wishes,

Stefan

3,091 Views
mariuslucianand
NXP Employee
NXP Employee

Hello @stefan_zamfires ,

Thank you very much for sharing this information with us! I really appreciate your interest!

If you have any other questions or need more information about our toolbox, encounter weird behaviour or you have suggestions for our toolbox, feel free to contact us!

Regards,

Marius 

0 Kudos
3,170 Views
stefan_zamfires
Contributor II

Hi Marius,

Thank you for the clarification on the ISR priorities. 
It still doesn’t answer the question why if we have the same Simulink model, the generated code is different. In my mind the generated code will be different only if the Simulink models are different. 
please bear in mind I have replaced the tlc file in the relevant folder with the one you sent and generated code from my model, flashed and saw no SPI comms.

I also generated code from your model, same tlc file, and your code worked.

The question I am trying to answer is why, with the same tlc with the right ISR priorities set, the code generated from my model doesn’t do SPI, whereas the code generated from your model does, having in mind both models are the same.  

Cheers,

Stefan

0 Kudos