We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi there All, I have a problem which seemed to be defying explanation, but I have come up with a theory. Could I possibly have some feedback on whether the following is likely, plausible, possible, untrue or downright rubbish? If one reads the contents of a CAN or ADC chip register at a particular address, then the label volatile is placed upon that address to prevent the compiler optimising out repeat readings of the address. If one reads the contents of the address into a variable, then the compiler would automatically treat the contents of this variable with similar care. Is it possible that there has been an oversight with statements where the contents of a variable depend on the contents of a volatile by way of an if statement, ie...
normal_var=volatile_var;
normal_var=voltile_var; if (normal_var=0x00) { another_normal_var+=1; }
Hi Richard, That's more like it. When discussing anything to do with C, I much prefer C code to abstract words :-) It sounds like you don't have an in-circuit debugger set up... Anyway, there is no need to try and guess how the compiler optimized your code when you can actually see the generated code. Print out the disassembly of your code and the questions will go away. If you are not familiar with the C166 instruction set, it wouldn't be too dificult to learn. After all, C166 is a RISC-like architecture, there are not that many instructions. I would suggest posting compiler listing here if there wasn't that much code. Regards, - mike
Hi Mike, Cheers for this suggestion, it looks like it is bearing fruit. Looking at the Main.LST file, the differences seem to be in the interpretation of the lines...
CAN_LED_status=RESET; if ((temp_a==0x00)&&(temp_b==0x00)) CAN_LED_status+=Transmit_OK; temp_b=ReceiveB; temp_a=ReceiveA; ReceiveB=0; ReceiveA=0; if ((temp_a==0x00)&&(temp_b==0xb8)) CAN_LED_status+=Receive_OK; CAN_board_LEDs=CAN_LED_status;
2A6C E00E MOV R14,#00H 2A6E F480DC00 MOVB RL4,[R0+#0DCH]; temp_a 2A72 3D04 JMPR cc_NZ,?C0236 2A74 F480DE00 MOVB RL4,[R0+#0DEH]; temp_b 2A78 3D01 JMPR cc_NZ,?C0236 2A7A 08E5 ADD R14,#05H 2A7C ?C0236: 2A7C D7408000 EXTP #080H,#01H 2A80 F3F80500 MOVB RL4,05H 2A84 E480DE00 MOVB [R0+#0DEH],RL4; temp_b 2A88 D7408000 EXTP #080H,#01H 2A8C F3F80400 MOVB RL4,04H 2A90 E480DC00 MOVB [R0+#0DCH],RL4; temp_a 2A94 E108 MOVB RL4,#00H 2A96 D7408000 EXTP #080H,#01H 2A9A F7F80500 MOVB 05H,RL4 2A9E E108 MOVB RL4,#00H 2AA0 D7408000 EXTP #080H,#01H 2AA4 F7F80400 MOVB 04H,RL4 2AA8 F480DC00 MOVB RL4,[R0+#0DCH]; temp_a 2AAC 3D07 JMPR cc_NZ,?C0237 2AAE F480DE00 MOVB RL4,[R0+#0DEH]; temp_b 2AB2 47F8B800 CMPB RL4,#0B8H 2AB6 3D02 JMPR cc_NZ,?C0237 2AB8 06FE0A00 ADD R14,#0AH 2ABC ?C0237: 2ABC F04E MOV R4,R14 2ABE D7408000 EXTP #080H,#01H 2AC2 F7F82E00 MOVB 02EH,RL4
2A82 E108 MOVB RL4,#00H 2A84 E480DA00 MOVB [R0+#0DAH],RL4; CAN_LED_status 2A88 F480DC00 MOVB RL4,[R0+#0DCH]; temp_a 2A8C 3D08 JMPR cc_NZ,?C0236 2A8E F480DE00 MOVB RL4,[R0+#0DEH]; temp_b 2A92 3D05 JMPR cc_NZ,?C0236 2A94 F480DA00 MOVB RL4,[R0+#0DAH]; CAN_LED_status 2A98 0985 ADDB RL4,#05H 2A9A E480DA00 MOVB [R0+#0DAH],RL4; CAN_LED_status 2A9E ?C0236: 2A9E D7408000 EXTP #080H,#01H 2AA2 F3F80500 MOVB RL4,05H 2AA6 E480DE00 MOVB [R0+#0DEH],RL4; temp_b 2AAA D7408000 EXTP #080H,#01H 2AAE F3F80400 MOVB RL4,04H 2AB2 E480DC00 MOVB [R0+#0DCH],RL4; temp_a 2AB6 E108 MOVB RL4,#00H 2AB8 D7408000 EXTP #080H,#01H 2ABC F7F80500 MOVB 05H,RL4 2AC0 E108 MOVB RL4,#00H 2AC2 D7408000 EXTP #080H,#01H 2AC6 F7F80400 MOVB 04H,RL4 2ACA F480DC00 MOVB RL4,[R0+#0DCH]; temp_a 2ACE 3D0B JMPR cc_NZ,?C0237 2AD0 F480DE00 MOVB RL4,[R0+#0DEH]; temp_b 2AD4 47F8B800 CMPB RL4,#0B8H 2AD8 3D06 JMPR cc_NZ,?C0237 2ADA F480DA00 MOVB RL4,[R0+#0DAH]; CAN_LED_status 2ADE 07F80A00 ADDB RL4,#0AH 2AE2 E480DA00 MOVB [R0+#0DAH],RL4; CAN_LED_status 2AE6 ?C0237: 2AE6 F480DA00 MOVB RL4,[R0+#0DAH]; CAN_LED_status 2AEA D7408000 EXTP #080H,#01H 2AEE F7F82E00 MOVB 02EH,RL4
2A22 E108 MOVB RL4,#00H 2A24 E480D600 MOVB [R0+#0D6H],RL4; CAN_LED_status 2A28 F480D800 MOVB RL4,[R0+#0D8H]; temp_a 2A2C 3D08 JMPR cc_NZ,?C0236 2A2E F480DA00 MOVB RL4,[R0+#0DAH]; temp_b 2A32 3D05 JMPR cc_NZ,?C0236 2A34 F480D600 MOVB RL4,[R0+#0D6H]; CAN_LED_status 2A38 0985 ADDB RL4,#05H 2A3A E480D600 MOVB [R0+#0D6H],RL4; CAN_LED_status 2A3E ?C0236: 2A3E D7408000 EXTP #080H,#01H 2A42 F3F80500 MOVB RL4,05H 2A46 E480DA00 MOVB [R0+#0DAH],RL4; temp_b 2A4A D7408000 EXTP #080H,#01H 2A4E F3F80400 MOVB RL4,04H 2A52 E480D800 MOVB [R0+#0D8H],RL4; temp_a 2A56 E108 MOVB RL4,#00H 2A58 D7408000 EXTP #080H,#01H 2A5C F7F80500 MOVB 05H,RL4 2A60 E108 MOVB RL4,#00H 2A62 D7408000 EXTP #080H,#01H 2A66 F7F80400 MOVB 04H,RL4 2A6A F480D800 MOVB RL4,[R0+#0D8H]; temp_a 2A6E 3D0B JMPR cc_NZ,?C0237 2A70 F480DA00 MOVB RL4,[R0+#0DAH]; temp_b 2A74 47F8B800 CMPB RL4,#0B8H 2A78 3D06 JMPR cc_NZ,?C0237 2A7A F480D600 MOVB RL4,[R0+#0D6H]; CAN_LED_status 2A7E 07F80A00 ADDB RL4,#0AH 2A82 E480D600 MOVB [R0+#0D6H],RL4; CAN_LED_status 2A86 ?C0237: 2A86 F480D600 MOVB RL4,[R0+#0D6H]; CAN_LED_status 2A8A D7408000 EXTP #080H,#01H 2A8E F7F82E00 MOVB 02EH,RL4
The only difference I see is that in the 'broken' code one of the variables (CAN_LED_status) is placed in the register R14. All the other veriables are placed on the user stack. Of course, this is perfectly legal and the compiler generated correct code. There can be all sorts of reasons why the code fails: changed execution speed, corruption of registers by interrupt service routines we don't know of, plain bug in the code (so it works accidentally sometimes) and so on. Best of luck! - mike
I'll second Mike's observation. There's absolutely no change at all between the three assembly outputs you show, as far as accesses to your CAN registers are concerned. They're those EXTB+MOVB pairs. Which means that whatever the real bug is, it's not in the piece of assembly code you did show. It's elsewhere. One thing I'm worried about is that I don't see any remains of the most significan byte actual addresses of your CAN registers (0x20) in any of the quoted code. Now, I don't do 166's at all, but this does feel fishy. Are you sure this code succeeds in accessing your CAN hardware registers at all, in the first place? You really should trace through this in some simulator or emulator to see what actually happens.
One thing I'm worried about is that I don't see any remains of the most significan byte actual addresses of your CAN registers (0x20) in any of the quoted code. It's those EXTP instructions. EXTP #080H,#01H is pretty much the same as EXTS #020H,#01H, which wouldn't alarm you. For some reason the C166 compiler prefers EXTP to EXTS, but that doesn't do any harm. - mike