NE64-FLASH Filesystem Problems/Serial Interface Configure

[BchBum11511]

I am new to using uTasker on my DEMONE64.  I finally got everything built to work on my network.  I am able to FTP to the board, but when I try and drop files to it, I end up with problems.  The simulation worked perfectly, but using the board I get a file that looks like "A./???" (without the /) and can't do anything with it.  If I add another file, I get the Empty file.  I turned off the MIME filenaming and then I get a file that gives me "F.HTM."  The first letter depends on the file I add, but when I go to open it with Firefox, I get some source code printed along with most of the correct looking webpage.  If I add another file, it just refreshes the list with the same filename, and when I refresh Firefox with the same filename, I get a concatenation of the two files I added to the system.
  I was wondering if anyone else is having this problem, and if they have what they did to fix it.  If I need to provide anymore information, please let me know what I should include.

Also, I would like to get the Serial Port working, but when I start to build the .elf and .s19 files, I get errors saying I am running out of memory, I think.  The section text has overrun its limit and causes the data, vectors and value to have problems.  I have tried turning off most of the features I don't need like smtp, udp, DHCP, etc to make room, but I can't seem to get it small enough.  Is there something else I need to do to make the Serial Port usable with an option to send the data received to the Ethernet Port?

Thanks,
Keith

[mark]

Hi Keith

This is strange because the simulator is generally very exact and so different behaviour on the target is very rare.
Check out the following thread to be sure that you don't see a error in use: http://www.utasker.com/forum/index.php?topic=65.0

Could you send me the file(s) which you have been using for your tests (if not the original ones from the demo project)?
A file displayed with 3x? means that the MIME type is not understood (it is not in the list defined in config.h - search for cMimeTable[]). Without SUPPORT_MIME_IDENTIFIER defined it is normal that all files are displayed with the extension .HTM since they are assumed to be of this type. This however restricts images being used when content is being generated since the parser will also try to interpret image content - resulting sometimes in strange effects.

At the moment I can't explain your other observations - it may be useful also to receive an Ethereal recording of the file being loaded to the board and the subsequent FTP dir refresh or a web server transfer.




If you are using the GCC compiler and start seeing things like the following it does mean that the memory is overflowing:

Code: [Select]

C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\..\..\..\..\m6811-elf\bin\ld.exe: region text is full (uTaskerV1.3.elf section .text)
C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\..\..\..\..\m6811-elf\bin\ld.exe: section .rodata [00004000 -> 00005851] overlaps section .text [00004000 -> 00011e45]
C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\..\..\..\..\m6811-elf\bin\ld.exe: section .data [00005852 -> 00005881] overlaps section .text [00004000 -> 00011e45]
C:\Programme\usr\bin\..\lib\gcc-lib\m6811-elf\3.3.4-m68hc1x-20040829\..\..\..\..\m6811-elf\bin\ld.exe: section .vectors [0000ff80 -> 0000ffff] overlaps section .text [00004000 -> 00011e45]
make: *** [uTaskerV1.3.elf] Error 1
It is an unfortunatle fact of life that the GNU compiler for the HCS12 is not very efficient. Using a good commercial compiler you can activate everything in the uTasker project (if I remember correctly) and it fits with some space to spare, but the GNU compiler requires around 80% more code space. [A side note is that the GNU compiler for ARM and Coldfire is very highly developed and has no disadvantages against the best commercial compilers in regard to code efficiency. The GNU compiler for the HCS12 couldn't take advantage of the ground work in the base project due to architectural differences so would require a large amount of additional work before it can compete. It does however produce perfectly working code and, if there is enough memory available, can be used very successfully.]

The serial interface demo in the uTasker project switches in quite a large amount of code so typically has this problem with GNU. It switches in the TTY module (with various options which can be reduced slighty by removing serial interface options - about 2k saving), the serial driver and also a menu driven demo interface - it is mainly the strings here which cause the project size to explode. With the define SERIAL_INTERFACE the GNU code increases by about 14k - which will take the project with HTTP (even without FTP) over the 46k limit.

To test the serial interface in the demo project you unfortunately need to remove FTP, HTTP and TELNET. Then it should fit quite easily (around 40k). Depending on what you want to do with the serial interface, you can then make your own application (simply copy the directory applications\uTaskerV1.3 and rename it to your own project name) and then remove large amounts of the file debug.c, which contains the demo menus.

You will find that the demo project doesn't include code to transfer between UART and Ethernet but this can be added for first experiments by following some of the guides:
- http://www.utasker.com/forum/index.php?topic=25.0
- http://www.utasker.com/forum/index.php?topic=31.0

Note however that high speed UART <-> TCP is best achieved using a Telnet-like socket. It is however not as easy as it first sounds due to the need to buffer data and perform flow control (serial and TCP).

Good luck

Regards

Mark

P.S. Look also at the M52233DEMO board from Freescale. It is low cost and includes a 128k limited version of CodeWarrior and a BDM. The chip is much more powerful than the NE64 and has rather more RAM - important for UART<->ETHERNET applications. The kit ($99) is hardly more expensive that the NE64 kit and I would advise anyone new to these types of chips (including educational establishments looking for a board for student work) to go for the Coldfire solution...the GNU compiler is also excellent for these devices!
I have also just learned that the DEMO9S12NE64 is no longer manufactured...

[thamanjd]

I use the NE64
It sounds similar to when i had accidentally set page 0x3C aside for flash and 0x3D for code in the memory setup in codewarrior compiler.
Whereas 0x3D should be set aside for flash file and 0x3C should be used for code.

FTP and the file system was getting completely stuffed up. FTP thought it was writing files but reading them back showed them to be gibberish.
I've never used GCC for this project. Make sure you disallow the compiler from trying to write code to page 0x3D?
Make sure the file system section gets put in the start of 0x4000?.

Ive never compiled with the serial interface option turned on so i cant compare compile sizes in CW atm.
I'll do this some time and post back here

I was going to write some sort of small serial<->ethernet app at some point. when i do i'll post snippets here.
Like Mark said you could disable the serial interface altogether if you wanted to, redirect the serial vectors to your own code and set up the serial port in your own code.

There are definately advantages with the other processors.
NE64 as part of the s12 family is attractive for some when spending a few grand on a commercial compiler because the compiler supports the rest of the diverse s12 family micros as well.
I found the little ne64 modules from technological arts in Canada very useful during experimenting with the hardware.



JD