Hi, Daniel wrote: > I think it probably "just works" in this case because the descriptor > table is defined in assembly and its address is forced in the linker. > > Hence the declaration only affects how the C code accesses it.
Ah yes, I forgot about this. Chris wrote; > You're the last person in the world I would want to argue with about > SDCC, but my observations *appear* to contradict you: It works because the descriptors are initialized in assembly. > * xdata is initialised with explicit values at 0x3f00 and 0xe000 by the > RAM load and 0xC2 EEPROM load before any SDCC-generated code executes > > > > FWIW, I just tried the code->xdata + DSCR_AREA=e000 change on the > > > firmware in FPGALink[2] and it works fine. > > > > Are you using C0 or C2 mode? C2 mode cannot load 0xe000 > > according to the datasheet. Can the driver download to > > 0xe000 directly? > > > A 0xC2 loader can definitely target 0xe000. There's a note in section > 3.4.3 of the TRM: > > Serial EEPROM data can be loaded only into these three on-chip RAM > spaces: > * Program / Data RAM at 0x0000-0x1FFF > * Data RAM at 0xE000-0xE1FF > * The CPUCS register at 0xE600 [bit 0] > > (Actually the TRM is a bit wrong here because it can actually load > program/data RAM at 0x0000-0x3fff, not 0x0000-0x1fff, but the point > about 0xe000-0xe1ff stands). I admit I did not read further than 3.2 EZ-USB Startup Modes which states: Note: Although the EZ-USB can perform C2 Loads from EEPROMs as large as 64 KB, code can only be downloaded to the 16K of on chip RAM. On second thought I think "code" here means code space since 0xe000 is xdata only. I had read it as 'binary data'. Sorry for the noise, Maarten ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 _______________________________________________ Fx2lib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
