SW Bug missing ISR macro in I2C module of SW32G_RTD_4.4_3.0.2_HF01 and later versions ?

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

SW Bug missing ISR macro in I2C module of SW32G_RTD_4.4_3.0.2_HF01 and later versions ?

696 Views
SSyb
Contributor III

Hi community, Hi NXP experts,

I am facing a compilation error in the I2c module of the NXP Realtime driver package SW32G_RTD_4.4_3.0.2_HF01:

 

 

[ 20%] Building C object CMakeFiles/RTA-SK.dir/C_/NXP/SW32G_RTD_4.4_3.0.2_HF01/eclipse/plugins/I2c_TS_T40D11M30I2R0/src/I2c_Ip_Irq.c.o
"c:\nxp\sw32g_rtd_4.4_3.0.2_hf01\eclipse\plugins\i2c_ts_t40d11m30i2r0\include\I2c_Ip_Irq.h", line 135: error #40:
expected an identifier
void I2c_Ip_IRQHandler1(void);

 

 

my driver stack is (in Tresos) configured to by of OsifOperatingSystemType = OsifAutosarOsType, and that determines the content of the ISR() macro.

I am aware that I2C is not (yet) specified by AUTOSAR, but it should not be a problem to use the I2C driver of the RTD stack
and call it from some custom integration code or an AUTOSAR CDD.

In my humble opinion, the root cause for the compiler error is the following:

in the file C:\NXP\SW32G_RTD_4.4_3.0.2_HF01\eclipse\plugins\I2c_TS_T40D11M30I2R0\src\I2c_Ip_Irq.c,
the function names are correctly wrapped in the ISR() macro:

 

 

#define I2C_START_SEC_CODE
#include "I2c_MemMap.h"

#if (I2C_INSTANCE_COUNT >= 1U)
ISR(I2c_Ip_IRQHandler0)
{
/* Call interrupt handler instance 0 */
I2c_Ip_ModuleIRQHandler(0u);
}
#endif

 


while in the corresponding header file C:\NXP\SW32G_RTD_4.4_3.0.2_HF01\eclipse\plugins\I2c_TS_T40D11M30I2R0\include\I2c_Ip_Irq.h, this macro is missing:

 

#define I2C_START_SEC_CODE
#include "I2c_MemMap.h"

#if (I2C_INSTANCE_COUNT >= 1U)
void I2c_Ip_IRQHandler0(void);
#endif

 


putting the ISR() macro manually around the function prototypes for the Irq handlers solves the problem

 

#if (I2C_INSTANCE_COUNT >= 1U)

ISR(I2c_Ip_IRQHandler0);
//void I2c_Ip_IRQHandler0(void);

#endif

 

This is also how it is done in all other modules of the RDT package.

But that means I am patching static NXP code. I am currently of the opinion that this is a software bug in a module that is possibly rarley used in conjunction with classic AUTOSAR stacks (but it should work anyway). I have checked later RTD versions for the S32G2, the code looks the same.

Can anyone from NXP please confirm (or object), and if confirmed: feed this into the development pipeline for fixing ?

thanks and best regards,
Stefam

target SoC: S32G274A
target board: NXP S32G-VNP-RDB2
project environment: classic AUTOSAR
Real time Drivers: NXP SW32G_RTD_4.4_3.0.2_HF01 (and later versions)

0 Kudos
5 Replies

681 Views
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

We may not be understanding correctly, if so, we apologize.

Under the RTD, there are 2 types of examples, AUTOSAR and non-AUTOSAR. When we use the AUTOSAR example (I2c_HLD_Transfer_S32G274A_M7) we do not have the compilation error you are seeing, nor we have to change the definition of the functions under "I2c_Ip_Irq.h".

With the above said, if the compilation error you are seeing is as common as you say, we should have taken notice a while ago and provided the required patch. Since we cannot see any compilation error as the one you are seeing, we cannot escalate this manner in the proper way.

Again, could be that we are not understanding the overall request. For which, we apologize.

Please, let us know.

0 Kudos

629 Views
SSyb
Contributor III

Hi @Daniel-Aguirre 

if you mean the example under "C:\NXP\SW32G_RTD_4.4_3.0.2_HF01\eclipse\plugins\I2c_TS_T40D11M30I2R0\examples\EBT\I2c_HLD_Transfer_S32G274A_M7"

No, in my humble opinion this is unfortunately not an AUTOSAR example. you can see it in the Tresos Base module configuration, it is configured as "BareMetal".(as such it compiles - but this does not prove me wrong, because my use case is AUTOSAR, not bare metal).

Moving to AUTOSAR has quite an impact on the source code through conditonal compilation, in all places with

#ifdef USING_OS_AUTOSAROS

When I change this setting only on the fly, I run into different compilation problems which I think arise from the fact there is no proper AUTOSAR Os in this example project or in the RTD stack. Among other things,  the OS should define the ISR() macro as per AUTOSAR conventions. I gave up converting the I2c_HLD_Transfer_S32G274A_M7 example into a proper AUTOSAR example.

In my project, the AUTOSAR OS comes from our (ETAS) AUTOSAR stack.

 

Once again: you can see in pretty much all other sub-modules of the SW32G_RTD_4.4_3.0.2_HF01 package that, when Interrupt handler are declared in static code, both the *.c file and the *.h file use the ISR() macro (because it poterntially changes / extends the name of the interrupt handler, and hence it must be used in both places)

Have you discussed this with the RTD developers ?

best regards,

Stefan

SSyb_0-1686732515653.png

 

0 Kudos

622 Views
Daniel-Aguirre
NXP TechSupport
NXP TechSupport

Hi,

Thanks for your feedback.

Since we had not understand the overall situation, we could not go to the related team, since we could not explain what the situation is.

From the last explanation you are providing, we can go with the internal team, since at this moment is clear what the situation is, aside from the beginning.

Please, let us know.

0 Kudos

547 Views
SSyb
Contributor III
Hi @Daniel-Aguirre, any new on this topic ?
0 Kudos

617 Views
SSyb
Contributor III

Hi @Daniel-Aguirre ,

 

perfect, thanks. The most important question to the developers is: is this issue confirmed, or am I doing something wrong....

When we know this, we can discuss next steps.

thanks and best regards,

Stefan

 

0 Kudos