Hi Paul,
I found it finally. I'll try to describe, it will be little longer...
The methods in IntFlash class (internal flash erase/write) reside in RAM and I
disable interrupts before I call them. I have to control the LCD backlight
manually, so there is IntFlash::setCallback(const Delegate& callback) method,
and the IntFlash's methods call that callback, if one is registered. The
Delegate class essentially has 2 members, pointer to object and pointer to
method. There is a method fire() and isEmpty():
inline bool isEmpty() const
{
return _object == 0;
}
inline void fire()
{
(_object->*_method)();
}
The IntFlash class has private method callback():
static void callback() ATTR_RUN_FROM_RAM
{
if (!_self._callback.isEmpty())
_self._callback.fire();
}
This method is called by other IntFlash methods. In one of my project this works
fine, in the other one the methods fire() and isEmpty() were not inlined, and
thus in flash, which then didn't work. So I created rather ugly methods
fire_InRAM() and isEmpty_InRAM() both marked with ATTR_RUN_FROM_RAM, with the
same code. If I call those methods from IntFlash::callback(), the project builds
with no warning, but some of the IntFlash methods are not placed into RAM (.fast
section), which I can verify in the .map file. In fact, the methods init() and
protectSector() are not visible in .map file at all. But they are somehow
linked, when I call them, it jumps to 0. When I make the private members of the
Delegate class public, and I access them in the IntFlash::callback() instead of
calling Delegate::isEmpty_InRAM() and Delegate::fire_InRAM(), it works again,
all the methods are in the .fast section.
Maybe this will be reproducible, using the "_object->*_method" code. Anyway it
seems to be GCC bug rather than Crossworks bug.
With regards,
Jan
----- Original Message -----
From: Jan Vanek
To: l...
Sent: Thursday, November 13, 2008 11:36 AM
Subject: Re: [lpc2000] method in .fast section
Hi Paul,
unfortunately with Build 14 it is still the same, even the "workarounds" seem
to work the same way.
Is there any other way how to place couple of methods into .fast section?
With regards,
Jan
----- Original Message -----
From: Jan Vanek
To: l...
Sent: Thursday, November 13, 2008 10:35 AM
Subject: Re: [lpc2000] method in .fast section
Hallo Rowley team,
I found a "workaround" how to get the init() method into .fast section. In the
following, the code between //BEG and //END was added. If any line there is
commented out, the init() method is no more in .fast section. Unfortunatelly
in release build now the protectSector() method is "evicted" from the .fast
section, regardless whether I call the code commented with // DOESN'T
HELP or not. In debug build it's OK. In both there is Enable Unused Symbol
Removal: No. There is no warning during compile/link. I also tried to define
the protectSector() in a ..CPP file, but here I get a "section type conflict"
error.
class IntFlash
{
public:
// BEG
static void initF1(void* p)
{
volatile void* pp = p;
}
IntFlash()
{
initF1((void*)&IntFlash::init);
// initF1((void*)&IntFlash::protectSector); // DOESN'T HELP
initF1((void*)&IntFlash::initF1);
}
// END
static void init() ATTR_RUN_FROM_RAM
{
...
}
static void protectSector(void* address) ATTR_RUN_FROM_RAM
{
....
}
};
I'll try to download the latest Crossworks, thanks.
With regards,
Jan
----- Original Message -----
From: Jan Vanek
To: l...
Sent: Thursday, November 13, 2008 1:15 AM
Subject: [lpc2000] method in ..fast section
Hi Rowley team,
I have couple of methods marked with
#define ATTR_RUN_FROM_RAM __attribute__((noinline, section (".fast")))
Everything worked fine, and suddenly one of those methods is not placed into
the .fast section anymore, instead it is placed at address 0. This is fatal.
Is this a known bug (I have 1.7 Build 8), and is there a workaround? Can I
upgrade to 1.7 Build ?
With regards,
Jan
[Non-text portions of this message have been removed]
#ygrp-mkp { BORDER-RIGHT: #d8d8d8 1px solid; PADDING-RIGHT: 14px; BORDER-TOP:
#d8d8d8 1px solid; PADDING-LEFT: 14px; PADDING-BOTTOM: 0px; MARGIN: 14px 0px;
BORDER-LEFT: #d8d8d8 1px solid; PADDING-TOP: 0px; BORDER-BOTTOM: #d8d8d8 1px
solid; FONT-FAMILY: Arial}#ygrp-mkp HR { BORDER-RIGHT: #d8d8d8 1px solid;
BORDER-TOP: #d8d8d8 1px solid; BORDER-LEFT: #d8d8d8 1px solid; BORDER-BOTTOM:
#d8d8d8 1px solid}#ygrp-mkp #hd { FONT-WEIGHT: bold; FONT-SIZE: 85%; MARGIN:
10px 0px; COLOR: #628c2a; LINE-HEIGHT: 122%}#ygrp-mkp #ads { MARGIN-BOTTOM:
10px}#ygrp-mkp .ad { PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM:
0px; PADDING-TOP: 0px}#ygrp-mkp .ad A { COLOR: #0000ff; TEXT-DECORATION: none}
[Non-text portions of this message have been removed]
#ygrp-mkp { BORDER-RIGHT: #d8d8d8 1px solid; PADDING-RIGHT: 14px; BORDER-TOP:
#d8d8d8 1px solid; PADDING-LEFT: 14px; PADDING-BOTTOM: 0px; MARGIN: 14px 0px;
BORDER-LEFT: #d8d8d8 1px solid; PADDING-TOP: 0px; BORDER-BOTTOM: #d8d8d8 1px
solid; FONT-FAMILY: Arial}#ygrp-mkp HR { BORDER-RIGHT: #d8d8d8 1px solid;
BORDER-TOP: #d8d8d8 1px solid; BORDER-LEFT: #d8d8d8 1px solid; BORDER-BOTTOM:
#d8d8d8 1px solid}#ygrp-mkp #hd { FONT-WEIGHT: bold; FONT-SIZE: 85%; MARGIN:
10px 0px; COLOR: #628c2a; LINE-HEIGHT: 122%}#ygrp-mkp #ads { MARGIN-BOTTOM:
10px}#ygrp-mkp .ad { PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM:
0px; PADDING-TOP: 0px}#ygrp-mkp .ad A { COLOR: #0000ff; TEXT-DECORATION: none}
[Non-text portions of this message have been removed]
#ygrp-mkp { BORDER-RIGHT: #d8d8d8 1px solid; PADDING-RIGHT: 14px; BORDER-TOP:
#d8d8d8 1px solid; PADDING-LEFT: 14px; PADDING-BOTTOM: 0px; MARGIN: 14px 0px;
BORDER-LEFT: #d8d8d8 1px solid; PADDING-TOP: 0px; BORDER-BOTTOM: #d8d8d8 1px
solid; FONT-FAMILY: Arial}#ygrp-mkp HR { BORDER-RIGHT: #d8d8d8 1px solid;
BORDER-TOP: #d8d8d8 1px solid; BORDER-LEFT: #d8d8d8 1px solid; BORDER-BOTTOM:
#d8d8d8 1px solid}#ygrp-mkp #hd { FONT-WEIGHT: bold; FONT-SIZE: 85%; MARGIN:
10px 0px; COLOR: #628c2a; LINE-HEIGHT: 122%}#ygrp-mkp #ads { MARGIN-BOTTOM:
10px}#ygrp-mkp .ad { PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px;
PADDING-TOP: 0px}#ygrp-mkp .ad A { COLOR: #0000ff; TEXT-DECORATION: none}