TMS320F28388D: localtime does not work as expected.

Hi User,

Please expect a couple of days delay for our expert to analyze and respond due to holiday on 4th Jul 2022.

Hidehiko,

Our compiler expert will be back in the office tomorrow.

Regards,

John

The function localtime makes use of a file level static struct variable named local_tm.  My guess is the memory location of this struct is somehow a problem.

Please build again, but add the linker option --mapfile_contents=sym_defs.  This causes the linker map file to show static symbols like local_tm.  Make sure it is allocated to memory that can be read and written, is correctly configured for the system, etc.

Please let me know if this suggestion resolves the problem.

Thanks and regards,

-George

Hi George,

Thank you for your information.

local_tm is allocated on RAM area. And this issue is eliminated when we call __localtime32() directly.

Could you please how we should use this library ? 

rts2800_fpu32_eabi.lib : localtim64.c.obj

Run/Load             
Value      Binding   Name (Section)
--------   --------  ---------------
0000df4d   local     $C$L1 (.text)
 00080f4d            
0000e017   local     $C$L10 (.text)
 00081017            
0000e019   local     $C$L11 (.text)
 00081019            
0000e02a   local     $C$L12 (.text)
 0008102a            
0000e035   local     $C$L13 (.text)
 00081035            
0000df50   local     $C$L2 (.text)
 00080f50            
0000dfb9   local     $C$L3 (.text)
 00080fb9            
0000dfca   local     $C$L4 (.text)
 00080fca            
0000dfcc   local     $C$L5 (.text)
 00080fcc            
0000dfdc   local     $C$L6 (.text)
 00080fdc            
0000dfef   local     $C$L7 (.text)
 00080fef            
0000dff1   local     $C$L8 (.text)
 00080ff1            
0000e004   local     $C$L9 (.text)
 00081004            
0000fe0c   local     .data (.data)
0000df43   local     .text (.text)
 00080f43            
0000df43   global    __localtime64 (.text)
 00080f43            
0000fe0c   local     local_tm (.data)
0000df43   global    localtime (.text)
 00080f43            

Best regards,

Hidehiko

Hidehiko Kaya said:

local_tm is allocated on RAM area

I presume this means reading and writing this variable works with no issues.

Hidehiko Kaya said:

this issue is eliminated when we call __localtime32() directly

The only documented interface is localtime().  __localtime32() is an implementation detail that you might notice, but you should not directly call it.  Please search the C28x compiler manual for the sub-chapter titled Support for Time and Clock Functions, and carefully follow it.

Please let me know if these suggestions resolve the problem.

Thanks and regards,

-George

Hi George,

>"Please let me know if these suggestions resolve the problem."

Could you let me know what you mean suggestions ?

At a your point of view, local_tm is allocated on RAM area because it is assigned to ".data" section.

"Support for Time and Clock Functions" is described about time() function.

I think that localtime() does not need CIO and CCS.

I'm confusing how I should to try to resolve this issue.

As you mentioned, I should not to call __localtime32() directly.

Could you please provide an idea to eliminate this issue ?

Best regards,

Hidehiko

Please go back to the post where you include some lines from the linker map file.  Several clues about your build are present in those lines.

To get a build that works the same way, I have to use these build options ...

-D__TI_TIME_USES_64 --abi=eabi --float_support=fpu32

Please confirm you use these same build options.  For now, I presume you do.

When built this way, a call to localtime in the C code generates a call to a function also named localtime.  Within the assembly code file generated by the compiler, localtime is a static symbol.  It is not a global symbol available to the whole program.  This static localtime function does nothing more than call the function __localtime64.  There is a global symbol also named localtime, which is at the same address as __localtime64.  I agree this is confusing.  Please consider it all carefully.

You say that you can avoid the problem by changing, in the C code, from localtime to __localtime32.  Are you certain about that?  Perhaps that is a typo, and you mean you directly call __localtime64.

Thanks and regards,

-George