I have found severe defect inside ARM cor Cortex-M3 compiler. It occurs only in release build.
And this is compilation result. Only 8 bytes is cleared, by using STR.
0x00013F06 F88D5008 STRB r5,[sp,#0x08] 23: UINT8 data[9];
64: continue; 65: } 66: 0x00013F42 E00F B 0x00013F64
67: memset(data,0, sizeof(data)); 70: 0x00013F44 9504 STR r5,[sp,#0x10] 0x00013F46 9505 STR r5,[sp,#0x14]
71: if(ReadBlockFromSRAM(data, addr, sizeof(data))) 72: { 0x00013F48 2209 MOVS r2,#0x09
=============================================================
When I use: x2 = sizeof(data); memset(data,0,x2);
It works fine.
Please ignore this post. It seems that last byte is cleared somewhere else.
0x00013F40 9504 STR r5,[sp,#0x10] 0x00013F42 9505 STR r5,[sp,#0x14] 71: if(ReadBlockFromSRAM(data, addr, sizeof(data))) 72: { 0x00013F44 2209 MOVS r2,#0x09 0x00013F46 4631 MOV r1,r6 0x00013F48 A804 ADD r0,sp,#0x10 0x00013F4A 9506 STR r5,[sp,#0x18] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0x00013F4C F7FDFB82 BL.W ReadBlockFromSRAM (0x00011654) 0x00013F50 B150 CBZ r0,0x00013F68 73: if(Err++>10) break;
I am not allowed to erase whole thread. Looks strange, that 4 bytes are cleared but is seems OK.
It could be that the last byte is indeed allocated and that no problem really exists. Actually, it smells like it - but further tests are needed to make sure nothing is placed at the 8th byte that is overwritten!
Tamir: 1) You shouldn't post your license key.
2) memset with value zero may be recognized by the compiler and handled specially, since the value zero is very special indeed.
Per,
Oops...
Just for cleaning things up. I am debugging I2C peripheral. And the I2C transfer fails only when transfer size is 9 bytes long together with release build. Debug build is 100% OK.
My failure is to suspect compiler that it is generating bad code. The most probable solution is that release code is somewhere faster.
Generally I love failures that manifests only in release builds. They are very hard to find.