On Sun, 25 Jan 2015 11:11:57 +0200 Kustaa Nyholm <kustaa.nyh...@planmeca.com> wrote:
> > 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 > > I found something here: http://dangerousprototypes.com/forum/viewtopic.php?t=3269&p=40918 (On the following link: http://dangerousprototypes.com/forum/download/file.php?id=7722&sid=f549638b834112dfa1c4ef976c40ec92) Perhaps might work. Károly ------------------------------------------------------------------------------ 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
