Memory check in msp430f5

rani rao said:

would like to know if following method for RAM check is correct

"correct" to what end?

Before designing a memory test, you need to know what kind(s) of fault(s) you need to detect. For code and a detailed discussion of memory testing - including the types of faults that commonly occur, and ways to detect them -  see: http://www.netrino.com/Embedded-Systems/How-To/Memory-Test-Suite-C

Note that most reasons for doing a memory test aren't really applicable to the internal memory of a microcontroller!

Hi Andy!
How come you are writing in the MSP forum? Or has someone moved this thread from Stellaris?

Anyway, I fully agree. A ram test is not necessary and mostly futile on internal RAM of a MCU.
It might have some use if you are writing a generic library that doesn't know of the available ram and needs to check its existence. If provided in source code, this could be more generic and portable than using the (varying from compiler to compiler) existing symbols for data segment start and RAM end (stack start).

However, this would be very, very specific and a rather constructed justification for a RAM test.

Also, I agree that even if a RAM test should be necessary for some reason, deep knowledge about organization of teh ram and scuh is required or thw test will miss many possible errors.
And I know what I'm talking about - some 25 years ago I wrote a ram test for the expanded 1750 memory expansion for the C64. There the test did have a purpuse: to detect and location possible shortcuts or dead signals and even defective ram parts after I soldered additional whopping 1.5MB ram to the DMA ram expasion which was designed for 512kB only. It took me weeks to design the test - and saved me even more time when testign the units after production.

However, MCUs already are tested by the manufacturer and wont ship if the ram isn't okay. And since everything is embedded, there is no possible cause (except extreme mistreating, which surely would affect more than just the ram) for a ram failure after the device passed the manufacturer test.

Jens-Michael Gross said:

How come you are writing in the MSP forum?

Because the nice people at TI have sent me some MSP toys to play with - sorry, "evaluate".

:-)

And this is actually a pretty generic question (and answer) - I first used Michael Barr's code (cited above) on an 8051 about 10 years ago!

Anyhow, perhaps you'd care to comment on this question: http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/471/t/135410.aspx

Cheers,

Andy.

Andy Neil said:

perhaps you'd care to comment on this question:

As an extension to my answer there: I did create my own sort of driver library. It is, however, configured by a project specific include file and compiled togehter with the application. This way it includes only the exact code needed, optimized for this MSP (or AVR, as we use them too and the framework covers both) and the required funcitonality.

However, some things are easier programmed directly than configured in a generic way.
This includes the size of available ram (to be back on topic :) )

I fully agree that  MCUs already are tested by the manufacturer and wont ship if the ram isn't okay.  But as a requirement supposed to do RAM test even incuding the stack area.  The C language requires the use of a stack, which requires memory.

I read that one method :

One way to do this is to force code to operate in one chunk of RAM and test the rest of the RAM. Then, move the code RAM into another chunk and test the old chunk out of which the program executed.

Second Method:

During the test, interrupts are disabled. A few variables are declared as "registers", just in case the compiler decided to use regular RAM. We then test every word in RAM (easier and just as fast to do 16-bit words) by reading it back into the register variable, writing a test pattern (the one's complement of the address) to the word, reading it back and comparing it to the 1's complement of the register variable.

I would like to know by which method i should proceed or any other method is suitable. Or do the test to be implemented in function, before control comes to main.

Sorry for creating new thread, since i didnt get a solution. As per Firmware flow , I need to implement ram test including stack area using IAR, then that before main.

I also read that _low_level_init function, already stack is initialized.

Do I have to modify in cstartup.s43 file:

 Custom function to do :

Disable watchdog

write 0x00, 0xaaaa,0x5555 values and check .

Also I need to glow the leds if ram check as done above, fails.

Using assembly code from ram strt address to end address can i write above values and read back.Can i access port pins at this level?

Thanks for the help in advance

rani rao said:

i didnt get a solution

Simply ignoring the input you've had so far is not going to improve your chances!

Again, you didn't answer the question:

I said:

But you just agreed that the test is pointless - so why do it at all?!

It's impossible to give appropriate replies if you can't clearly explain what you're trying to achieve here!

http://www.catb.org/~esr/faqs/smart-questions.html#goal 

I need  to do a ram-test and also indicate error by glowing led before the main-function of my program starts. How to implement this using IAR Emb workbench?

But why do you say that you "need" (sic) to do a RAM test?

You yourself have already agreed that such a test is pointless - so why do it at all??!

rani rao said:

I need  to do a ram-test and also indicate error by glowing led before the main-function of my program starts. How to implement this using IAR Emb workbench?

That someone is not making any sense. Yet you can still do it to full fill this requirement. You can ignore what was already in the stack and do not use any RAM for variables. You can "test" all the RAM, show the result with LED, and put CPU to sleep.

old_cow_yellow said:

I do not think you need to do ... I think somebody requires you to do that

You are probably right.

But, if the OP works in an organisation that has such a requirement, surely there should be sufficient experienced staff there to be able to do this?

If they are developing such "safety critical" systems that such requirements are warranted, but don't have suitably experienced staff - that is surely of far greater concern...?!!