Thanks for the help Erik!
So if I understand correctly, the loader writes "code" in what is sees
as data memory, so one can only write code in external memory that the
8051 can access as both data (RD,WR) and code (PSEN) memory? How come
does the EZ-USB TRM (page 3-4) include location 0x1b40 and upwards as
external code memory when no loader can write code at 0x1b40-1f3f ? This
One more question: I would then start my code segment at 0x2000 to avoid
the 0x1b40-0x1f3f code gap, using --code-loc 0x2000. But this is in
external RAM, and I still need to place some data structures in the
internal RAM for the SUDPTR pointer to be able to fecth them. If I use
absolute addressing to locate an array at, say 0x0100:=20
static code at 0x0100 Byte device_descriptor 
where will this array be placed? The storage class 'code' places the
array in the code segment, thus at 0x2000 + 0x0100 ? The SUDPTR pointer
does not work if I place the data structure in xdata memory, starting at
0x0000. It needs to be in the code segment. How can I then utilize
internal and external memory as code memory, while avoiding the
0x1b40-0x1f3f gap? Any advice?
[mailto:sdcc-user-admin@...] On Behalf Of Erik Petrich
Sent: 24 September 2004 04:08 AM
Subject: Re: [Sdcc-user] 8051/EZ-USB FX code segment
On Thu, 23 Sep 2004, Muller Jaco <jjmuller@...> wrote:
> The "--code-loc" parameter relocates all the code to the given=20
> location, including the interrupt table. Why would the interrupt table
> be relocated as well? The first record in the hex record is a ljmp to=20
> the start of my actual code, and this instruction, together with the=20
> interrupt table, must always start at 0x0000 (where the processor will
> start execution). If I relocate code,say to external memory location=20
> 0x4000, I have to manually edit the hex record so that this ljmp=20
> instruction and interrupt table starts at 0x0000 before the program=20
> code will work. Is there any way in which I can tell SDCC not to=20
> relocate the first instruction and the interrupt table?
Rather than manually editing the hex records, you could link your
program with a custom interrupt vector table, written in assembly, and
use the --no-iv option to cause the compiler to omit its default
interrupt vector table.
> Also, the internal 8KB RAM of the EZ-USB FX is only usable up to=20
> 0x1B3F for code. I have external memory on the development board, and=20
> as I understand, the PSEN, RD and WR signals are only active for=20
> code/program fetches which doesn't exist in internal RAM. (EA pin tied
> low, code internal, data/code external). This means that I can=20
> continue with my code segment at 0x1B40 in external RAM, because the=20
> micro will generate a PSEN signal for locations above 0x1b3F, which is
> used to enable the external RAM on the development board. But this=20
> doesn't work - as soon as my program code overflows from internal RAM=20
> to external RAM, it stops working (it does work when I relocate the=20
> entire code segment to external RAM, or if it is kept small enough to=20
> fit into internal RAM) Any ideas what I could be doing wrong? As I=20
> understand, the code segment should be continuous between internal RAM
> and external RAM.
Yes, the code segment is continuous between the internal memory and
external memory. However, it is not possible to download code to
external memory between 0x1b40 and 0x1f3f or between 0x7800 and 0x7fff.
The built-in USB core only supports downloading to the on-chip memory,
so to handle downloading to off-chip memory, the Cypress utilities first
download a loader to the on-chip memory (see Cypress KB article 11785).
If the loader attempts to write to the above mentioned regions, no
external memory cycles are generated since these regions map to on-chip
resources when read or written as data (which is the only way the 8051
core can perform a write). Thus your downloaded program fails if it
fetches code from the external memory in these regions since the
download cannot initialize memory there.
> Last question: The device descriptors for the EZ-USB need to be in=20
> internal RAM for the setup data pointer (SUDPTR) to function. Using=20
> absolute addressing to locate a data structure in internal code RAM=20
> doesn't reserve that space for the variable. How can I keep a variable
> at a specific location in internal RAM, without letting the rest of my
> code overlap with it?
Use absolute address to locate the data structure at some location, then
use --code-loc and --xram-loc to specify locations that won't overlap
each other or the the data structure. You can use the --xram-size and
--code-size options to warn if these regions expand beyond your
specified allocations (and thus possibly into each other).
> I plan to use an external EEPROM when development is finished (to boot
> the device without first downloading firmware), but in the meanwhile I
> want to use RAM.
Keep in mind that the built-in EEPROM bootloader will only load the
on-chip memory. If you are planning on using off-chip RAM for code, you
will need to load your own bootloader into the on-chip RAM and transfer
data from the EEPROM to the off-chip RAM yourself.
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
Sdcc-user mailing list