RM48L952: HalCoGen 4.07.00 - CSP

Hello Andrew,

I have forwarded your question to one of our SW experts. He will be back with you for your questions. Thanks.

Thanks QJ, When will the sw expert be able to discuss the issue ? Just so that I can indicate when the task can be completed.

Hello Andrew,

We also forwarded the email to SW team, and they will do some test. I will check with them tomorrow morning.

The TAU provides the capability for customers to update to their HALCoGen version, HALCoGen configuration, build options, compiler tools, and specific target device configurations. Customers can choose from the existing test cases with the appropriate modifications to the existing test cases, and/or addition of test cases of their own.

The CSP release version 1.0.0 was tested against HALCoGen version 04.02.00. The issues observed are due to changes done in later HALCoGen versions and could also come from configuration differences from the standard configuration tested by TI. Reference test cases are available for the TI standard configuration which uses HALCoGen version 04.02.00.

Girish,

We did not anticipate modifying any of the test cases within the CSP. We understood that the package was available to test the HalCoGen code, and assumed that any modifications to the code generated would not affect the test suite, or the test suite would be updated to align with the new revision of HalCoGen. The whole point of purchasing the package was to reduce the amount of software test required on our part, and to rely on the TI testing performed by the test suite, but repeating it for our particular configuration

Could you confirm if TI will or will not update the HalcoGen CSP to align with the latest version of HalCoGen (4.07.00). Assuming that TI will be updating the CSP can you provide dates

Hi Andrew,

Please refer to the CSP User's guide. As HALCoGen is a code generator which can generate different code based on customer configurations, we bundled our Test automation framework or the TAU as a part of the CSP. This allows customers the flexibility to verify their HALCoGen generated code and generate the required test coverage for their needs of compliance to safety standards. Customer configurations include the HALCoGen project configuration, compiler settings, target configurations, compiler toolchain, HALCoGen version changes.

Chapter 10 of the HALCoGen CSP User's Guide explains the procedure needed for defining and adding new tests. This should also serve as the guide for making modifications to existing test cases. Customers can selectively use the test cases which are relevant to their use case and make any modifications needed. They may also add any additional  test cases of their own.

At this point we do not have plans to issue a CSP update. We can work with you on the specific cases of test case failures you're observing. Please attach the relevant log files and mention test cases which have the failures.

Thanks,

Girish

Thanks Girish,

I will run the ADC tests and send you the log files for the failing tests. is there a more direct route other than the forum ? In the mean time look at the following comment I made earlier

ADC 1- Fails 4 tests – The failure appears to be associated with the G0SAMP – strange as ADC 2 passes all tests

Failing tests :- adcInit, adcGetEVTPin, and both adc1GetConfigValue


Regards

Andy

Thanks Girish,

I will run the ADC tests and send you the log files for the failing tests. is there a more direct route other than the forum ? In the mean time look at the following comment I made earlier

ADC 1- Fails 4 tests – The failure appears to be associated with the G0SAMP – strange as ADC 2 passes all tests

Failing tests :- adcInit, adcGetEVTPin, and both adc1GetConfigValue


Regards

Andy

Thanks Girish,

I will run the ADC tests and send you the log files for the failing tests. is there a more direct route other than the forum ? In the mean time look at the following comment I made earlier

ADC 1- Fails 4 tests – The failure appears to be associated with the G0SAMP – strange as ADC 2 passes all tests

Failing tests :- adcInit, adcGetEVTPin, and both adc1GetConfigValue


Regards

Andy

Thanks Girish,

I will run the ADC tests and send you the log files for the failing tests. is there a more direct route other than the forum ? In the mean time look at the following comment I made earlier

ADC 1- Fails 4 tests – The failure appears to be associated with the G0SAMP – strange as ADC 2 passes all tests

Failing tests :- adcInit, adcGetEVTPin, and both adc1GetConfigValue


Regards

Andy

Girish,

Please find attached the logs as indicated above.

These are the logs for ADC1 Unit tests and for ADC2 unit tests noting that ADC2 passes and ADC1 fails test  adcInit, adcGetEVTPin, and both adc1GetConfigValue

3441.Temp for ti.7z

Hi Andrew,

thanks, we'll take a look into these issues - we'll get back to you if we need more information.

thanks,

Girish

Hi Girish,

Have you managed to have a look at the log files I sent ?

Regards

 Andy Walsh

Hi Andy,

we are still investigating - Please give us some more time.

thanks,

Girish

Girish,

After a brief absence  (holiday and other tasks) I am now returning to look at the HalCoGen CSP

Having a more in depth look at the ADC tests, I have resolved the issues with the exception of the following tests

adcGetEVTPin

For ADC 1

There are two tests , one fails and one passes. The ADC Event pin is an output that can be routed through the pin mux to an external pin. We have not routed it to an external pin. The ADC Event Pin can be used as a general purpose I/O pin, hence  there are registers that allow the pin to be set as an output / input. The test uses it as an output and reads the value back. the initial code sets the ADC Event pin, and then the adcGetEVTPin code reads it back, and verifies the values set is the same as the value read back.

adcREG1->EVTDIR = 1;             */ Pin set as an output /*
adcSetEVTPin(adcREG1, 1);      */ Set the value as a 1 /*

It appears that the Event Pin is stuck - the readback result is always zero. Hence in the initial setup one of the two adcGetEVTPin tests passes and the ADC Event pin is set to a zero.

For ADC 2

It appears that the Event Pin is stuck - the readback result is always one. hence in the initial setup one of the two adcGetEVTPin tests passes and the ADC Event pin is set to a one.

Can you have a look at this please so that I can sign off the ADC tests of the HalCoGen code

Regards

Andy Walsh

Hi Andy,

please accept my apologies for the delay in responding to your queries.

For ADC, we have investigated the issues you observed and found the following:

1. adcInit and adc1GetConfigValue failures for ADC1, related to the readback of adcREG1->EVSAMP. We found that the testcase file compared the read back value to (uint32) ADC1_G1SAMP_CONFIGVALUE and not to the configured (uint32) ADC1_G0SRC_CONFIGVALUE, which was a typo in the test case file. Please fix this in your test case files.

2. ADC1EVTpin - The default pinmux selects ADC1EVT by default. However, on the TI RM48 HDK board this pin is connected to EMAC. The DIP switch S2 controls the Ethernet interface, if enabled, it can influence the input at ADC1EVT pin.

3. ADC2EVT pin -It is not default pin(default MIPSPI3) so we need to do pinmuxing. This should be done in startup of code of the test case.

4370.ADC2_UT.xlsxWe will now look into the other issues you reported.

Regards,

Girish

Thanks Girish - that all worked out.

I'll start having a look at the next issue I reported.

CRC

Resolved the issue with the CRC test - spreadsheet

ESM

The ESM test file seems to call an incorrect variable ESTATUS5ESM- (replaced with EPSR) and the "esm_functest1() etc in the clean up cause the compilation to fail. removing the cleanup code and changing the var name to EPSR allows it to compile but seems to hang the processor.. hope that helps

Regards

Andy Walsh

Good morning Girish,

     This should be a quick one for you to fix or at least tell me where the code is......

I have ran the Gio test and after a bit of work can get all but one test to work. The test that fails is 10.2 gioGetConfigValue, after a bit of investigating I noticed the following error in the code that is generated - inszt_gio.c :-  see the code exert below with the error highlighted - PULDIS and PSL have been swopped. Where is the source code that gets pulled together to create the inszt_gio.c source file ? If I could locate that I can correct the error there. I could put the inverse error in the test spreadsheet... but that doesn't look good. Hopefully you can spare a few minutes to point me in the correct direction... (If you can supply the file name I can find it from there...)

Regards

Andy Walsh

Line

1931        config_reg -> CONFIG_PORTBDIR = (
1932        ( gioPORT_t * ) 0xFFF7BC54U ) -> DIR ;
1933        config_reg -> CONFIG_PORTBPDR = (
1934        ( gioPORT_t * ) 0xFFF7BC54U ) -> PDR ;
1935        config_reg -> CONFIG_PORTBPSL = (
1936        ( gioPORT_t * ) 0xFFF7BC54U ) -> PULDIS ;
1937        config_reg -> CONFIG_PORTBPULDIS = (
1938        ( gioPORT_t * ) 0xFFF7BC54U ) -> PSL ;

Hi Andy,

The GIO test issue is actually a bug in the source code, i.e., the test case is correct, but the code has a bug. We have this as a known issue (currently internally).

This is in the HALCoGen generated file gio.c:

void gioGetConfigValue(gio_config_reg_t *config_reg, config_value_type_t type)

{

if (type == InitialValue)

{

   config_reg->CONFIG_INTDET    = GIO_INTDET_CONFIGVALUE;

       config_reg->CONFIG_POL       = GIO_POL_CONFIGVALUE;

       config_reg->CONFIG_INTENASET = GIO_INTENASET_CONFIGVALUE;

       config_reg->CONFIG_LVLSET    = GIO_LVLSET_CONFIGVALUE;

   config_reg->CONFIG_PORTADIR    = GIO_PORTADIR_CONFIGVALUE;

   config_reg->CONFIG_PORTAPDR    = GIO_PORTAPDR_CONFIGVALUE;

   config_reg->CONFIG_PORTAPSL    = GIO_PORTAPSL_CONFIGVALUE;

   config_reg->CONFIG_PORTAPULDIS = GIO_PORTAPULDIS_CONFIGVALUE;

   config_reg->CONFIG_PORTBDIR    = GIO_PORTBDIR_CONFIGVALUE;

   config_reg->CONFIG_PORTBPDR    = GIO_PORTBPDR_CONFIGVALUE;

   config_reg->CONFIG_PORTBPSL    = GIO_PORTBPSL_CONFIGVALUE;

   config_reg->CONFIG_PORTBPULDIS = GIO_PORTBPULDIS_CONFIGVALUE;

}

else

{

/*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */

   config_reg->CONFIG_INTDET    = gioREG->INTDET;

       config_reg->CONFIG_POL       = gioREG->POL;

       config_reg->CONFIG_INTENASET = gioREG->ENASET;

       config_reg->CONFIG_LVLSET    = gioREG->LVLSET;

   config_reg->CONFIG_PORTADIR    = gioPORTA->DIR;

   config_reg->CONFIG_PORTAPDR    = gioPORTA->PDR;

   config_reg->CONFIG_PORTAPSL    = gioPORTA->PULDIS;

   config_reg->CONFIG_PORTAPULDIS = gioPORTA->PSL;

   /*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */

   config_reg->CONFIG_PORTBDIR    = gioPORTB->DIR;

   config_reg->CONFIG_PORTBPDR    = gioPORTB->PDR;

   config_reg->CONFIG_PORTBPSL    = gioPORTB->PULDIS;

   config_reg->CONFIG_PORTBPULDIS = gioPORTB->PSL;

}

}

You can disposition this failure on your end if you do not use this API. You shouldn't fix this issue by modifying the test case itself as that is not a valid test.

Thanks,

Girish

Thanks Girish,

We will be using the function as part of the continuous / periodic diagnostic test suit, so we will correct it using the HalCoGen report we generate to initiate the change - Well show the final result in the test results document... I've changed the code and re run the test - all ok so will raise a formal internal change request.

I will continue with the Het driver tests...

Any progress on the ESM or the FEE ?

Regards

Andy Walsh

Good Morning Girish,

Hopefully you can spend a few minutes and provide me with some direction for the issue.

I managed to have a look at the Het1 Unit test.

Set up the halcogen as per the instructions in the spreadsheet. produced the Halcogen code

At the moment it fails to compile.

The compiler identifies the following error :-

"C:\ti\Hercules\SafeTI-HALCoGen-CSP\RM48x_v01.00.00\HALCoGen\HALCoGenTAU\Scripts\inszt_het.c", line 2929: error #20: identifier "HET_INIT1_PST" is undefined

Has this been removed from the Het code in ver 4.0.7 of Halcogen ?

How do we get around this ie do I need to edit the test code or is there some code missing from the het.c source file ?

Regards

Andy Walsh

Hi Andy,

Could you share your Halcogen(.hcg) project file? I want to see your HET configurations.
What are the issues you are facing with PMM?. Please share the details.

Regards,
Kalaiyarasan.

Good Morning Kalaiyarasan.

Please find attached the HalCoGen Project file. I have been changing things in the area of the HET to see if I can get the tests to run.

With respect to the PMM, so far I have attempted to run this but the processor simply seems to halt. - I have not looked into this yet to see what needs to be done so your assistance is most welcome. ( Suspect it powers down something that it shouldn't...

If you want the logs, I will provide them.

Regards

8726.MiS210_HCG_CSP_1.7z

Andy Walsh

Hi Andy,

I am suspecting power domain(PD2) is making problem. So please unchecked all PD2 test cases and once again run the remaining test cases with your board.
let me know your status.

Regards,
Kalaiyarasan

Hi Kalaiyarasan

OK :- I unchecked all the PD2 tests in the HalCoGen TAU. The remaining tests then run successfully. Having looked at the test names  I re-introduced all tests apart from PMM_UT_02:2, 03:2, 06:1, and yes all the tests run to completion. any one of the unchecked tests cause the test sequence to halt. Does the development board use the PMM DMM RTP ETM ? In our final build we will probably turn Power domain 2 off to save power. - do we need the functions supported by power domain 2 for anything other than debugging ?

Regards

Andy Walsh

Hi Andy,

Please find attached Errata document, "should not disable PD2 using software commands, otherwise system will hang after warm reset".

So Please skip the following test cases:

1.    PMM_UT_02:2 - Unit test for pmmTurnOFFLogicPowerDomain to power down PD2

2.    PMM_UT_04:2 - Unit test for pmmTurnONLogicPowerDomain to power down PD2

3.    PMM_UT_06:1 - Unit test for pmmISLogicPowerDomainActive to check status of PD2

Regards,

Kalaiyarasan.1351.spnz196g.pdf

Many Thanks Kalaiyarasan,

Was this bug fixed in the revision D silicon for the RM48L952ZWT ? I believe this is the version of the silicon we will use in production. I've looked for the errata sheet but it doesn't appear in the search results "RM48x Microcontroller errata sheet" where can I find it ?

Regards

Andy Walsh

Andy,
Please refer to the erratum DEVICE#B053 in www.ti.com/.../spnz223b.pdf.
Thanks,
Girish

Hi Andy,

Thanks Andy, Please share your FEE build configuration file.

Regards,
Kalaiyarasan

5657.Downloads.7zHi Kalaiyarasan,

Sorry for the delay, attached is the Halcogen files that we use in the project. This is my starting point for testing so it may need changes for the HET code verification etc..

Two files in ZIP - hcg and dil. If you you need anything else please let me know and I will provide

Hi Girish,

Any news regarding the issues outstanding for the HalCoGen CSP ? ie N2HET, FEE, and ESM ?

Regards

Andy Walsh

Hi Andy,

please check - Kalai has posted an updated ESM test file.

I will check with Kalai about the status of FEE and NHET and get back to you.

Thanks,

Girish

Thanks Kalaiyarasan

That is all good..

Just the HET1 &2 and FEE to go - then we have a clean set of tests for Halcogen 4.0.7

Regrads

Andy Walsh

Thanks Girish,

Not sure why I didn't pick that up immediately. That fixed the ESM issue which now leaves the FEE, and the HET1& 2 issues.

Many thanks for your continued support.

Regards

Andy Walsh

Thanks Andy,

In your Halcogen project in "NHET Driver settings" you linked some external files(DummyHet.h, DummyHet.c). What is the Purpose of this? it is possible please share me that files and current HET compilation logs.
Are you completed all your configuration/changes in HET module? Any update on HET after your last post(.hgc proj)?
If you made any changes please update me.

For FEE, Please share your FEE build configuration file.

Regards,
Kalaiyarasan

Hi Kalaiyarasan,

For our project we generate a number of N2Het configuration files. We select the file we require at run time. For the initial HalCoGen configuration we use dummy files which allow the HalCoGen code to compile (Placeholders).

The code that we use to configure, check and control the N2Het's is tested by our LDRA static, and module testing, and then integration test and so on. The N2Het drivers are used and the intention is to run the CSP package to verify they function as expected. Hence we are happy to follow the CSP TCF file suggested HalCoGen configuration ie setting up a PWM and verifying with a scope etc etc

The N2Het compile issue appears to be because this identifier is incorrect - this is identified in the TCF spreadsheet and can be corrected - removing the _st1

"..\..\..\..\source\het.c", line 2921: error #20: identifier "config_reg_st1" is undefined Please confirm this is correct.

The tests appear to start, but seems to get stuck on the system reset...

Hope that helps with the N2Het.. Halcogen file for the test  here

For the FEE, I have attached the HalCoGen project which contains the FEE configuration. So you can see our configuration for the FEE....5277.source.7z

If there is anything

1423.HALCoGen_Lib.zip

Hi Kalaiyarasan,

From the FEE build log, the Cancel.c file does not compile due to an endieness error. Checked the project file that is "little endian"

Regards

Andy Walsh




'Building file: ..\..\..\..\source\ti_fee_cancel.c'
'Invoking: ARM Compiler'
C:/ti/ccsv6/tools/compiler/arm_15.12.3.LTS/bin/armcl -mv7R4 --code_state=32 --float_support=VFPv3D16 -me --include_path="C:/ti/ccsv6/tools/compiler/arm_15.12.3.LTS/include" --include_path="C:/ti/Hercules/F021 Flash API/02.01.01/source" --include_path="C:/Users/walsan01/workspace/MiS210_HCG_CSP_1/DummyHet" --include_path="C:/ti/Hercules/F021 Flash API/02.01.01/include" --include_path="C:/Users/walsan01/workspace/MiS210_HCG_CSP_1/include" --include_path="C:/Users/walsan01/workspace/MiS210_HCG_CSP_1/source" -g --define=LDRA_ENABLED=1 --diag_wrap=off --diag_warning=225 --display_error_number --abi=eabi --enum_type=packed --obj_directory=Debug --include_path="C:/ti/ccsv6/tools/compiler/arm_15.12.3.LTS/include" --include_path="C:\Users\walsan01\workspace\MiS210_HCG_CSP_1\include" --include_path="." "..\..\..\..\source\ti_fee_cancel.c"
"C:\ti\Hercules\SafeTI-HALCoGen-CSP\RM48x_v01.00.00\HALCoGen\HALCoGenTAU\Scripts\inszt_ti_fee_cancel.c", line 434: warning #48-D: incompatible redefinition of macro "NULL" (declared at line 195 of "C:/ti/ccsv6/tools/compiler/arm_15.12.3.LTS/include/stdio.h")
"C:\ti\Hercules\SafeTI-HALCoGen-CSP\RM48x_v01.00.00\HALCoGen\HALCoGenTAU\Scripts\inszt_ti_fee_cancel.c", line 1120: fatal error #35: #error directive: "Target Endianess is not defined. Include F021 header files and library."
1 catastrophic error detected in the compilation of "..\..\..\..\source\ti_fee_cancel.c".
Compilation terminated.

Hi Kalaiyarasan,
From the FEE compile log there appears top be an endian issue. Checked the project - this is little endian.

Regards

Andy Walsh

' '
'Building file: ..\..\..\..\source\ti_fee_cancel.c'
'Invoking: ARM Compiler'
C:/ti/ccsv6/tools/compiler/arm_15.12.3.LTS/bin/armcl -mv7R4 --code_state=32 --float_support=VFPv3D16 -me --include_path="C:/ti/ccsv6/tools/compiler/arm_15.12.3.LTS/include" --include_path="C:/ti/Hercules/F021 Flash API/02.01.01/source" --include_path="C:/Users/walsan01/workspace/MiS210_HCG_CSP_1/DummyHet" --include_path="C:/ti/Hercules/F021 Flash API/02.01.01/include" --include_path="C:/Users/walsan01/workspace/MiS210_HCG_CSP_1/include" --include_path="C:/Users/walsan01/workspace/MiS210_HCG_CSP_1/source" -g --define=LDRA_ENABLED=1 --diag_wrap=off --diag_warning=225 --display_error_number --abi=eabi --enum_type=packed --obj_directory=Debug --include_path="C:/ti/ccsv6/tools/compiler/arm_15.12.3.LTS/include" --include_path="C:\Users\walsan01\workspace\MiS210_HCG_CSP_1\include" --include_path="." "..\..\..\..\source\ti_fee_cancel.c"
"C:\ti\Hercules\SafeTI-HALCoGen-CSP\RM48x_v01.00.00\HALCoGen\HALCoGenTAU\Scripts\inszt_ti_fee_cancel.c", line 434: warning #48-D: incompatible redefinition of macro "NULL" (declared at line 195 of "C:/ti/ccsv6/tools/compiler/arm_15.12.3.LTS/include/stdio.h")
"C:\ti\Hercules\SafeTI-HALCoGen-CSP\RM48x_v01.00.00\HALCoGen\HALCoGenTAU\Scripts\inszt_ti_fee_cancel.c", line 1120: fatal error #35: #error directive: "Target Endianess is not defined. Include F021 header files and library."
1 catastrophic error detected in the compilation of "..\..\..\..\source\ti_fee_cancel.c".
Compilation terminated.

Hi Andrew,

You need to define __little_endian__ in your project settings so that F021 defines _LITTLE_ENDIAN. FEE checks if the either of _LITTLE_ENDIAN or _BIG_ENDIAN are not defined, it throws an error.

Hi,

just checked the properties. - Selecting general, under the advanced setting it requests the device endianness. this is set as little for the RM48L952ZWT . Is this what you mean or is there another setting you are referring to ?

regards

Andy Walsh

Hi Andy,

Goto Properties->Build->ARM Compiler->Advanced Options->Predefined Symbols. Add  __little_endian__.

Thanks Vishwanath,

I added the "predefined symbol" as you indicated... looked through the header files to make sure the format was correct and the compile line looks like this ( from the Build Options .txt)

Compiler Options:-mv7R4 --code_state=32 --float_support=VFPv3D16 -me --include_path="C:/ti/ccsv6/tools/compiler/arm_15.12.3.LTS/include" --include_path="C:/ti/Hercules/SafeTI Diagnostic Library/2.3.1/libs" --include_path="C:/ti/Hercules/F021 Flash API/02.01.01/include" --include_path="C:/ti/Hercules/F021 Flash API/02.01.01" --include_path="C:/ti/Hercules/F021 Flash API/02.01.01/source" --include_path="C:/Users/walsan01/workspace/MiS210_HCG_CSP_1/DummyHet" --include_path="C:/Users/walsan01/workspace/MiS210_HCG_CSP_1/include" --include_path="C:/Users/walsan01/workspace/MiS210_HCG_CSP_1/source" -g --define=LDRA_ENABLED=1 --define=_LITTLE_ENDIAN --diag_wrap=off --diag_warning=225 --display_error_number --abi=eabi --enum_type=packed
Linker Options: --reread_libs --warn_sections --rom_model -me
Run time Library: rtsv7R4_T_le_v3D16_eabi.lib
CG Tool Root Path: C:\ti\ccsv6\tools\compiler\arm_15.12.3.LTS

Still get the same error.

Hope you can help

Regards

Andy Walsh

Hi Andy,

Please add the exact macro as I suggested.  Macro should be __little_endian__

I was bale to compile the your project HALCoGen_Lib with above setting.

Hi Vishwanath,
Sorry I didn't give you the full story. I tried adding the predefined symbols exactly as you prescribed, this failed to build so I tried to see where it was used and replicated the format I saw.. hence the change in the text in the previous email.

Do I have the correct / compatible version of the F021 Flash API ?

Below is the Build options file contents

"
Compiler Options:-mv7R4 --code_state=32 --float_support=VFPv3D16 -me --include_path="C:/ti/ccsv6/tools/compiler/arm_15.12.3.LTS/include" --include_path="C:/ti/Hercules/SafeTI Diagnostic Library/2.3.1/libs" --include_path="C:/ti/Hercules/F021 Flash API/02.01.01/include" --include_path="C:/ti/Hercules/F021 Flash API/02.01.01" --include_path="C:/ti/Hercules/F021 Flash API/02.01.01/source" --include_path="C:/Users/walsan01/workspace/MiS210_HCG_CSP_1/DummyHet" --include_path="C:/Users/walsan01/workspace/MiS210_HCG_CSP_1/include" --include_path="C:/Users/walsan01/workspace/MiS210_HCG_CSP_1/source" -g --define=LDRA_ENABLED=1 --define=__little_endian__ --diag_wrap=off --diag_warning=225 --display_error_number --abi=eabi --enum_type=packed
Linker Options: --reread_libs --warn_sections --rom_model -me
Run time Library: rtsv7R4_T_le_v3D16_eabi.lib
CG Tool Root Path: C:\ti\ccsv6\tools\compiler\arm_15.12.3.LTS

"

The only thing that I am not sure of is the include path for the Flash API library code. The library code appears here

C:/ti/Hercules/F021 Flash API/02.01.01 ... should this be in a library folder ? ie
C:/ti/Hercules/F021 Flash API/02.01.01/lib
The compile fatal error only appears in Cancel.c file compilation...

Thanks for your continued support

Regards

Andy Walsh

Hi Andy,

Were you able to compile the project "HALCoGen_Lib" you have attached to this thread?

My settings are below:

-mv7R4 --code_state=32 --float_support=VFPv3D16 -me --include_path="C:/ti/ccsv7/tools/compiler/ti-cgt-arm_16.9.0.LTS/include" --include_path="C:/ti/Hercules/F021 Flash API/02.01.01/include" --include_path="C:/Users/a0132218/Downloads/HALCoGen_Lib/include" -g --define=__little_endian__ --diag_wrap=off --diag_warning=225 --display_error_number --enum_type=packed --abi=eabi

I'm attaching the log file.5633.CompileLog.txt

Hi Vishwanath,

I will be returning to this task in order to complete it for the certification effort.

So I started a new project in ccs, generated the Halcogen code, configured the project properties - includes  device  etc  and yes the Halcogen code compiles

I then move to the TAU,  Add the Pre define LDRA and attempt to run the TAU. The build fails. From what I can see you have compiled the Halcogen code but not run the Tau which incorporates the LDRA test harness etc which appears to cause the build error. Could you have a look at that ?

Regards

Andy Walsh

Hi Andy,

I will recretae this issue using TAU and come back to you.

Hi Andy,

Kalaiyarasan was able to compile successfully with following build options. Can you check if you have same settings as below in your buildOptions.txt file?

Compiler Options: -mv7R4 --code_state=32 --float_support=VFPv3D16 --abi=eabi -me -g --diag_warning=261 --diag_warning=118 --diag_warning=225 --diag_error=189 --diag_error=994 --diag_error=551 --display_error_number --enum_type=packed

Linker Options: --reread_libs --warn_sections --rom_model -me
Run time Library: rtsv7R4_T_le_v3D16_eabi.lib
CG Tool Root Path: C:\ti\ccsv8\tools\compiler\arm_5.1.8
DependencyLibraryStart:
"C:\ti\Hercules\F021 Flash API\02.01.01\F021_API_CortexR4_LE.lib"
DependencyLibraryEnd
IncludePathStart:
C:\ti\Hercules\F021 Flash API\02.01.01\include
IncludePathEnd
SourcePathStart:
"C:\ti\Hercules\F021 Flash API\02.01.01\source"
SourcePathEnd

Hi Vishwanath,

Not sure if we are talking about the same thing. Yes I can compile the HalCoGen Code in code composer.

But when I take the Halcogen project and use the HalCoGen CSP certification tools  the compilation fails.

Do you have the log file so that I can understand what you compiled., For the LDRA test harness i would expect to see this in the list of files compiled

\inszt_ti_fee_cancel.c",

 

Regards

 

Andy Walsh

Hi Andy,

I have asked Kalaiyarasan to check this.