Version 5.1 C51.exe generates code that randomly resets when compiled optimized level 9, favor size, unless all switch statements are replaced with if-then. This is on years-old stable code that recently outgrew its 32K boundary, which is why we had to optimize for size. No other change is made, and the code runs fine.
It's pretty easy to find the cause of a reset problem: set a breakpoint at address 0000h.
C51 V5.1 is over 10 years old. We're currently shipping Version 8. Maybe it's time for an upgrade?
Jon
Have the documented (and undocumented) optimizer issues been fixed in the new version?
Correction, we are running v7.2. have any optimizer issues been fixed since 7.2? Last week we traced the problem to address 0x2AAA in the lines below. It is setting DPTR=0xFF??, that is, high byte is 0xFF, and low byte is some random number, always different, then executing the JMP to that address. The code there is shown below the CCASE code that follows. C?CCASE: C:0x2A90 D083 POP DPH(0x83) C:0x2A92 D082 POP DPL(0x82) C:0x2A94 F8 MOV R0,A C:0x2A95 E4 CLR A C:0x2A96 93 MOVC A,@A+DPTR C:0x2A97 7012 JNZ C:2AAB C:0x2A99 7401 MOV A,#0x01 C:0x2A9B 93 MOVC A,@A+DPTR C:0x2A9C 700D JNZ C:2AAB C:0x2A9E A3 INC DPTR C:0x2A9F A3 INC DPTR C:0x2AA0 93 MOVC A,@A+DPTR C:0x2AA1 F8 MOV R0,A C:0x2AA2 7401 MOV A,#0x01 C:0x2AA4 93 MOVC A,@A+DPTR C:0x2AA5 F582 MOV DPL(0x82),A C:0x2AA7 8883 MOV DPH(0x83),R0 C:0x2AA9 E4 CLR A C:0x2AAA 73 JMP @A+DPTR That jump took us to this area: C:0xF658 FF MOV R7,A C:0xF659 FF MOV R7,A C:0xF65A FF MOV R7,A C:0xF65B FF MOV R7,A C:0xF65C FF MOV R7,A where those lines execute one after the other until PC rolls over to 0x0000. Every time we get the reset, R0=0xFF, and DPTR=0xFF??. Does this look familiar to anybody? sd
What device are you using?
The ?C?CASE is unchanged since 15+ years and there is no known bug with it. What you are showing is the code of ?C?CASE itself. However the code reads a table that starts after the call of ?C?CASE. So the issue might be that you run on a code banked system or that this table is not correctly stored on the system. Can you verify the table before the call. This may sound a bit odd to you, but you say "This is on years-old stable code that recently outgrew its 32K boundary". My son grows, but software does not change size when it is unchanged. So the question is, what changes did you made and may these changes cause some side effects.
We had a bug that was there all along but was masked by other factors. See my post on "using 0."