Tutorial for CCS + HalCoGen + SafeTI Library

Thank you for using the Hercules forum. One of our engineers will be with you shortly.

Hello,

the SafeTI Diagnostic Library release version 1.1.0 (available at http://www.ti.com/tool/safeti_diag_lib) includes a demo application built with HALCoGen for TI Tools (Code Composer Studio and TI compiler tools) which you can use as reference.

This version of the Diagnostic Library supports different Hercules MCUs - RM42, RM46, RM48, TMS570LS04x/03x, TMS570LS12x/11x, and TMS570LS31x/21x. During the install process you need to select the target(s) you will be working with (Select Components part of the install process) - this will install a demo application corresponding to your target(s) along with the diagnostic library in source and binary form.

The folder structure is described in the release notes accompanying the install (also available in docs folder of the install). The demo application CCS project is in the build\<device>_NoOS folder, source code is available in demo_app\common folder, and the device configuration using HALCoGen is available in demo_app\HALCoGen\<device>_NoOS folder.

You can use this demo application to explore the features of the SafeTI Diagnostic Library.

Please let us know if any further information is needed.

Thanks,
Girish Gajwani

Library Version 1.1.0: 

When I load project "SL_RM46L852_NoOS" in CCS5.4.0 and do a build, I get hundreds of warnings like "char *" cannot be used to initialize "const uint8 *".  

Furthermore, the linker tells me that section ".intvecs" does not have a SECTIONS specification.

Question:  How can I compile the project with no warnings?

Does anybody have a solution?

Or was anybody successful in opening the demo projects of Version 1.1.0? 

Frank,

I tried downloading the example today and building, and I see > 131 warnings.

While most of them seem like no big deal - about 100 of the warnings are just from the use of the character string to initialize the type 'unit8 *'... you can easily fix this by changing the array to char *.  (the return value is cast to uint8 * anyway).

Another group seems to be 'declared but not referenced' and these 16 warnings seem to be there because the code that would reference is disabled with #if 0 for some reason.  These don't bother me that much.   Same goes for the 3 'set but not used' warnings.

The duplicate typdef of t_isrFuncPTR seems like something that needs to be in a header file.  I am guessing this is a duplicate because there is a mix of HalCoGen stuff and SL stuff, but since the duplicaiton is compatible I don't think this is harming anything.

The implicit declaration warnings for "SL_FLAG_GET" and "_SL_HoldNClear_nError" can be fixed by including 'sl_priv.h' in the source files that reference them, but if you do this then you get additional warnings due to some incompatible redefinitions of BF_GET, BF_SET, BIT_MASK  and GET_ESM_BIT_NUM macros.   So I don't see a clean soluton to this one but it looks like something that could be sorted out eventually.

The ones that bother me the most are the .intvecs warning - the halCoGen source that has the vector table , sys_intvecs.asm - outputs the vectors to .intvecs.   And it's linker file which isn't included in the project has the correct name.  I'm not sure why the SL_RM46L852_NoOS_sys_link.cmd linker command file renamed this section but I think if you don't put it back then you won't get code that works from a power-on standalone.

Also the '#548 D warning about the switch statement bypassing initialization of testIterations and iTestCycle.  I don't think this causes a problem because the only references to these variables are within the same case statement that initializes them;  but this is some complex looking code.

Anthony,

thanks for this verification and crosscheck.

Of course most of the warnings can be fixed, but shouldn't they be fixed by the programmer of the demos? Can you internally ask the owner/producer of this code about some comments?  The discussion here is about "Safety" - and a minimum of simple software quality management  is that warnings are to be removed.

Regards

Frank

Frank,

I'll assign this to the library owner (Girish).

If you look at the warnings quickly - it looks like they're mostly trivial and belonging to the application example not the library.   But as you pointed out, there are few 'serious' warnings buried in the list which is I think a motivation to clean up even the trivial ones ... so the serious ones can't hide.

Hello,

as my colleague - Anthony Seely has pointed out above, most of the warnings are around the demo for the diagnostic library. However, we agree that warnings shouldn't exist (unless justifiable), especially in a safety software context.

We will take an action to fix the warnings as applicable - please await a new release which will fix issues.

In the meantime, you may continue to use/evaluate the diagnostic library and the demo software using the current version - we do not envisage any functional issues in this release.

Apologize for any inconvenience caused.

Thanks and best regards,
Girish Gajwani