Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-1626326 ] _XPAGE Initialization in startup.
|
From: SourceForge.net <no...@so...> - 2007-01-03 09:43:26
|
Bugs item #1626326, was opened at 2007-01-02 09:08 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1626326&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: msc51(8051) target Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ralf Guetlein (rguetlein) Assigned to: Nobody/Anonymous (nobody) Summary: _XPAGE Initialization in startup. Initial Comment: No matter what options I choose, the _XPAGE register ends up to be wrongly initialized. I looked deeper into the startup code, and to my findings there are some weird relationships: 1) If --xstack option is used _XPAGE gets initialized to (__start__xstack >> 8), which is located after XISEG, and which is *not* the same as the pdata page (see crtxstack.asm) 2) If there are initialized xdata variables (and no xstack and no pdata) the _XPAGE ends up being set to 0xFF (literal constant!) (see crtxinit.asm). 3) If there is any pdata variable (initialized or not) _XPAGE is set to (s_PSEG >> 8) which, in any configuration I tested, is always 0. 4) With no initialized xdata, no pdata, no xstack, _XPAGE is not initialized at all. The only way I achieved a properly initialized _XPAGE register was to call the linker stage with -Wl "-b PSEG = 0xF000", with at least one pdata variable defined. To enable you to follow my findings I attached the file "startup.doc" which summarizes the startup sequence, normally spread over many modules (a valuable addition to the documentation, anyway). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-03 01:43 Message: Logged In: NO As I promised I created a small testcase. In contrast to my first assumption I do not suspect the startup code anymore. The bug (and I am still considering it a bug) is in the linker. I will submit a separate bug report. Ralf ---------------------------------------------------------------------- Comment By: Ralf Guetlein (rguetlein) Date: 2007-01-02 12:54 Message: Logged In: YES user_id=145736 Originator: YES Maarten, thank you for your reply. Yes, both pdata and xstack should be on the same page, but they are not. No matter what I do, s_PSEG (in the map file) is always "0". xstack comes *after* XSEG/XISEG which is contrary to the manual (stating that pdata/xdata is on the same page on the *beginning* of xram area. I'll create a small sample application that explains my complaint. Accepted, if no pdata is used, P2 should be left alone or be reinitialized to 0xFF Ralf ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2007-01-02 12:06 Message: Logged In: YES user_id=888171 Originator: NO Hi Ralf, You state _XPAGE is wrongly initialized, but what is wrong about the initialization? In your opinion what should it be? 1) Both the XSTK and PSEG should be in the same page. The linker takes care of that. 2) On a genuine 8051 _XPAGE is P2 which has a reset value of 0xFF. This sets it back. 3) There is no standard option to set the start of PSEG. The linker option -Wl-bPSEG=0xF000 is ok. See also 1. 4) Why should it? You're right about the documentation, this sequence gives much insight. Maarten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1626326&group_id=599 |