MBD Toolbox doesn't initialize LPSPI interrupt vectors when running in PIL mode

[glenndoiron]

The attached file has two demonstration models and a word file detailing exactly how the issue was found.

TLDR - When compiling for non-PIL upload, the LPSPI interrupt vectors are populated with the appropriate interrupt routines.  When compiling for a PIL upload, the vectors are unconfigured and using the LPSPI peripheral causes a crash as soon as the LPSPI module generates an interrupt.

We'd like to know if this is intended or if we are doing something wrong when creating or compiling the PIL model.

[stefancinipeanu · Accepted solution]

Hello, @glenndoiron 

I have investigated the issue that you have with LPSPI interrupts and I have some ideas to explain. As Marius said PIL simulation is not intended to access hardware stuff, it is for validation purposes. In PIL simulation you put an algorithm which will run on the hardware to check if that algorithm is performing well on the target, measure the code execution profiling or to observe code coverage.

From the model deployed on target in normal mode, the entire LPSPI initialization code is executed before enabling all interrupts, as shown in the next image.

In PIL mode, the code is generated differently. The LPSPI init code is executed in the xilSystemInitialize function defined in the xil_interface.c which is generated automatically by Siumulink and we don`t have  control on this, so we cannot call the functions for enabling the interrupts. Also, the main function that we defined in normal mode in the mbd_main.c file is redesigned as hw_init in the mbd_hw_init.c file and we could enable the interrupts there, but we cannot call the initialization function which contains the LPSPI init code.

So, our suggestion is to redesign you approach and try not to access hardware in PIL simulation. Also, PIL is not a real time simulation and even if you succeed to have a functional LPSPI, you could lose data in the transfer or it can block the execution of the simulation.

Best regards,

Stefan.

[mariuslucianand]

Hello @ericrost, @glenndoiron 

I am really sorry for our delayed response. We are currently busy preparing a release on another platform and this is why our responses are being delayed. I will have a look at your reported issue.

What I want to mention is that PIL mode is supposed to test the execution of the algorithm on the CPU and we do not recommend accessing the peripherals, because both SIL and PIL are not executed in real-time, so you might face some delays when data is being transmitted. However, I am not sure if this behavior is intended or not, so I need to investigate based on your attached models.

I will send you a reply soon.

Regards,

Marius

[ericrost]

Can we please get a support response on this issue? Arrow quoted that 4 business days is typical, its been three weeks.

@mariuslucianand @paulvlase any timeline for someone picking this up?