Help on how to test RAM parity test for STM32F091VB micro controller.

I don't think there's any consistent method to forcibly invoke a SRAM error. The RM warns about the parity bits being at random value after power down/up for memory cells which were never written, you can try to use this but you can't rely on error to occur on any particular address, Some SRAMs tend to maintain previous state for a surprisingly long time, and have to be powered down hard (i.e. shorting out VDD to ground) to produce at least some "randomness".

JW

PS. Please change your username to a normal nick.

Thanks alot for the reply. But again considering the constraints my question about how we can rely the RAM parity check module is working fine if we enable the bit in option byte. Because by default all the status bits will be '0' and 'SRAM_PEF' bit will be still '0' even after normal execution. So we cannot conclude easily rather than theory that my RAM parity test is really passed or may be the case that module is enabled but RAM parity test is actually not done.

Will it be possible if be corrupt a particular memory like ZI or bss ?, if this will work please guide me how to do it.

Mithun

Hi Mithun,

As I've said, reading *uninitialized* RAM after a well-performed poweron (with VDD shorted to GND) should lead to SRAM parity error, but there's no guarantee it will.

I've tried and on my piece of 'F091 there appears to be a pretty high probability of parity error on reading uninitialized portion of SRAM:

(gdb) p /x SYSCFG->CFGR2
$11 = 0x0
(gdb) x 0x2000405C
0x2000405c: 0xe259de51
(gdb) p /x SYSCFG->CFGR2
$12 = 0x0
(gdb) x 0x20004000
0x20004000: 0x00000000
(gdb) p /x SYSCFG->CFGR2
$13 = 0x100
(gdb) x /40 0x20004000
0x20004000: 0x00000000 0x00000000 0x00000000 0x00000000
0x20004010: 0x00000000 0x00000000 0x00000000 0x00000000
0x20004020: 0x00000000 0x00000000 0xab9c3867 0x00000000
0x20004030: 0x00000000 0x00000000 0x00000000 0x00000000
0x20004040: 0x00000000 0x00000000 0x00000000 0x00000000
0x20004050: 0x00000000 0x00000000 0x00000000 0xe259de51
0x20004060: 0x00000000 0x00000000 0x00000000 0x00000000
0x20004070: 0x00000000 0x5f12c4e2 0x00000000 0x00000000
0x20004080: 0x9fbec3ca 0x00000000 0x00000000 0x00000000
0x20004090: 0x00000000 0x00000000 0x00000000 0x00000000
(gdb)

The first read, from 0x2000405C, appears to result in normal read, no parity error there. The second read, from 0x20004000 resulted in parity error. It appears, that - in undocumented way - reading of uninitialized SRAM with parity check enabled results in reading 0x00 when the parity error occurs (without removing power, I disabled parity error check, and then all this part of memory reads as pretty random, without the zeros. As you can see, reading uninitialized RAM in my case resulted in parity error in 3/4 of cases - I guess this is because the SRAM powers up in quite random pattern and that there are 4 parity bits per word, one for each byte.

JW

PS. Please change your username to a normal nick.

@Vincent Onde​ ,

Isn't this a nice idea for an AN of the "memories and systems" dozen? And the 'G0 has the memory parity in the same way, doesn't it. Yes, there's AN4750 , but that opens more questions than it answers then. And, I can't find nowhere answer to the particular question raised here, i.e. how to enforce or even passively test the parity check properly.

That AN then could also highlight the timer break on parity error feature, giving snippets examples to try. Also, ways to deal with NMI could be explored, e.g. the fact that interrupts might stop working (i.e. printf based on interrupt-based-UART or USB won't work) could be dealt with, again in snippets.

JW