Vectorcast using IAR compiler for RL78

Question

I'm just started to work with Vectorcast and IAR for RL78 compiler. I want to build an environment in vectorcast using IAR Compiler for RL78 Microcontroller.

Code which is used for testing has been successfully compiled in IAR embedded workbench for RL78.

I am facing the below error while building an environment in vectorcast for a module.

Error:

 40_MCAL\\Memory\\FDL\\fdl_types.h", line 133: error: division by zero enum { R_FDLT02_ASSERT_LINE_133 = 1/(! !(sizeof(fdl_u16)==2)) }; ^ 40_MCAL\\Memory\\FDL\\fdl_types.h", line 137: error: division by zero enum { R_FDLT02_ASSERT_LINE_137 = 1/(! !(sizeof(fdl_command_t)==1)) }; ^ 40_MCAL\\Memory\\FDL\\fdl_types.h", line 138: error: division by zero enum { R_FDLT02_ASSERT_LINE_138 = 1/(! !(sizeof(fdl_status_t)==1)) }; ^ 40_MCAL\\Memory\\FDL\\fdl_types.h", line 141: error: division by zero enum { R_FDLT02_ASSERT_LINE_141 = 1/(! !(sizeof(fdl_request_t)==8)) }; ^ 40_MCAL\\Memory\\FDL\\fdl_types.h", line 142: error: division by zero enum { R_FDLT02_ASSERT_LINE_142 = 1/(! !(sizeof(fdl_descriptor_t)==10)) }; ^ 5 errors detected in the compilation of "Flash.c".

And the source code is below:

# define R_FDLT02_ASSERT_CONCAT_(a, b) a##b        

#define R_FDLT02_ASSERT_CONCAT(a, b) R_FDLT02_ASSERT_CONCAT_(a, b)    

#define R_FDLT02_STATIC_ASSERT(e) enum { R_FDLT02_ASSERT_CONCAT    
(R_FDLT02_ASSERT_LINE_, __LINE__) = 1/(!!(e)) }    

/* assertion if unsigned data type size is not correct, please evaluate compiler settings for integer types */

R_FDLT02_STATIC_ASSERT(sizeof(fdl_u08)==1);    

R_FDLT02_STATIC_ASSERT(sizeof(fdl_u16)==2);    

R_FDLT02_STATIC_ASSERT(sizeof(fdl_u32)==4);    


/* assertion if enumeration type size is not correct, please evaluate compiler settings for enumeration types */    

R_FDLT02_STATIC_ASSERT(sizeof(fdl_command_t)==1);    

R_FDLT02_STATIC_ASSERT(sizeof(fdl_status_t)==1);    

/* assertion if structure type size is not correct, please evaluate compiler settings for structure types */    

R_FDLT02_STATIC_ASSERT(sizeof(fdl_request_t)==8);    

R_FDLT02_STATIC_ASSERT(sizeof(fdl_descriptor_t)==10);    

Answer 1

They are expressions intended to fail compilation if the size of the specified types is not as required by the library.

You need to check that the definitions for types such as fdl_u16 are appropriate for you target. For IAR's RL78 compiler the basic types have the following sizes:

bool               8 bits
char               8 bits 
signed char        8 bits
unsigned char      8 bits
signed short       16 bits
unsigned short     16 bits 
signed int         16 bits 
unsigned int       16 bits
signed long        32 bits 
unsigned long      32 bits
signed long long   32 bits
unsigned long long 32 bits 

It is generally more portable however if specific sizes are required to define such types in terms of the types such as uint16_t for example.

It is hard however to think of a plausible definition of fdl_u16 that would not have a size of 2, given that you have no error for fdl_u8 or fdl_u32 , but you have not provided that code.

The apparent expectation that the sizeof any specific enum is 1 is unsafe (see What is the size of an enum in C? for example), although in the IAR RL78 compiler manual it states that the smallest type that can accommodate all the enum constants will be used.

The failure of the structure types is quite likely a result of the failure if fdl_u16 , but again without the definitions of these types it is hard to tell.

Answer 2

For testing tools like VectorCAST, it's always recommended to find whether the source of error is from our Source code or from the tool. For example, VectorCAST uses a preprocessed file to parse through the code to identify if there is any syntax or semantic error or not by mimicking the compiler under use with its own parser.

Usually, the tool's parser is configured for generic default settings and it may end up with an error if one uses a non-genric project. Inside VectorCAST one can use the Test settings option to find the source of error is from compile stage or from the parse stage(test tool side). If it's a parser error(as indicated by user8270915) then contact the tool vendors support team for additional flags to resolve such issue. If an error is originating from compile stage of Test settings then in such a case one has to compare the settings used in the test environment with their actual project.