S32 DS 3.4 FreeRTOS Config

[partis]

Hi

When using S32 Design Studio and adding the FreeRTOS component, it allows configuration of the various sections of FreeRTOS. When changes are made to the design via the GUI, the file peripherals_freertos_1.c is updated with comments of new settings, but FreeRTOSConfig.h does not change with the actual settings.

Is this a known problem?

Kind regards

Gary Partis

[mikedoidge]

Hi Gary,

Would you kindly share the installation details so we could know what version is impacted by this issue?

Help -> S32DS Extensions and Updates, then click on 'Installation Details' at the lower right of the Overview panel.

If the device you are using is part of a family, please specify the exact processor name.

Thanks,

Mike

[partis]

Hello Mike

Digging through the .mex file, I find that the IDE is placing the FreeRTOSConfig.h file elsewhere. It has detected another version of this file in a virtual folder within the project, and has decided to use that instead of the "board" folder.

gary2_0-1654587028904.png

The image above shows what the IDE is updating and relative paths. Obviously, the last entry is incorrect (it is picking up demo code from a CANopen stack). Manually changing the .mex file has no effect as it appears to re-search the filesystem and pick up the first entry it finds (presumably in alphabetic order).

Is there a way to prevent this automatic search-and-change from taking place?

Kind regards

Gary

[partis]

Hi Mike

We are targeting an S32K144 LQFP64 device. The installation details of the IDE and extra is thus:

Package: GDB Client for ARM Embedded Processors 9.2 Build 1701; Version: 1701; Build id: 202012011653
Package: S32 Design Studio Platform package; Version: 3.4.3; Build id: 202112151555
Package: S32K1xx development package; Version: 3.4.1; Build id: 202106101451
Package: NXP GCC for Arm Embedded Processors v6.3 build 2017 with EWL2; Version: 2017; Build id: 202005201521
Package: NXP GCC for Arm Embedded Processors v9.2 build 1649; Version: 1649; Build id: 202005201157
Package: GNU ARM PEMicro Interface Debugging Support; Version: 5.2.0; Build id: 202203211842
Package: AMMCLIB for S32K14x devices; Version: 1.1.27; Build id: 202112140821
Package: S32 Design Studio Platform Tools package; Version: 3.4.3; Build id: 202112151555
Package: S32SDK S32K1XX RTM 4.0.2; Version: 4.0.2; Build id: 202106110620
Package: NXP GCC for Arm Embedded Processors Build 1620; Version: 1620; Build id: 202005201521

Would a copy of the .mex file help find this issue?

Kind regards

Gary

[mikedoidge]

Hi Gary,

Please see my reply on the other thread:  Re: S32 DS 3.4 Clock Config - NXP Community

It applies here as well.

I did a quick check, I was not able to reproduce the issue you observed. Are you using a workspace from an older version of the S32 Design Studio? Is the project a new one or was it created in and converted from an older version of the S32 SDK or S32 Design Studio?

Best Regards,

Mike

[partis]

Hi Mike

Many thanks for your reply.

The workspace (.project & .cproject) and system config (.mex) were all created by the S32 DS 3.4; so should not contain any legacy/old/incorrect settings from an earlier SDK or DS.

May I PM you with the files..?

Kind regards

[mikedoidge]

Hi Gary,

I'm not sure if the .MEX file would be enough, but we could try that. Ideally if you could share the project folder. If you are not able to share it on a public forum, you could either send it to me via PM as you suggest (still within the community, but only visible to the two of us), or you could submit a support ticket and it should go to my team.

Best Regards,

Mike

[partis · Accepted solution]

Hi Mike

I have created a work around for the IDE placing the FreeRTOSConfig.h file in the incorrect place. Before starting S32 DS, manually edit the .project file such that the virtual directory points to an illegal path, so the tool doesnt find an alternative FreeRTOSConfig.h file to update. Then perform all configs, regenerate files; and exit S32 DS. Finally, manually edit .project back to the true path.

This work around is satisfactory for our needs

Just need to sort the clock tree now...

Kind regards