This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

6727 internal RAM check

I wrote a function to perform the internal RAM check of DSP 6727 in C. But the problem is it can not test the stack section and the section of this test code reside. But I need to test every RAM used.

Anyone know how to solve this problem?

Thanks

Honghui Qi

  • Hi,

    Try to run your RAM test code in external DDR and start to test internal RAM.

    You can modify the linker command file of CCS to run the code at DDR.

  • Thanks.

    Actually, my application does not have external RAM available, so that could not solve the problem.

  • Hi,

    Then, I think you can't test the RAM location where the code reside and runs.

  • Honghui Qi,

    It is important to understand how your memory test program written in C will be used. In a system that has no external RAM, it would be unusual for an actual application to devote a section of internal RAM to testing that internal RAM, because there may be more need for that internal RAM for the application code and data. You see how I must make assumptions without more detail, yet.

    One solution is to have two projects with the same program but with different linker command files. The first linker command file will place the program and stack in the lower half of the internal RAM and allocate the upper half to be tested. The second linker command file will place the program and stack in the upper half of the internal RAM and allocate the lower half to be tested. This will allow you to load one project's .out file and test one half, then load the other project's .out file and test the other half.

    Regards,
    RandyP

  • Randy,

    I believe I understand your solution. Your solution assumes first half memory where the application codes reside is good. I am not sure whether we can make such assumption. Also it will double the bootload  time since it needs load twice. The good point of this solution is it tests every RAM.

    let's back to what I did.

    What I did now is to place the test codes into a specified section and the real application codes in different sections, therefore I can not test the test code section and the stack section, since the test code used the stack too. I can test all other RAM location.

    I know the method I used now is unable to test the RAM test code reside. But I hope it can still test stack section, so I am assured all RAM my real application code used will be good assuming the RAM where test code reside is good.  So the RAM test code shall be written to not use stack section. One method came to my mind is to add register key word in front of every local variable of the test code. I do not know if it works, not try yet. do not know what is the risk. Do you have better ways?

    Also I want to know if test code is written in assembly language and executed before C codes start, will it have miracle? I do not have experience on assembly code.  

    Thanks for help and suggestion.

    Honghui

       

  • Honghui,

    TI fully tests our devices in a much better way than anything you are doing in your application. The probability of a memory failure is low, and the static testing you are doing does not catch all possible errors that can occur - our testing at the factory did a better job before the device was shipped to you.

    So it is important to understand why you need to do this, and exactly what problem you are trying to solve by running this test?

    If you cannot assume the first half of memory is good then you cannot run a test program using internal memory.

    honghui Qi said:
    Also it will double the bootload  time since it needs load twice.

    If this doubles the bootload time, then this is the only thing being bootloaded. That implies there is no application. So you can see my confusion about this exercise.

    The 'register' keyword will not do what you assume it will do. It will offer guidance to the compiler but the compiler will do the best job of optimization that it can do even if that means using stack space.

    A better way can only come from a fully holistic understanding of the application and the need for this test. You cannot do a destructive test on the part of memory you are using. And testing the RAM area does not tell you anything about the other logic gates in the peripherals or in the DSP core, or the dMax, or the I/O pins.

    Regards,
    RandyP

  • Randy,

    Thank you for your reply.

    This is helpful. It confirms what I can do in the current design and tells me I should not spend more time on it to find a solution using my current design.

    The RAM test requirement comes from top manager, we have no way to object. So I try my best to do this function well. That is why I seek help from you and hope there is a miracle way.

    BTW: The method I mentioned using register keyword was unsuccessful and I also tried other different ways for test codes not to use stack section, none is successful.  

    Honghui

  • Honghui,

    What is your bootloader method?

    To avoid using stack space, do not use any local variables or function calls. Only use global variables and code in main().

    Regards,
    RandyP

  • Randy,

    The bootloader method is SPI slave.

    I tried to use global variables for the test code, but did not eliminate function call, also did not place it in main(). That is why it was unsuccessful.

    Can I use inline keyword to achieve the same as to not using function call?

    Honghui  

  • Correction: Called it in main(), but has function calls within the test codes

  • Honghui,

    Try any compiler options and keywords and switches you want to, and see if you get the results you want. I can make no promises. The compiler is not designed to avoid stack use.

    Regards,
    RandyP

  • Randy,

    I spend many hours today and find out that the compile look ignore the key word inline, I saw the stack section is used whenever it is called no matter it is inline function or not. maybe just like you mentioned it is not promised.

    Based on my observation, I came up a method to write a function to just test that stack section alone, that function return void, no argument input, and no subroutine called, no local variables. I just finished this try and found it works. So the stack section can be tested. Other sections of memory test can be performed with no requirements as above. 

    All memory test codes and related data are placed in a section, therefore only this section is not tested.

    Based on your method to bootload twice to test memory alternatively, I think we can write second test code to cover first test code memory section only . The second test code can reside in the same section as application codes. After the first test code finished, then call second test code to test the first test code memory section. From that sense, we tested every memory location, just bootload once and code size is increased a little bit -- I will try it out. 

  • Honghui,

    Excellent work. Please let us know how it works for you.

    After you find success, please post your method for loading the two test codes, and your memory test code, if you can do that. It will help the Community for future tests on this and other DSPs.

    Regards,
    RandyP

  • Randy,

    I did a try with two test codes. That works to me. Thanks for your help. The final method is formed through the discussion with you and many tries. I am appreciate your time to discuss with me. Thanks.

    In the next post, I will summarize the method I used. Hope that would help other community members.

    Honghui Qi

  • Re: DSP6727 internal RAM test method

    The goal is to test every internal RAM location inside DSP6727. It is part of an application codes and will run on every power on. The method used is to write two sets of memory test codes. The first set of the test code perform all memory test except the sections the first test code and its data reside. Let's call it TestCode and TestData sections.  #pragma CODE_SECTION () and # pragma DATA_SECTION () are needed to place the first test  code and data into that section. Make sure the first set of test code and data use only defined sections(TestCode and TestData) and stack section, no other memory is involved. The second set of test code is written to test the sections of TestCode and TestData. This second test code is placed in other memory sections, could be the same section as other application codes, but make sure the second test code and its associated data will not use any memory locations of TestCode and TestData.

    As for the first test code function, the challenge part is to test the stack section. a special function is written to just test the stack section, let's call it void StackMemTest(void). That stack memory test function must be return void, no input argument, no subroutine called within and no local variables. All variables need by this function are declared as global variables and use #pragma to place them into TestData section. The point is StackMemTest() can not use any stack memory at all. All other function of the test code can freely use the stack section.

    As for the overall memory test method, divide memory into blocks, test block by block. within a block test, copy what in the block to a backup block, then write patterned data into the block. finally read back the data and compared. if data readout is different than what it is written, then it declares fault, otherwise all good. the final step is to copy back from backup block to this block, so memory content is not altered. For the detailed method, you may reference   TI's spra838a for C6416  section 2.2 Internal memory part only. That is what I referenced.

    Hope that help.

    Honghui Qi