Run Time Library Deletion from the HALCogen generated code.

Bindu Tanguturi

Other Parts Discussed in Thread: HALCOGEN, TMS570LS20206

Hi,

We are using the CCV4 for developing embedded product for avionics domain. We are using the TMS570LS20216SPGEprocessor. As of now we are able to run the code on the target with Run time library inclusion. But as per the avionics guidelines, final object code should not contain any code that is related to run time libraries.

I have used the HALCOgen tool to generate the initial drivers required for the processor TMS570LS20216SPGE. I have followed the steps mentioned in the application report SPNA 121A to create the project in the ccv4. In the project properties, i found that libc (index library) is included. I have deleted this from the project options and also deleted the included files from the project. Then i try to build the program, I got few errors related to missing functions or symbols. Ex : __TI_zero_init, exit and copy_in, memcpy functions. From the lib folder (provided in Texas compiler folder) I have copied the definitions of these functions to main application program and built it. I am successful in building the code. Then I flashed the code to target, it works as i expected ( i have written the code for NHET pulse measurement, which works fine).

Is my approach towards run time library deletion is correct? (Because i am not sure if any other files required by target processor are present in the libc)

The following items are necessary for proper initialization of the TMS570LS20 device as per the application report SPNA119.

--> Initialization of internal R4F core registers and return stack, Setup stacks, Configure Flash memory option, Setup system and peripheral clocks.

When i go through the system_startup.c file, i found that _c_int00 function is defined (which is the system reset Interrupt ). And all the above are done in the _c_int00 function. So i am sure that code execution starts from this function and all the functions calls made after this are in my main application program only.

Now here are my questions about assembly code used in the program. As this a avoincs project, for each and every line in the program, reference to manuals and justification is required.

1. The function _memoryInit_ is called in _c_int00. Which memory this asm function is initializing and to what value ? (Ref : sys_memory.asm)

2. The following functions are define in the sys_core.asm file, but not called anywhere. Looks like all thse functions are for enabling or disabling some features of the processor. What is the state of these features after reste ? Shall we have to enable or diable ?

_coreEnableEventBusExport_, _coreDisableEventBusExport_, _coreEnableRamEcc_, _coreDisableRamEcc_, _coreEnableFlashEcc_, _coreDisableFlashEcc_

3. Some more functions are about the fault status and clearing (Ex :_coreGetDataFaultAddress_, _coreClearDataFaultAddress_). Do we need these?

4. _coreInitRegisters_ : The Cortex-R4F core supports seven modes of operation. This function is used to set the registers to default value in every mode of operation. From where should (reference) i get the default value for these registers in each mode?

5. _coreInitRegisters_ : This function implementation in the the application report SPNA119 and the project created using the HALCogen tool are differs. Why ? Or is my understanding wrong? Ex : a) r1 register is set with zero in the application report where as generated code set to 0x03D0. b) values used for setting core to corresponding mode also differs.

6. Provide me the references for better understanding of assembly instruction set.

7. Is there any need for exit() function once after the main function call ? As the code in main run always in infinite loop ?

8. Please let me know any other functions required for the processor that need to be added to application program as libc library is deleted from the project.

And also suggest me if anything else to be done as a part of system initialization.

Thanks a lot in advance.

over 13 years ago

0 A Arora over 13 years ago

TI__Mastermind 30845 points

Bindu,

While I work to get you some answers, here's something you can get started with already:

6. The Cortex R4 instruction set is documented in detail in the Cortex R4 Technical Reference Manual.

I will get back on your other questions.

Regards,

Abhishek

0 Bindu Tanguturi over 13 years ago in reply to A Arora

Expert 1180 points

Hi Abhishek,

DO you have any update on this post ?

I have the TRM that you mentioned. I will go through it.

Thanks in advance.

0 Bindu Tanguturi over 13 years ago in reply to Bindu Tanguturi

Expert 1180 points

Hi forum,

Can anyone have update on this ?

0 A Arora over 13 years ago in reply to Bindu Tanguturi

TI__Mastermind 30845 points

Bindu,

sorry for the delay. Please find answers embedded:

Hi,

Is my approach towards run time library deletion is correct? (Because i am not sure if any other files required by target processor are present in the libc)

>> Yes your approach is correct.

The following items are necessary for proper initialization of the TMS570LS20 device as per the application report SPNA119.

--> Initialization of internal R4F core registers and return stack, Setup stacks, Configure Flash memory option, Setup system and peripheral clocks.

>> Yes, the code execution starts from _c_int00. Before the init routine jumps into main though, there are function calls within system_startup.c as well as other asm files.

Now here are my questions about assembly code used in the program. As this a avoincs project, for each and every line in the program, reference to manuals and justification is required.

1. The function _memoryInit_ is called in _c_int00. Which memory this asm function is initializing and to what value ? (Ref : sys_memory.asm)

>> This is initializing all RAMs except MIBSPI. In the case of MIBSPI the RAMs are auto initialized when the peripherals are brought out of reset. Further information can be found in the PBIST chapters of the TRM and the datasheet.

_coreEnableEventBusExport_, _coreDisableEventBusExport_, _coreEnableRamEcc_, _coreDisableRamEcc_, _coreEnableFlashEcc_, _coreDisableFlashEcc_

>> All these functions are related to ECC and each feature would need to be enabled with their respective function calls in order to effectively use the ECC feature. They are all disabled by default.

2. Some more functions are about the fault status and clearing (Ex :_coreGetDataFaultAddress_, _coreClearDataFaultAddress_). Do we need these?

>> Yes, I believe these functions should be used.

3. _coreInitRegisters_ : The Cortex-R4F core supports seven modes of operation. This function is used to set the registers to default value in every mode of operation. From where should (reference) i get the default value for these registers in each mode?

>> All this function is doing is initializing all registers to 0. As these registers come up in unknown state, if left uninitialized, can cause a core compare error, and thus need to be initialized to the same state on both cores.

4. _coreInitRegisters_ : This function implementation in the the application report SPNA119 and the project created using the HALCogen tool are differs. Why ? Or is my understanding wrong? Ex : a) r1 register is set with zero in the application report where as generated code set to 0x03D0. b) values used for setting core to corresponding mode also differs.

>> I did not see this problem. The code I see generated by HALCoGen matches the app note i.e. 0. Please point me to the right files / line number, or attach the file.

5. Provide me the references for better understanding of assembly instruction set.

>> Provided in previous post.

6. Is there any need for exit() function once after the main function call ? As the code in main run always in infinite loop ?

>> This is not a must if the main is an infinite loop.

7. Please let me know any other functions required for the processor that need to be added to application program as libc library is deleted from the project.

>> I will try to get this answered separately.

And also suggest me if anything else to be done as a part of system initialization.

Thanks a lot in advance.

0 Bindu Tanguturi over 13 years ago in reply to A Arora

Expert 1180 points

Thanks arora. I will come back on point 3 and 4

0 A Arora over 13 years ago in reply to Bindu Tanguturi

TI__Mastermind 30845 points

Bindu,

let me know if you are still seeing this issue.

Regards,

Abhishek

0 elenab over 10 years ago in reply to A Arora

Intellectual 440 points

Hi Bindu,

I am currently getting through the same issue of your post. In the scope of an avionic project I am trying to remove the run time library and add only the source of those library functions needed for microcontroller boot-up.

But I am currently getting into a mess and cannot have a successful build... Can you please tell me which files/functions did you include in your project? This would help me saving a lot of time...

I am using CCS v. 5.2, tms570ls20206 and the library rtsv7R4_T_be_v3D16_eabi.lib.

Thanks a lot! :-)

Elena

0 Anthony F. Seely over 10 years ago in reply to elenab

TI__Guru 68920 points

Hi Elena,

Not sure but I don't think there is a good reason to expect that the runtime lib. functions you are using would necessarily be the same as Bindu, unless you are working on the same project.

Can't you leave the runtime lib out of the build and get a list of unresolved symbols from the linker.

Then I think you could use one of the ELF utilities on the runtime library to identify which file they came from...

I'm not sure what the best tool would be .. haven't tried this before. But played around a little and if you link *with* the runtime library, then take the object that is linked and run this command

armofd --func_info -v <your_app.out>

This gives you a listing of all the function names and the file that they came from. When I did this all the halcogen files showed up in a halcogen path (subfolder) and the files without any folder info were the ones from the runtime lib. Don't know how reliable that is as a rule but it could be a place to start.

A simpler way (should have thought of this first :) might be to look at the .map file produced by the linker:

For example here you can see where several functions from the runtime lib were pulled in. I believe the name of the source would match the name of the obj although can't really tell from this if it is .c or .asm...

.kernelTEXT
*          0    00000020    00001374
                  00000020    00000014     os_tasks.obj (.const:.string)
                  00000034    00000094     rtsv7R4_T_be_v3D16_eabi.lib : auto_init.obj (.text)
                  000000c8    00000060                                 : copy_decompress_rle.obj (.text)
                  00000128    00000006                                 : copy_decompress_rle.obj (.text:decompress:rle24)
                  0000012e    00000002     --HOLE-- [fill = 0]
                  00000130    00000048                                 : cpy_tbl.obj (.text)
                  00000178    00000012                                 : copy_zero_init.obj (.text:decompress:ZI)
                  0000018a    0000000e                                 : copy_decompress_none.obj (.text:decompress:none)
                  00000198    00000594     os_port.obj (.kernelTEXT)
                  0000072c    00000580     os_heap.obj (.kernelTEXT)
                  00000cac    000004b0     os_portasm.obj (.kernelTEXT)
                  0000115c    00000238     os_list.obj (.kernelTEXT)

0 elenab over 10 years ago in reply to Anthony F. Seely

Intellectual 440 points

Hi Anthony,

thanks for your very useful suggestions.

I have started from the simpler approach, looking at the map file. I have identified the the library src files to add, I have added these to my project and then I have removed the library.

I have built my project again and I have identified the missing header files to include by looking at the build errors.

I have proceeded rebuilding and adding, but now one error still remains:

Type '__SIZE_T_TYPE__' could not be resolved

It is used many times across the library files in this way:

#ifndef _SIZE_T
#define _SIZE_T
typedef __SIZE_T_TYPE__ size_t;
#endif

I have looked through all the library but I cannot find a place where this is defined. Can you please give me suggestions about this?

Thank you a lot,

have a nice day,

Elena

0 Anthony F. Seely over 10 years ago in reply to elenab

TI__Guru 68920 points

Hi Elena,

I guess I am not understanding where the error is coming from:

Type '__SIZE_T_TYPE__' could not be resolved

What build step is causing this error.

I did a grep on _SIZE_T and __SIZE_T_TYPE__ in the unzipped lib and got the results below.

stddef.h:#ifndef _SIZE_T
stddef.h:#define _SIZE_T
stddef.h:typedef __SIZE_T_TYPE__ size_t;
stdio.h:#ifndef _SIZE_T
stdio.h:#define _SIZE_T
stdio.h:typedef __SIZE_T_TYPE__ size_t;
stdlib.h:#ifndef _SIZE_T
stdlib.h:#define _SIZE_T
stdlib.h:typedef __SIZE_T_TYPE__ size_t;
string.h:#ifndef _SIZE_T
string.h:#define _SIZE_T
string.h:typedef __SIZE_T_TYPE__ size_t;
time.h:#ifndef _SIZE_T
time.h:#define _SIZE_T
time.h:typedef __SIZE_T_TYPE__ size_t;
yvals.h:typedef __SIZE_T_TYPE__ _Sizet;

c:\Users\a0321811\Desktop\temp_rtslib\rtssrc>grep --recursive "_SIZE_T_TYPE__" *.h
stddef.h:typedef __SIZE_T_TYPE__ size_t;
stdio.h:typedef __SIZE_T_TYPE__ size_t;
stdlib.h:typedef __SIZE_T_TYPE__ size_t;
string.h:typedef __SIZE_T_TYPE__ size_t;
time.h:typedef __SIZE_T_TYPE__ size_t;
yvals.h:typedef __SIZE_T_TYPE__ _Sizet;

But I guess the question is still why you are getting the error. Are you perhaps trying to build some code that should have been including one of the above header files but is not?

0 elenab over 10 years ago in reply to Anthony F. Seely

Intellectual 440 points

Hi Anthony,

I am not understanding either... in fact I have added all the header files you have mentioned in my project.

I suppose the problem is in __SIZE_T_TYPE__ itself...

In fact this type is not defined anywhere, so when I try to define "size_t" or "_Sizet" the compiler cannot understand how to define them because it does not know what "__SIZE_T_TYPE__" is...

0 Anthony F. Seely over 10 years ago in reply to elenab

TI__Guru 68920 points

Hi Elena,

Well I think we can dig a little more just by understanding where you get the error. Is it during the compilation or link stage?

0 elenab over 10 years ago in reply to Anthony F. Seely

Intellectual 440 points

The error was after the compilation stage.

I found that the symbol __SIZE_T_TYPE is a built-in symbol, as can be seen in CCS under "Show build settings --> C/C++ general --> Paths and symbols -->Symbols". Its value is unsigned but is fixed and cannot be changed in the options panel. It is like if this symbol could not be seen in my project.

I have used a workaround in my project, adding the following into the files that were using size_t (copy_decompress_none.c and copy_zero_init.c):

#ifndef size_t
#define size_t unsigned
#endif

This allowed me to remove some .h files that were then no more necessary.

I managed to compile and link with no errors and the program seems to boot up and execute correctly. Still now I don't now why the symbol cannot be seen in the project, but witht he workaround this problem seems to be solved.

The last step I had to face was related to the code state: 16-bit or 32-bit.

Inspecting the .map files I saw that when using the library rtsv7R4_T_be_v3D16_eabi.lib, the symbol IND$CALL (16-bit indirect call) was included. When using my subset of lib source files, the symbol IND_CALL (32-bit indirect call) was used.

In order to have exactly the same symbols as when using the complied library, I added the file icall16.asm in place of the file icall32.asm to my project. Then I wanted the function __TI_auto_init (file auto_init.asm) to call IND$CALL instead of IND_CALL.

I read through this forum and spnu151 application note. I understood that this was related to the choice of code state settings ("Show build settings --> CCS Build --> ARM compiler --> Processor options --> Designate code state").

Some forum discussions suggested to set the code state of the project to 16-bit and to set the code state of single file intvecs.asm to 32-bit to allow the use of interrupt vector. But this brings additional probles related to the linker command file.

I decided instead to leave the project code state as default 32-bit (which I understood is the preferred mode) and change only the code state of file auto_init.asm to 16-bit, in order to have IND$CALL called instead of IND_CALL. This approch seems working. Can you confirm that I have proceeded in the right way?

Thank you very much for your time and support,

Elena

0 elenab over 10 years ago in reply to elenab

Intellectual 440 points

Ok, I have tested and verified that this is working properly... :-)

Arm-based microcontrollers

Arm-based microcontrollers forum

Run Time Library Deletion from the HALCogen generated code.