Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-3399946 ] Corruption of variables
|
From: SourceForge.net <no...@so...> - 2011-09-07 22:32:08
|
Bugs item #3399946, was opened at 2011-08-28 23:27 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3399946&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mcs51(8051) target >Group: non bugs >Status: Deleted Resolution: None Priority: 5 Private: No Submitted By: Aero72 () Assigned to: Nobody/Anonymous (nobody) Summary: Corruption of variables Initial Comment: Runtime errors caused when values pushed to stack are either overwritten or erroneously used. (target is a Silabs C8051F564). Same code compiled with Keil/Raisonance works exactly as intended. Routine showing the problem is a u16 div u8 library function (which I'm sure is 100% correct from looking at the code in the _divuint.c library function and comparing it to the disassembled contents of memory at the LCALL) - so strongly suspect issue must be something to do with the preamble to the routine and/or restoration of previous state; from looking at the assembler, it appears addresses in the stack are being used as temporary storage of operands - the bytes being loaded with these variables are about 10 bytes into the stack, and I know the overall stack usage of my program far exceeds 10 bytes (its more like 40). I suspect the amount of worst-case stack in use is being miscalculated, and when the routine is called it over-writes other variables which have been pushed by other functions. This problem causes erroneous behaviour in about 5% of calls to the routine which contains the divide. Sample code containing the problem can be found in the Silabs brushless 3-phase motor control software (AN208) - this contains a suitable balance of ISR code and regularly scheduled software (similar u16/u8 calcs are in both). I have converted and enhanced this software for use on the F564 and added an interface to CAN to allow debugging of the code. Compile instruction is -c --debug --model-small --use-stdout -V -D=_C8051F56x_ The SDCC versions tested are both the official release of version 3.00, and also one of the latest patched versions - the following string is in the stdout... -DSDCC=304 -DSDCC_REVISION=6752. CAN data shows just one frame of erroneous data in the 1ms when the problem occured, the frames preceeding and following the time of interference to the variables show exactly correct data. If you should need to contact me (and please do if you want specific tests etc..), you can get me at and...@vo... ---------------------------------------------------------------------- >Comment By: Aero72 () Date: 2011-09-07 22:32 Message: Reckon this was my error - Have recompiled all the maths functions used by the whole software using --stack-auto, made adjustments to use semaphoring (where sensibly possible) to reduce mathematics in the ISRs and the problem has now gone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3399946&group_id=599 |