Upgrading S32 Design Studio for Power Architecture from V1.1 to V1.2

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

Upgrading S32 Design Studio for Power Architecture from V1.1 to V1.2

Jump to solution
2,931 Views
ivanjuresa
Contributor II

Evening,

We found some quite interesting problem regarding new S32 version. 

We were working on S32 V1.1 for quite some time now and today we have switched on V1.2. Hardware we are working on is MPC5744P and problem emerged on our STM (System Timer Module) driver.

Problem is when it tries to set PRESCALER value program jumps to IVOR1 machine check. Digging deeper we found that when writing PRESCALER value to STM_0.CR.B.CPS register it tries to write value as BYTE and not as WORD which is of course triggering error because as said in MPC5744P Reference Manual STM registers can only be accessed using 32-bit (word) accesses.

pastedImage_2.jpg

As seen on picture above S32 Design Studio V1.1 is used and it writes value as word.

pastedImage_3.jpg

On picture above v1.2 is used and it can be seen that on same line of code it tries to write value as BYTE which results in MachineCheck IVOR1.

Problem can be solved by OR-ing value as: STM_0.CR.R |= STM->prescaler - 1;

but it is not readable as above solution.

Why is only prescaler value being written as BYTE and the rest are written as WORDs?

Regards,

Ivan

1 Solution
2,536 Views
stanish
NXP Employee
NXP Employee

Hi Ivan,

There is one change in the default compiler settings in v1.2.

Strict volatile bitfields are not forced anymore by default for e200zX cores

I'd recommend you to add this compiler flag to your project settings:

-fstrict-volatile-bitfields

pastedImage_2.png

Hope it helps.

Stan

View solution in original post

8 Replies
2,537 Views
stanish
NXP Employee
NXP Employee

Hi Ivan,

There is one change in the default compiler settings in v1.2.

Strict volatile bitfields are not forced anymore by default for e200zX cores

I'd recommend you to add this compiler flag to your project settings:

-fstrict-volatile-bitfields

pastedImage_2.png

Hope it helps.

Stan

2,536 Views
ivanjuresa
Contributor II

It is working now. Jiri and Stanislav thank you for your help. I will mark Stanislav's answer as correct one.

Ivan

0 Kudos
Reply
2,536 Views
jiri_kral
NXP Employee
NXP Employee

Hello Ivan, 

I tried reproduce your issue - but when I'm using unsigned char and int - in both cases is code working for me and disassembly uses word instructions - even with -O3 optimization. How is defined your STM->prescaler variable? 

Jiri

0 Kudos
Reply
2,536 Views
ivanjuresa
Contributor II

Hello,

We are using -O1 optimisation but have also tried it on -O3. Same machine check is happening in both cases. Below is attached picture with STM structure.

pastedImage_8.png

Are you sure you are using V1.2?

Ivan

0 Kudos
Reply
2,536 Views
jiri_kral
NXP Employee
NXP Employee

I'm using v. 1.2 - build number 170217. With your structure, -O1 and this source code

pastedImage_2.png

I got  this disassembly and STM_0.CNT is counting without any exception. 


pastedImage_3.png

Do you have installed all updates? (main menu bar -> help -> check for updates) Wich language dialect are you using? (i left the section in default settings). 

Jiri

0 Kudos
Reply
2,536 Views
ivanjuresa
Contributor II

I am using Version: 1.2 and Build id: 170613. S32 is up to date. Language dialect is left blank. Optimisation is also on -O1.

I tried your code and it still tries to write it as byte.

Ivan

0 Kudos
Reply
2,536 Views
jiri_kral
NXP Employee
NXP Employee

I got the 170613 version (I had some pre-release version) - and you are right - output code is using byte instruction also with unsigned int as a variable for prescaler storage or with direct number. Thank you for catching this. I'll create JIRA ticket S32DS team. 

As a temporary workaround - you can use OR or switch back to previous version. I'm not sure if this error is affecting other read/write operations with registers. 

Jiri

0 Kudos
Reply
2,536 Views
ivanjuresa
Contributor II

Thank you for your feedback. We didn't get any strange behaviour from other drivers so hopefully its isolated case.

Ivan

0 Kudos
Reply