Blast from the past! Debugging my 'memcpyram2ram problem' (going on for 20 hours now!) I may have found the problem, I've yet to verify this but it looks like my (Diolan's really) USB bootloader enables the extended instruction set and searching the web I came across this interesting exchange between Raphael and myself:
Raphael Neider <rneider@we...> - 2009-01-08 12:28:23 > Since SDCC r5276 (2008-11-25), the extended instruction set is > automatically disabled by SDCC by meddling with the user-provided > CONFIG4L byte (if no CONFIG4L byte is specified, Microchip states > that XINST defaults to being disabled, so we are lucky). > Prior to SDCC r5276, one had to explicitly state > static __code char __at(_CONFIG4L) _conf4l = something & _XINST_OFF; > and if you missed _XINST_OFF, your program was bound to fail in > various interesting ways, the cause of which was rather hard to find. How prophetical! I'm pretty sure that is the issue. Anyways, for posterity, this is how I found this (potential) bug. I run my code in 'gpsim' and it did not crash! So I next flashed my code with PICKit and that code worked! Right, so something wrong with the USB boot loading. I disabled code protection so I could read back the code, on comparing the pickit flashed and diolan bootloader loaded code the code looked identical, except for the unprogrammed areas (still need to investigate why and if that is a problem). So I read back the config bits from both the working code and non working code and went through them bit by bit and came across the XINST bit. To verify this I copied the config bits from the non-functional to the functional code (in source code) and flashed that with PICKit. Still the code worked!! Ok, so no problem with the config bits, just to make sure I read back the config bits. WHAT? The XINST bit was not set even though I set it in the source code! (That was when I found that blast from the past above.) Almost missed that one. I think it is a bit nasty that SDCC changes that bit silently, I could have easily missed this and be still searching. If the source code sets that bit then obviously something is wrong and the compiler should at least warn about it or better yet give an error. Anyways, the real problem lies not with SDCC but the fact that Dialan's bootloader turns on (and probably uses) the extended instruction set. Now back to verifying and rectifying the problem. I seem to remember that someone has already made a version that does not use the extended instruction set, yep, it is called diolan-plus ... now if I can just find the code. br Kusti This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general. ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
