utFat and simulator

[rad]

Hi Mark,

Now I try to use utFat according to Your document (uTasker-utFAT), but when I use simulator and connect with terminal, it seems to send just a few chars and then it stops. See following listing:

info

SD-card  (1967128576 bytes)
Bytes per sector: 512
Cluster size: 4096
Directory base: 0x00000002
FAT start: 0x0000005f
FAT size: 0x00000ea5
Number of FATs: 2
LBA: 0x00001da9
Total clusters: 0x0007504a
Info sect: 0x00000040
Free clusters: 0x00Connection timed out

Actually it stops at last line and if I left it for a while it add Connection timed out. The same if I type

sect 0

Reading sector 0x00000000
 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
 0x00000000 0x00000000 0x00000000 0x00000000 0x0Connection timed out

I use Xon/Xoff at the terminal (but the same is If I disable it) and the same result if I comment out #define SERIAL_SUPPORT_DMA. I didnt make any changes in project v.1.4, I expect its set up to work properly with utFat without any settings, at least for use with terminal..

Rad

[mark]

Hi Rad

It looks as though the UART output buffer (queue) is set a bit too small for these outputs.

Increase TX_BUFFER_SIZE so that a complete output block can fit into it and that should solve the issue.

Note that the debug output will simply discard output data when there is no more space to put them into the buffer. The command line menu uses a special technique where the debug task is suspended when the output queue doesn't have enough space. This means that it can display large menus even with a small output buffer size since the task will write just a part of the menu, stall and wait until the buffer becomes free (as the UART driver sends the content out) and then sends the next part.

Regards

Mark

P.S. The message "Connection timed out" is normal when there is no input for a certain time. This will disconnect the UART from the command line interface and allow a user to establish a new debug connection on a different port (eg. TELNET or USB). Without the timeout the UART connection would clock the other ports for ever. Once timed out simply entering new commands re-establishes another session.

[rad]

Hi Mark

I changed TXbuffer to 2048 and now it works, but You used 256 bytes long Txbuffer originally, so It seems to be quite big change (1024 bytes buffer didnt work). Now I cannot connect to ftp (terminal says connection was closed by remote host). I use M52233DEMO so I undefined _M5225X in config.h. Did I something wrong? (because ftp works before). It seems to start my problems use kirin2 instead of kirin3..

Rad

[mark]

Hi Rad

The use of RAM buffer space is always a bit of a "balancing act" on smaller single-chip processors. The M5223X have 32k which needs to be shared by application, driver buffers, Ethernet etc.

I expect that the larger UART buffer means that there is not enough space for FTP (or TELNET) to allocate their working buffers so you will probably also have to increase the HEAP size accordingly (from which the drivers usually take their buffer memory from). This you can do in config.h [OUR_HEAP_SIZE] but remember that this also has to be taken from the available RAM and there needs also to be adequate stack space in RAM for the code to do its normal work. The memory use can be monitored and should also be monitored generally to know what the present usage is and what space is still available for further extensions or optimisations. Details about how to do this can be found here:
http://www.utasker.com/forum/index.php?topic=468.0
http://www.utasker.com/forum/index.php?topic=96.msg384#msg384

The memory usage can be requested with the "memory" command in the "statistics" menu (command line memory) or is diaplayed on the administrator web page when working with the web server example.

Regards

Mark

PS. Note that Kirin3 has up to 64k RAM and so its heap size can be set much higher

[rad]

Hi Mark,

Thank You for Your professional reply to My sily questions;) I played a bit with My configuration, and with fresh uTasker V1.4. In My configuration I use M5223x demo and in original is used M5225x (both I test in simulator). If I use SD card and try to execute command sect 0, both configurations behave the same (as in My previous post- probably due to the same tx buffer size- 256 bytes), but when I try for example print 0menu.htm, it prints much more characters correctly. It means, that You use different routines for print and sect or info?

Also, I couldnt get working ftp in My configuration, even if I increase heap size and use original tx buffer. I looked at the original heap size and M5225x has defined 23.5 kb heap and M5223x 21 kb. I also check heap size in statistic page and heap seems to be big enougth. Stack is always 0x0 but I read somewhere that it is normal in simulation (I hope I remember it well;)) Actually I dont need FTP now, just ethernet, Http, utFat and UART is enought for Me. But I dont know how to copy and verify files into simulated sdcard in other way (before I start to write some routines). I also couldnt start web server from sd card. If I copy some http file into sd card (in root or directory dir1), it still displays error 404 (I use original config. with kirin 3). I also rename some file "index.htm" but it doesnt help. Do You have any idea? I know, problem is probably between keyboard and chair, so I appologize for My sily questions

Regards, Rad

[mark]

Hi Rad

The "print" command allows long file content to be printed since it uses the same method as used by the command line menu - it simply writes until the buffer gets full - suspends - waits for the buffer to empty - writes more until full again - suspends - waits for the buffer to empty - writes more until full again - suspends -  ... etc.  It can thus print out infinite file length content even with small UART output buffer size.

The "sect" and "info" commands just throw all that they have to the debug output and expect that it can buffer it.

When simulating, the remaining stack size will always be displayed as 0 (the uTasker simulator doesn't/can't simulate stack use). It will however not be restricted when simulating since the PC has huge stack size (which it uses) - this value is only of relevance on the target.

When working with the HTTP server from SD card you need to have a directory called "dir1" (this can be changed by modifying the define HTTP_ROOT). It then tries to retrieve the file dir1/index.htm (the file is defined by DEFAULT_HTTP_FILE and can also be changed if required). Therefore ensure that you have the index file in the correct directory.
It may be necessary to reset once after creating the directory (not exactly sure without trying again) although the code does look to check each time a connection is established.

The only real way to get files to the simulated SD card is by using FTP but you can copy these in any project (where FTP is working normally) and then simply copy the file SD_CARD.bin to other project (where FTP isn't operational). I have a directory with various interesting SD card contents which I can then use when needed without having to load files each time.

I don't know why FTP should stop working but you should be able to debug this by checking why the TCP reception decides to reset the connection rather than accepting it.

Regards

Mark