We have found a strange core behavior as a result of some unexpected test failures. It appears that an STRB to [SP+1] immediately followed by an LDR from [SP] loads the word value at [SP,SP+1] from before the STRB!
I have been able to isolate the behavior to the following C code snippet.
#include <stdio.h>typedef struct{ char status; char value;} UInt8Result;int main(void){ UInt8Result resultA = { 1, 0x00 }; UInt8Result resultB; char temp = resultA.status; resultA.value = 0xFF;// asm("LDRB R0,[SP, #+1]"); resultB = resultA; printf("A: Status: %d, Value: %d\n", resultA.status, resultA.value); printf("B: Status: %d, Value: %d\n", resultB.status, resultB.value); printf("temp: %d\n", temp); return 1;}
The assignment of resultA to resultB should leave the two structures identical, but the console log reports the following:
A: Status: 1, Value: 255B: Status: 1, Value: 0temp: 1
Uncommenting the assembly instruction generates the expected value for resultB:
A: Status: 1, Value: 255B: Status: 1, Value: 255temp: 1
We are using the LM3S9B92 Rev C5 part on several custom boards. The C code is compiled with the IAR C/C++ Compiler for ARM [version 6.10.2.52244].
Here's the assembly generated by the compiler:
SECTION `.text`:CODE:NOROOT(1) CFI Block cfiBlock0 Using cfiCommon0 CFI Function main THUMB// 13 int main(void)// 14 {main: PUSH {R2-R4,LR} CFI R14 Frame(CFA, -4) CFI R4 Frame(CFA, -8) CFI CFA R13+16// 15 UInt8Result resultA = { 1, 0x00 }; ADR.W R0,`?<Constant {1, 0}&rt;` LDR R0,[R0, #+0] STR R0,[SP, #+0]// 16 UInt8Result resultB;// 17 // 18 char temp = resultA.status; LDRB R4,[SP, #+0]// 19 resultA.value = 0xFF; MOVS R0,#+255 STRB R0,[SP, #+1]// 20 // 21 // asm("LDRB R0,[SP, #+1]");// 22 // 23 resultB = resultA; LDR R0,[SP, #+0] STR R0,[SP, #+4]// 24 // 25 printf("A: Status: %d, Value: %d\n", resultA.status, resultA.value); LDRB R2,[SP, #+1] LDRB R1,[SP, #+0] ADR.W R0,`?<Constant "A: Status: %d, Value:...">` BL printf// 26 printf("B: Status: %d, Value: %d\n", resultB.status, resultB.value); LDRB R2,[SP, #+5] LDRB R1,[SP, #+4] ADR.W R0,`?<Constant "B: Status: %d, Value:...">` BL printf// 27 printf("temp: %d\n", temp); UXTB R4,R4 ;; ZeroExt R4,R4,#+24,#+24 MOVS R1,R4 ADR.W R0,`?<Constant "temp: %d\\n">` BL printf// 28 // 29 return 1; MOVS R0,#+1 POP {R1,R2,R4,PC} ;; return CFI EndBlock cfiBlock0// 30 }
With the LDRB assembly instruction inserted, the 'LDR R0,[SP,#+0]' instruction loads 0x0000FF01 in to R0 as expected.Without the assembly instruction (line 21), the 'LDR R0,[SP,#+0]' instruction loads 0x00000001 in to R0, apparently missing the prior STRBFurthermore, (again without the assembly instruction), if I set a breakpoint on the LDR instruction and single step over the it, R0 is loaded with 0x0000FF01. If I set the breakpoint after the LDR instruction, R0 is again incorrectly 0x00000001.
Could this be a cache or pipeline problem? I've tried inserting a 'DMB' or 'DSB' instruction between the STRB and the LDR, but the results are the same. It appears that only an LDRB with a non-zero immediate offset from SP restores the expected behavior. Note: the debugger reports that SP is correctly long word aligned. I haven't been able to find any errata referring to this problem.
Can someone let me know if this is a known problem or if I am doing something wrong? If not, can anyone suggest a workaround?
Best Regards, Mike
We have confirmed this is a problem with multiple LM3S9B96 boards and on a Stellaris EKI-LM3S9B92 eval board.
The same code behaves correctly on an LM3S8962, so it seems to be pretty clearly a core problem, possibly on all Tempest class chips.
I suspect that the core is overlapping the half-word write to [SP, #+1] with the word read from [SP,#+0], not recognizing that the data range of the read overlaps the write.
Can someone from TI confirm that they are investigating this? This has the potential to cause severe data corruption.
Regards, Mike
Mike,
Thank you for the detailed write-up. We're looking into it.
On the EK, how have you configured the system clock? Ie., what speed do you think the core is running at?
Thanks,--Miles
Mike Attili1 STR R0,[SP, #+0]
What is the value of SP throughout this code?
--Miles
Miles,
Thanks for looking in to this.
I believe the clock is typically running at 50MHz in our application code where this problem was first identified.However, the simplified code above is running right out of reset without any system config other than that provided by the default IAR C runtime.
The value of SP through this code is 0x20000450.
I've attached the build output below so that you can see the options selected. I've tried to make this as vanilla as I can. The file TestSoftwareTimerRunner.c simply contains the program text from the original post.
Please let me know if you need any additional information to reproduce the problem.
Mike
---------------------------------------------------------------------------
Updating build tree... TestSoftwareTimerRunner.c iccarm.exe Source\TestSoftwareTimerRunner.c -lA Source\Debug\List\ -o Source\Debug\Obj\ --no_cse --no_unroll --no_inline --no_code_motion --no_tbaa --no_clustering --no_scheduling --debug --endian=little --cpu=Cortex-M3 -e --fpu=None --dlib_config C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.0\arm\INC\c\DLib_Config_Normal.h -On IAR ANSI C/C++ Compiler V6.10.2.52244/W32 for ARM Copyright 1999-2010 IAR Systems AB. 158 bytes of CODE memory Errors: none Warnings: none Linking ilinkarm.exe Source\Debug\Obj\TestSoftwareTimerRunner.o -o Source\Debug\Exe\TestSoftwareTimer.out --redirect _Printf=_PrintfLarge --redirect _Scanf=_ScanfLarge --map Source\Debug\List\TestSoftwareTimer.map --config C:\Program Files (x86)\IAR Systems\Embedded Workbench 6.0\arm\CONFIG\generic_cortex.icf --warnings_are_errors --semihosting --entry __iar_program_start --redirect __write=__write_buffered --no_exceptions IAR ELF Linker V6.10.2.52244/W32 for ARM Copyright 2007-2010 IAR Systems AB. 6 288 bytes of readonly code memory 44 bytes of readonly data memory 1 116 bytes of readwrite data memory Errors: none Warnings: none Link time: 0.03 (CPU) 0.03 (elapsed) TestSoftwareTimer.out Converting ielftool.exe --bin --verbose Source\Debug\Exe\TestSoftwareTimer.out Source\Debug\Exe\TestSoftwareTimer.bin IAR ELF Tool V9.8.0.27 [BUILT at IAR] Copyright 2007-2010 IAR Systems AB. Loading Source\Debug\Exe\TestSoftwareTimer.out Saving binary file to Source\Debug\Exe\TestSoftwareTimer.bin Total number of errors: 0 Total number of warnings: 0
I have found that the problem is also present on a word store followed by a long word load, so it is not limited just to byte accesses. The problematic sequence of instructions in this case is:
LDRH R4,[SP, #+0] MOVS R0,#+255 STRH R0,[SP, #+2] LDR R0,[SP, #+0]The 'LDR R0,[SP,#+0]' instruction loads a stale value in to R0. R0 should contain 0x00FF0001, but instead contains 0x00000001.
Have you been able to reproduce and confirm the problem? I have attached a zip file containing a pre-built test project (using IAR tools) that exhibits the problem with word accesses.
This seems to be a very significant bug in the LM3S9B92 processor, at least. As you can imagine, this could have significant impact on our project and prompt support from TI is critical for us. I would appreciate you keeping me informed on your progress.
Best, Mike
Since I haven't heard anything from TI for a week, I've continued to do further investigation of this problem.
The error occurs under the following conditions:
- It doesn't matter if a DMB or DSB instruction is inserted between steps 2&3 or steps 3&4.- It doesn't matter if other instructions are inserted between steps 2&3 or 3&4, so long as - they don't load from or store to A, and - they don't modify the register pointing to A and then load from or store to that address
I hope that someone from TI is able to confirm this bug and update the errata so that the compiler vendors can develop appropriate work-arounds. I would appreciate confirmation, at least, that they are still investigating.
Note: I have updated the title of this thread to more accurately reflect the nature of this problem.
Thank you for your thorough investigation, this has greatly helped in the validation of what you are seeing. I wanted to let you know that this has been confirmed on our end and that we are investigating this further and exploring next steps.
I will be updating this thread as more information becomes available.
-Dave
Thanks Dave,
Glad you are able to confirm this problem. Look forward to the results of your investigation.
Dave,
It's been two weeks since your last message. Do you have any updates or an ETA on errata for this processor bug?IAR will not address a compiler workaround to this problem without errata from the foundry.
Do you know, at least, which devices or device families are affected? It may not be too late for us to switch processors. I'd prefer not to have to switch to another vendor, but need more information from TI to support that.
Thanks, Mike
We are still working on finalizing the errata description and workaround, but I can give you an update:
You can identify which Stellaris MCUs have this problem by comparing which devices also have μDMA. The problem is not caused by the presence of uDMA, but you can use the parametric search on μDMA to determine if a part is affected by this erratum or not.
What specific device capabilities are you using on your 9B92 processor?
Also, while validating the erratum, I found that IAR with medium optimization does not exhibit this behavior. I’m not sure how this optimization setting would affect your code, but you could try it out as a potential workaround.
Please let me know if you have further questions.
For our application I need at least 128KB Flash, 50 MHz, Ethernet, 2 QEI, 2 I2C, 4 PWM, 8 ADC, and a fair amount of GPIO. All of the matching parts in the Stellaris Cortex-M product search page indicate that they support 32 DMA channels. I think that means all of these parts are subject to this erratum. The closest match appears to be the LM3S6965 (but that's light on ADC channels).
I can look in to whether we can off-load or multiplex some of the A/D if you can confirm that the LM3S6965 part does not exhibit this bug.
I've modified the test application to use medium optimization and I still get the failure. I suspect that since medium optimization permits code motion, that this might prevent the problem from occurring in some instances, but it's not a solution for us.
The most helpful thing you can do for me right now is to provide some estimate of the amount of time before the errata will be released. Simply a coarse estimate of days/weeks/months would help a great deal.
Correct, the LM3S6965 will not exhibit this bug.
When you tested your code with the medium optimization level, were you attached to the debugger or free running? If you were attached to the debugger, it may be worth trying it without as IAR disables many optimizations when debug is enabled.
As far as a coarse estimate for when the errata will be released regarding this bug, I would say that something should be released by the end of the month.
Can you provide any update on the progress for errata addressing this bug? There has not been an update since this was reported and confirmed. IAR will not provide a compiler workaround for this problem until TI releases the errata.