Thanks for all your comments. I agree that finding another consultant or even buying Keil might well have been cheaper and quicker overall, but I just had to find out what was wrong. I expect everyone here knows that feeling! In terms of validation, of course we have a test protocol that we wrote when the original software was commissioned, and we'd follow that any time there was a change, however trivial.

On to more technical matters, I think I have found the problem. Does the following look odd to you?

Here's the source; it's setting a register in extended memory. At MCU reset, the register is zero so it should end up with 0x0c in that register.

#define bMODECNFG   (* (unsigned char xdata *)0xFFFB)        
#define MODECNFG_CLKOUTEN 0x04  
#define MODECNFG_CLKSLCT 0x08   
...                                
bMODECNFG |= MODECNFG_CLKOUTEN;
bMODECNFG |= MODECNFG_CLKSLCT;
...

 

(ignore the fact it's not the most concise way to do this!)

Code generated by SDCC:

                            444 ;	bMODECNFG |= MODECNFG_CLKOUTEN;
   004B 7A FB               445 	mov	r2,#0xFB
   004D 7B FF               446 	mov	r3,#0xFF
   004F 90 FF FB            447 	mov	dptr,#0xFFFB
   0052 E0                  448 	movx	a,@dptr
   0053 FC                  449 	mov	r4,a
   0054 74 04               450 	mov	a,#0x04
   0056 4C                  451 	orl	a,r4
   0057 8A 82               452 	mov	dpl,r2
   0059 8B 83               453 	mov	dph,r3
   005B F0                  454 	movx	@dptr,a
                            455 ;	bMODECNFG |= MODECNFG_CLKSLCT;
   005C 90 FF FB            456 	mov	dptr,#0xFFFB
   005F 43 04 08            457 	orl	ar4,#0x08
   0062 EC                  458 	mov	a,r4
   0063 F0                  459 	movx	@dptr,a

 

This (as far as I can see) results in 0x04 in the register.

Equivalent dissassembled from the Keil version:

X10be:	mov	dptr,#Xfffb
	movx	a,@dptr
	orl	a,#4
	movx	@dptr,a
	movx	a,@dptr
	orl	a,#8
	movx	@dptr,a

 

This looks a lot more sensible (and shorter!)

I changed the source to

bMODECNFG |= (MODECNFG_CLKOUTEN|MODECNFG_CLKSLCT);
 

and it now works perfectly on SDCC.

Do you agree this is a bug in SDCC's code generation?