IEC 60730 selftest library on TMS320F28062x targets

Lori,

Thanks for the response. I do agree with you that the lib is built for 28069 which is the superset of the 28062 I use. The lib is just inconsistent, as it does select 28033/28035 from 2803x family that have CLA whereas it does not do this distinction for the 2806x family --> see snippet in my first post. Seems to me that smth has been ignored here :-)

take this to the missing feature list for future lib releases, for now I am fine with adapting the source.

BR Andreas

I have entered this into bug tracking.

Regards
Lori

Thanks a lot Lori. Btw I have a couple of other possible incidents. Shall I post them into the forum or would you prefer to get into (private) contact

Please post them. Others may benefit from the discussion.

Lori,

The same is true for VCU support. VCU checking is globally enabled for all 2806x targets, but is only available on 28069, 28065 and 28064. Please add this as well to your IEC60730 Bugtracker.
Furthermore it would be very nice, if all the available devices would be present in the STL_system_config.h. It would certainly be less error prone if the device config comes from TI itself.
Thanks,
Andreas

Thank you Andreas. I will log these as well.

Regards
Lori

here comes another one:

In the file STL_register_test_patterns.c there is a compiler switch excluding all testpatterns except for SPI and PIE. Why is this? I think this should be removed.
And in addition testpatterns for the following registers are missing:
-System Power control registers
-Flash Registers
-ADC registers
-PIE vector registers
-gpio registers
-system control registers
-watchdog registers
-mcsp registers

BR Andreas

unfortunately it becomes nasty now...

in the File STL_register_test.c check the method STL_REGISTER_TEST_testPeripheralRegisters

If all the tests succeed, the EALLOW is not closed with an EDIS. Not very nice in a safety lib context, since this means all subsequent code will run with EALLOW protection turned off... MISRA forbids to have more than one return in a method, they know why.

uint16_t STL_REGISTER_TEST_testPeripheralRegisters(STL_REGISTER_TEST_registerTest_Handle registerTestHandle)
{
   
   uint16_t *pRegister; // pointer to register
   uint16_t originalValue; // contents of registers saved in this variable
   uint16_t registersCount; // maximum number of registers to be tested
   uint16_t testIndex; // register index counter
   STL_REGISTER_TEST_registerTest_Obj *registerTest = (STL_REGISTER_TEST_registerTest_Obj *)registerTestHandle;
   
   registersCount =  (uint16_t)(registerTest->pRegisterEndAddress - registerTest->pRegisterStartAddress);
   pRegister = registerTest->pRegisterStartAddress;
   testIndex = 0U;
   EALLOW;
   while(testIndex <= registersCount){
       // perform a write test only if register test pattern is 
       // a non-zero value.
       if((uint16_t)0x0000U != (registerTest->pTestPattern1[testIndex])){
         originalValue = *pRegister; // save original value
         *pRegister = registerTest->pTestPattern1[testIndex]; // write first pattern to register
         if(*pRegister != (registerTest->pTestPattern1[testIndex])){ // read back pattern from register
             *pRegister = originalValue; // try restoring original value
             EDIS;
             return(TEST_FAILED);        
         }
         *pRegister = (registerTest->pTestPattern2[testIndex]); // write second pattern to register
         if(*pRegister != (registerTest->pTestPattern2[testIndex])){ // read back pattern from register
            *pRegister = originalValue; // try restoring original value
            EDIS;
            return(TEST_FAILED);        
         }
         *pRegister = originalValue;  // restore original value
       }  
       testIndex++;
       pRegister++;
   }
   
   return(SIG_PERIPH_R_TEST);

}// end of STL_REGISTER_TEST_testPeripheralRegisters function

There are other issues with the peripheral register test:

in my opinion most of the prepared testpatterns are wrong - at least I cannot see how the spi testpattern should match the implemented SPI module register mapping, or for the epwm registers where the testpattern contains to many reserve at the end.... Can you please verify if the peripheral register code has been tested on a target. And if so on which target?

BR Andrea

any updates here??

BR Andreas

Hi all,

I need some sort of support here... Certified body starts to ask questions about the used library. Please some TI guy have a look at this

BR Andreas

Hi Andreas,

It looks like the message RAM is not available on F28062. It is also not available in the linker command file for your device, so it is not possible that you will have code or data in the message RAM block of addresses.

Therefore, this condition should always pass. You can either remove the check, being confident that STL_UTILITY_assertRamAddress() could never fail because nothing will ever be between 0x1500 and 0x157F (message RAM), or you can leave it. If you are nervous about changing the code, this change should not affect anything in your system, but you can still leave it.

Regards,
sal

Hi Andreas,

I also looked into the incorrect implementation for the register test for SPI.

You are correct, not all the writea-ble registers are mapped or tested in the register test for SPI.

For example, it is missing the SPITXBUF. I suspect this is because the bits of SPITXBUF in the TRM are labelled as Read-Only. The TRM is incorrect. The register test cannot write and read back to Read-Only registers, so it is likely that SPITXBUF was left out of the test due to this.

As a suggestion, the test register patterns can be modified to suit your needs. For example, you can test every write-able bit by writing a '1' to it and reading it back. Or you can simply write your configuration pattern to the register and read that back. Again, you could then periodically read back the patterns of the registers to ensure that they are correct and no bit flip has occurred.

Hope this help!

sal

Hi Sal,

Thanks for taking the time to answer this. It helps partly.
I am fine with excluding all tests that cover non exisiting peripherals/memory. I already modified the code and it works fine. I do understand, that the lib needs to be modified at this point, since you cannot know for which target the lib is used. However I found little support in the documentation for this. The Doc does cover the porting of the source code for other targets, but a lot is left out and must be discovered by every single user implementig the lib into a project/specific target. I hope this will be improved for future releases of the lib.

For the missing/wrong peripheral register test patterns however I do not agree to modify the source code by myself. Who could know the registers better than TI itself. Honestly I do not feel very comfortable gathering the necessary information out of the datasheet, knowing that this information is always subject of change. Here I really insist that you, TI must take care of this. And I am sure and certain that VDE/TUV would agree if asked.

Btw - I am really surprised that they agreed with this peripheral register tests as they are obviously incomplete. In their report they confirm the selftest library cover the standart IEC60730 for all 2806x/2805x/2803x/2802x targets... I doubt this completeness knowing the lib.

And last but not least - you did not answer the EALLOW/EDIS issue. I think this could be critical. The VDE report states that the lib follows MISRA rules. Having multiple returns in a function is a clear violation to MISRA, and I cannot see any comment justifying the exception. And the bug is here - or am I wrong? This should be fixed soon for your sake and for ours.

BR Andreas

Andreas,

The EALLOW/EDIS problem is clearly a bug. I agree. Multiple return points is a violation of the MISRA standard, but in my opinion this can be done safely and may be done well to benefit the system, especially considering the limited memory and MIPS of an MCU. I agree that there is no comment justifying this in the current 60730 Class B release. This should have been done.

Some peripheral tests do seem to be incomplete. However, the test strategy meets the 60730 standard. The approach to testing the registers meets the standard. I agree again, that this is a bug and there are some missed registers that are not being tested in the test patterns provided. The test patterns should have been more complete. But the test patterns were not certified, the software test strategy and implementation was. The source code and test patterns are provided to be modified by the system integrator as needed. The entire source code of the library is released to aid the system architect and integrator in performing safety related self-tests in order to meet 60730 safety standards. The library shows that with a safety library certification can be met. However, we should have made it more convenient and the tests more accurate to help you with that task. This was our first shot at implementing a safety library, and clearly some things were missed that could have easily been caught and improved.

We are taking much greater care in future releases of 60730 libraries and hope to fix these bugs for the current release.

Thank you for bringing all of these issues to our attention. Please continue to post any issues or questions to the E2E forum, they are very much appreciated.

Regards,

sal

Andreas,

I appreciate you reporting issues you are finding and also regret that they exist and are causing problems. The library is meant to assist the end developer in achieving IEC60730 compliance and as Sal mentioned may need to be modified for the specific use case. We are logging the issues and the team is learning from these mistakes.

The original developer is no longer at TI. I am working to figure out if registers being left out was done for a specific reason or if it was an oversight.

Regards
Lori

Hi Lory/Sal,

Bugs are part of our lives aren't they - I know this very well being long enough in business. In this specific case bugs and un- or underdocumented features, exceptions etc. are a bit more delicate since it is not only me that has to accept them but also a certified body that is spying over my shoulder during the product assessment. I think you can understand that this makes things a bit complicated. I understand your arguments and statements perfectly now that I have them. However I need an argumentation towards the certifier as you can imagine.

As you said in your last posts, documentation is unclear at certain points and that should really be fixed soon, to be more specific. Especially the section about porting the library. Likewise it would be helpful to know which parts of the lib exactly were assessed during the lib certification. Knowing this would haven given me confidence where I can change/adapt code and where I would need to be careful with changes. Might be I've overseen this but I spent quite some hours with the documentation

Apart from these points I really appreciate the existence of the library since I estimate the effort behind. I am sure that you will be able to even improve it, with the help of the community.

BR Andreas

Hi Andreas,

I believe some of the registers in SPI do not have register test patters despite being write-able because due to their functionality they would not read back the same value. For example, SPITXBUF. After writing to this register, the data should be shifted into a shift buffer preparing to be transferred. Similar behavior should exist for SCI and other communication peripherals.

I suspect for similar reasons some registers are not tested with test patterns for the PWM either.

In these cases the functional tests of the 60730 library such ask SPI Loopback test would cover these registers.

Can you find specific registers that do not have register test patterns and are write-able that do not fall into this category?

Regards,
sal

Hi Sal,

Here my feedback after implementing Peripheral Register Test for WD/SCI/SPI/EPWM/ECAP Registers. Following changes to the testpatterns were necessary:

For the Watchdog:
in the SCSR register there is a R/W1C register (WDOVERRIDE) this one is difficult to test. However this is not so important since the WD can be tested with its functionality

SCI
SCICTL2 reads back a 0xC from the reserved registers. Not sure if this is true for different piccolo flavours. However it must be covered by the testpatterns

SPI
SPIFFTX:TXFIFO reads back zero - reason is not yet clear to me. SPIFFTX:TXFIFOINT is a RO Flag. spruh18f is wrong here. Testpattern must be 0xA02A/0x4015


EPWM:
TBCTL:SWSYNC - this bit is only active when SYNCIN is enabled. Testpattern must be zero here
AQSFRC:OTFSB and OTFSA - these bits always read back zero. Testpattern must be 0x8a/0x51.
TZFRC: All bits read back zero. Testpattern must be zero.
ETPS:SOCBCNT and SOCACNT. Readonly bits. Testpattern must be zero.
HRMSTEP is written by SFO calibration routine and cannot be written by the user (AFAIK).Testpattern must be zero.
TBPRDM is a shadow register. Testpattern must be zero.
DCCAP is RO. Testpattern must be zero.

CAP
ECCTL2:REARM and ECCTL2:SWSYNC always read back zero. Testpattern must be 0x2a2/0x455

You owe me a beer ;-)

BR Andreas

Hi Andreas,

Thank you for looking into this and commenting.

Functional tests will be the only way to test certain registers as you have noted.

In the case of SCICTL2, "reserved bits" behavior is undefined so the pattern should be generated from a test as you have done.

SPIFFTX: TXFIFO will read back zero because the way only way to set those bits is to write to the TXBUF. The TXFIFO status will not increase by writing to those bits. They require that something be written into the TXBUFFER. Additionally, with the module disabled I doubt that that TXFIFO status bits will increase. Furthermore, with the module enabled, the data written to the TXBUF should be transmitted so by the time you read from TXFIFO, the status would have decreased. The only way to test the FIFO is with a functional test.

Thank you for taking the time to look into those registers and their test patterns.

I know this work can be tedious, I have done it on a couple different modules as a proof of concept for customers. It is important for each customer to determine which registers to test on power up and which to test in-system. This is why we only provide some basic templates. The test patterns depend on how they will be used by the customer. The test can be used to configure the registers and then test the configuration is correct periodically in system. Test patterns can be used to test every write-able bit, but that may also not be necessary for functional safety.

I appreciate your effort in finding all this data and documenting it here. Thanks you!

sal