Using the IEC60730 F2833x RAM test (SafeTI™ software packages)

Hi Stephen,

Please see the answers to your questions below.

1. MARCH RAM test is a destructive test. It modifies the original content of the RAM. User is responsible for backing up the contents before calling the STL_MARCH_TEST_testRam routine. The STL_MARCH_TEST_testSafeRam routine however is to be used for specific types of RAM only as outlined in the user's guide. This API restores back the original contents of the safe ram regions being tested.
2. The range of RAMs we test are often greater than the number of available registers. Hence we can't save contents of RAM into registers.
3. STL_MARCH_TEST_testSafeRam routine however is to be used for specific types of RAM only as outlined in the user's guide. It is not to be used for RAM regions that are not designated as safe ram regions in the guide.
4. PC_TEST_1 and PSA_CRC are safe RAM regions whose contents is critical to the safety library - hence their original value should be restored after those ram regions are destructively tested.
5. There is a sample project that ships with the safety library to showcase the use of the safety library in a simple application. It comes with a command linker file and critical sections that shouldn't be changed. Please refer to those and the , Using the IEC60730 STL, section of the user's guide. 
6. You can test any RAM areas(RAM1 , RAM2 , and any others ...) using STL_MARCH_TEST_testRam unless they are specified as safe ram regions - in which case you would be using the STL_MARCH_TEST_testSafeRam routine. But note that STL_MARCH_TEST_testRam is a destructive test and you should be backing up your test regions.

Thanks

Noah

2. The range of RAMs we test are often greater than the number of available registers. Hence we can't save contents of RAM into registers.

     I realized the range of RAM tested is large, however, is it necessary to fill the RAM first with zeros or all ones?  Can't you just do the following for all memory areas:

             register = memory location

             memory location = 0

            if ( memory location == 0) then ok, else fault

However, there may be a reason for filling the memory first that I am not aware of, i.e. the march test specifically requires it to test address lines or memory in some way.

4. You can test any RAM areas(RAM1 , RAM2 , and any others ...) using STL_MARCH_TEST_testRam unless they are specified as safe ram regions - in which case you would be using the STL_MARCH_TEST_testSafeRam routine. But note that STL_MARCH_TEST_testRam is a destructive test and you should be backing up your test regions.

       Ok.  If I am only using the simple STL_MARCH_TEST_testRam and no other parts of the the safety library, can I test all of the TMS320F28335's RAM.   Do you see any problem with testing any RAM in the following range:

                             0x0000 - 0x1FFF
                             0x5000 - 0xFFFF

        I am particularly concerned about RAM marked as protected, but I am concerned about any issue with writing to any RAM address. 

Thanks,

Stephen

Also, I am using an example file named CodeStartBranch.asm (see below).  I don't think  STL_MARCH_TEST_testRam uses the stack, so I think it should be ok to call a function that calls STL_MARCH_TEST_testRam from that point in the code (i.e. in CodeStartBranch.asm).  Is that correct?

***********************************************************************
* File: CodeStartBranch.asm -- File for Labs 5, 6, 7, 8, 9, 10 and 12
* Devices: TMS320F2833x
* Author: Technical Training Organization (TTO), Texas Instruments
* History:
*   07/15/08 - original
***********************************************************************

WD_DISABLE	.set	1		;set to 1 to disable WD, else set to 0

    .ref _c_int00
    .global code_start

***********************************************************************
* Function: codestart section
*
* Description: Branch to code starting point
***********************************************************************
    .sect "codestart"

code_start:
    .if WD_DISABLE == 1
        LB wd_disable       ;Branch to watchdog disable code
    .else
        LB _c_int00         ;Branch to start of boot.asm in RTS library
    .endif

;end codestart section


***********************************************************************
* Function: wd_disable
*
* Description: Disables the watchdog timer
***********************************************************************
    .if WD_DISABLE == 1

	.text
wd_disable:
    SETC OBJMODE            ;Set OBJMODE for 28x object code
	EALLOW					;Enable EALLOW protected register access
    MOVZ DP, #7029h>>6      ;Set data page for WDCR register
    MOV @7029h, #0068h      ;Set WDDIS bit in WDCR to disable WD  
	EDIS					;Disable EALLOW protected register access
    LB _c_int00             ;Branch to start of boot.asm in RTS library

    .endif

;end wd_disable
***********************************************************************


	.end                    ; end of file CodeStartBranch.asm

4. STL_MARCH_TEST_testRam should be used only for data and program memory. The protected RAMs contain memory mapped registers. You should not be using the routine to test those areas. 

  Whoops..your exactly right. Those are memory mapped to the peripherals.

Thanks

Hello Noah,

POST (Power-on Self Tests) should occur right after reset, however, the current version of the STL Library can only be used after the stack pointer is initialized.  That may not be be too bad if the boot code from the run time library was integrated with it in some way.  

Is the STL Library going to be updated to be more usable for POST?  Also, is/are the person/people working on the STL in the process of adding any new features or fixes?

Stephen

Hi Stephen,

Right after reset the boot-rom kicks in. Right now the boot-rom doesn't do a march test and we can't add a code between reset and boot-rom as the boot-rom is hardwired. And as of now there is no plan to include the ram test in boot-rom.

You can contact me regarding any bugs or issues on the library. We currently don't have any plan to add new features.

Thanks

Noah