OK, with a little further investigation I noticed the following:
My firmware can grow up to 19844 bytes. If I add a simple instruction,
e.g LED1=3DON, the Cypress EZ-USB FX fails to enumerate, although it =
that the main() firmware loop is functioning.=20
I checked the .map and .mem files. I am not linking to any of the
reserved memory spaces. The only difference between the two cases is
that the code segment grew by 2 bytes, as expected.
The enumeration error is probably caused by the USB interrupts not
occuring. I noticed that during the firmware download process, another
two bytes (of value 0x22) is written to internal RAM at address 0x0.
This overwrites my assembly interrupt vector table that I link to
address 0x0. I placed this interrupt table here, because SDCC relocates
its own generated vector table to the start of the code segment (my code
segment starts at 0x2000). If I manually edit the hex record file to
remove this last record, everything works fine again. Now the big
question is why SDCC does this? A bug? Any ideas?=20
Last record in the c code of the hex file:
[mailto:sdcc-user-admin@...] On Behalf Of Ernst
Sent: 01 July 2005 03:49 PM
Subject: Re: [Sdcc-user] code fails if it reaches certain size?
On Friday 01 July 2005 15:31, Muller Jaco <jjmuller@...> wrote:
> My firmware code is growing, and is working fine until its size=20
> reaches about 19000 bytes. The code is running on an EZ-USB FX
> As soon as the size reaches this limit, the device cannot be=20
> enumerated (firmware not working..) Below this limit, the firmware can
> be relocated anyware in external RAM without any problems. I am=20
> avoiding the memory areas of the EZ-USB used for buffer registers.
> The firmare size will grow beyond 19000 bytes, as I still need to=20
> implement more functions. I am completely baffled and don't even know=20
> where to start tracing the bug - does anyone have any idea where the=20
> problem could be? As far as I know, there is no code size limit in
My guess would be that your code somewhere overlaps with the endpoint
buffers, making renumeration fail cause the buffers are filled with your
But since those Buffers start at 0x7B40, there should be enough space
below for your code.
The EZUSB Chips also remap those buffers into a second memory area, but
IIRC those would be at arround 0x2... so I guess you deactivated that
Maybe check the memory map as generated by the linker for overlap with
some of the usb buffers?
Luckily my project's firmware still fits in an AN2131SC without
additional external ram, so I never looked closely at availabe memory
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. =
Sdcc-user mailing list