I probably found a bug in the Simulink code generation

cancel
Showing results for 
Search instead for 
Did you mean: 

I probably found a bug in the Simulink code generation

309 Views
Contributor III

Hi again,

after trying to get an external interrupt working with the eTimer building blocks (inside Simulink), I probably found a bug in the code generation.

Inside the intc_init.c file, where the ISR priorities get set, lines get mixed up a bit which results in wrongly set priorities. In my case I tested the eTimer 0 channel 4 with an Input High Edge interrupt by a secondary source which does work fine when coded in S32 IDE. The priority for the 4th channel gets set to 0x00, but that should be 0x0F. Also the comment next to it refers to channel 5, but the vector number does belong to channel 4. (The vector number for channel 5 is missing completely.)

After setting the right priorities manually in S32 IDE (with an imported Simulink project), it works btw.

You may look at the screenshots I added to this message.

Can anybody please confirm that?

EDIT:

I think I found another thing:

The eTimer Mux table is probably also not completely right. Module 0 seems to have the right values, but module 1 and 2 are probably wrong, since the IMCR values are all "-1". Please look at the corresponding .png file.

Kind regards,

Markus R.

4 Replies

30 Views
NXP Employee
NXP Employee

Hi markusransberger‌,

Thank you for reporting the eTimer ISR issue. I confirm is a bug: it is now logged in our database as: AST-780

The workaround is quite simple: just modify the ..\mbdtbx_MPC574xP\mbdtbx_pnt\mbdtbx_pnt\mbdtargetmainlibpnt.tlc file to include the eTimer_0 TC4IR entry. 

If you want (and I encourage you) you can add the modified file here as a patch - so that everyone else could benefit.

In respect with the second item, those structures implement the Table 4-7 Pin Muxing and Table 4-9 Peripheral Muxing from MPC5744P Reference Manual. The -1 is usually used for reserved/not implemented functionalities. I do not the reason behind this implementation but i will try to find out (at this point i guess is hw specific) .

Best regards,
Daniel

0 Kudos

30 Views
Contributor III

Hi dumitru-daniel.popa,

do you have any update on the eTimer muxtable? I'll attach the "fixed" file under this message. (No warranty that every value is right. Use with caution.)

pastedImage_3.png

Kind regards,

Markus R.

30 Views
NXP Employee
NXP Employee

Hi markusransberger‌,

It looked over our older records and seems like we have inherit the file from an older version and failed to update it.

As soon as we will have a new update for the toolbox we will fix this as well. 

Till then, it looks like your file is in sync with the RM and could be used as workaround.

Thank you & Best regards,

Daniel

30 Views
Contributor III

Hi Daniel,

I'm going to make a post with the corrected file where you said.

Also I edited the pin muxing table and now everything I tested so far works. I'm pretty sure that it should not be a hardware limitation since you are actually specifying the IO pins in the quick start guide of the DEVKIT.

IO.png

Also in Simulink you can choose the pins, but they do not get muxed obviously.

eTimer.png

eTimer2.png

Kind regards,

Markus R.