TUSB3410

Hi all, We have a licensed IAR Product Version: 7.20A.

We have application sources which are already built on IAR -EW8051 versio

2.20C/WIN.

we tried to build the above application sources with the latest version :7.20A of IAR. But it resulting many errors and warnings such as reserved/keyword errors have been displayed. We tried it in many ways(by applying migration tips available in you online documentation), but still, we couldn't succeeded in building th application.

Specifications says ?In a TIUSB3410 chip, under normal operation mode the 10K ROM is mappe to (0x8000?0xA7FF) in code space. The internal 16K RAM is mapped t address range (0x0000?0x3FFF) in code space. Buffers, MMR, and I/O ar mapped to address range (0xF800?0xFFFF) in data space.?

I am getting the following error while building the TIUSB3410 sourc code. Error[e16]: Segment IDATA_Z (size: 0x1d9 align: 0) is too long for segmen definition. At least 0x154 more bytes needed. The problem occurred while processing the segment placemen command "-Z(IDATA)IDATA_I,IDATA_Z,IDATA_N=08-_IDATA_END", where at the moment o placement the available memory ranges were "IDATA:7b-ff" Reserved ranges relevant to this placement: IDATA:8-f VREG IDATA:10-19 DATA_Z IDATA:1a-1f IDATA_I IDATA:21-ff IDATA_I BIT:0-7 BREG BIT:90-97 SFR_AN BIT:b0-b7 SFR_AN

After reading through the TIUSB3410 specifications, I modified the Linke script as follows.

I define the Code, XData, IXData 'START' and 'END' as follow?

CODE -- 0x0000 - 0x3FFF XDATA -- 0xF800 - 0xFFFF IXDATA -- 0xF800 - 0xFFFF

I define the PDATA with ??? not sure about this

-D_PDATA_START=0x0000 // First address for PDATA memory

-D_PDATA_END=0x00FF // Last address for PDATA memory

Rest of the file is as follows

// Special SFRs // ------------ // CODE bank setup

-D_FIRST_BANK_ADDR=0x10000

-D_NR_OF_BANKS=0x10 // // Register bank setup //

-D?REGISTER_BANK=0 // Default register bank (0,1,2,3).

-D_REGISTER_BANK_START=0 // Start address for default register ban (00,08,10,18). // // PDATA page setup //

-D?PBANK_NUMBER=0F // high byte of 16-bit address to the PDAT area

-D?PBANK=A0 // Most significant byte in MOVX A,@R0 (0xA0 is sfr P2)

-D?PBANK_EXT=0xEA // Most significant byte in MOVX A,@R0 (0xEA is for Dallas DS80C390) // // Virtuel register setup // ///-D_NR_OF_VIRTUAL_REGISTERS=0x20

-D?VB=20 // Used to refer to BREG as byte. // // ////////////////////////////////////////////////////////////////////////////////

// Include the lnk_base command file // =================================

-f lnk_base.xcl

I am new to 8051 and IAR linked scripts. I read though the 8051 compile and linker manuals provided by IAR and could correct some part linke parameters as mentioned above. Please let me know if I am doing it right. If required any changes let me know Regards, Mahesh

Reply to
maheshpeddi
Loading thread data ...

On Wed, 26 Dec 2007 08:54:02 -0600, "maheshpeddi" wrote in comp.arch.embedded:

Have you tried talking to IAR technical support? They are usually very responsive and quite helpful.

I've never used IAR on the 8051, but IDATA is a pretty universal term for any and all 8051 derivatives.

The maximum amount of IDATA on 8051 derivative is 256 bytes. And you can't actually use all of that, because you need at least one register bank.

The fact that the linker is telling you that it has at least one segment of 0x1d9 (473) bytes that wants to go into IDATA means that something is very, very wrong, because there is not, and cannot ever be, that much IDATA memory.

This sounds like it could come from a problem in compiler settings. Perhaps you telling the compiler to put all data defined in C source into IDATA when it should be going into external data space.

////////////////////////////////////////////////////////////////////////////////

I would still suggest that you contact IAR support.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Reply to
Jack Klein

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.