Messages

1

NXP^TM LPC2XXX and LPC17XX / Re: Receiving UDP packets at a rate of 10ms

« on: November 06, 2014, 03:27:30 PM »

Hi Mark,

thanks to your explanation I could solve the problem.
The reason was that I use µTasker in a bit a different way. I manually activate a task and than call uTaskerSchedule() at a time when it cannot interfere with the sampling process for instance.
Now I call uTaskerSchedule() in the mainloop exactly when I need the data and the listener callback function provides the most recent results.

ETHERNET_RELEASE_AFTER_EVERY_FRAME  and ETHERNET_RELEASE_LIMIT do not exist in my version of µTasker.

Thank you very much for your immediate response. That was very helpful!

Kind regards,

Martin

2

NXP^TM LPC2XXX and LPC17XX / Receiving UDP packets at a rate of 10ms

« on: November 05, 2014, 02:26:01 PM »

Hi Mark,

I am facing a problem regarding the UDP reception.

So far I have been sending UDP data blocks periodically (from within the main loop) and have been receiving nonperiodic commands per UDP. That is all ok. Nothing to complain.

Now I created an additional socket to receive UDP data periodically from a sensor. The data is sent every 10ms, I could check that with WireShark. The problem is that the listener function is not called at the same interval. Instead it is called for instance 5 times every 100...200µs (1 data packet per call), but the next five data packets are delivered 50ms later. So 5 packets per 50ms is ok if one only looks at the amount of data. It seems that no data gets lost.
Obviously µTasker is optimizing how often the listener function is called.

This is how the socket is obtained:
  scUdpMotionSocket = fnGetUDP_socket(TOS_MINIMISE_DELAY,
    fnUdpMotionListener,
    0                     
    | UDP_OPT_CHECK_CS); 

I thought that the parameter TOS_MINIMISE_DELAY might have something to do with the problem, but the function description says that this parameter is not used. (I am using µTasker V1.4.)

The problem is that I need actual data.
Is there a way to "persuade" µTasker to call that special listener function immediately when data is received, i.e. every 10ms?
Or even better, to call the listener on request. I only need the most recent data package. In that  case it would not matter if 5 packets were sent as a group.


Kind regards,
Martin H.

3

utFAT / Re: How to detect if SD card formatting has finished

« on: March 28, 2014, 08:34:37 AM »

Hi Mark,

I suppose I will prefer polling.
Thank you so much for your immediate reply!

Regards,

Martin

4

utFAT / How to detect if SD card formatting has finished

« on: March 27, 2014, 11:26:20 AM »

Hi Mark,

Referring to uTasker_utFAT.pdf/V0.09 I would like to add the re-format and fformat features to a LPC2468 project.
The function utFormat() returns UTFAT_SUCCESS if the formatting/re-formatting has started successfully.
But as formatting can take some time, is there a way to find out if formatting has finished so that new files can be written?

utDeleteFile() deletes single files. I suppose this function cannot be used to delete several files in the root by specifying files using wildcards? Something like *.* or obj*.* ?

Regards,
Martin

5

NXP^TM LPC2XXX and LPC17XX / Re: SD card: Boot sector not readable

« on: October 16, 2013, 08:38:45 AM »

Hi Mark,

data storage was still in progress this morning. 964 files had been stored meanmwhile.
Comparison of 10 files proofed that the files were identical.
Hopefully I will get the same results with more cards of the same type from SanDisk.
It still has to be checked however if enabled interrupts have any influence on the result. So far all of them had been disabled.

So if you modify the driver I would be delighted to hear about the results. Especially that code that led to an infinite loop still seems to be a weak point.

But for the moment I am happy with the results.
Thank you for all.

Regards,
Martin

6

NXP^TM LPC2XXX and LPC17XX / Re: SD card: Boot sector not readable

« on: October 15, 2013, 02:56:40 PM »

Hi Mark,

thanks for your trouble and your very comprehensive investigations!

Yesterday the 32GB card from SanDisk arrived.
Right from the beginning I could store files of 32032036 bytes in size within 2'50'' to 2'58' (about 174kB/s). I had it running over night and after 197 files had been written  it stopped because an external event was missing. But as soon as that event was reestablished storing files was continued.

I will have it running again tonight and do some file comparison tomorrow.

Regards,
Martin

7

NXP^TM LPC2XXX and LPC17XX / Re: SD card: Boot sector not readable

« on: October 10, 2013, 08:22:00 AM »

Hi Mark,

just a remark on aborting:
I set a counter to exit that infinite loop after a certain time, deleted MCIStatus bits 10...0 and repeated the function call of _fnGetSector().
That did not lead to a solution - the loop remained infinite.

Regards,
Martin

8

NXP^TM LPC2XXX and LPC17XX / Re: SD card: Boot sector not readable

« on: October 08, 2013, 02:31:55 PM »

Hi Mark,

do you mean I should undefine SD_CONTROLLER_DMA and SD_CONTROLLER_AVAILABLE?
I am afraid I can't do that. The board is a LPC2468-16 OEM board from EA. They use ports P1.2, P1.6, P1.3. For none of these pins a MISO, MOSI or SCLK function can be selected.

I finally disabled all interrupts and repeated tests with different MCIClocks (18MHz... 2.25MHz).
The Kingston Micro SDHC (SDC 10/32) did not store the whole amount of 31282kB reliably neither with SD_CONTROLLER_DMA defined nor
without. That means in most cases it hang before the whole file was written. Though it has to be mentioned that the amount of stored 512-byte-blocks sometimes was very high before the programm hang in _fnGetSector().
(In the rare cases when it passed the storage test, it took less then 3 minutes (MCIClock=18MHz, DMA enabled) to store the data.)

At that infinite loop MCIStatus was either
  0x20 - RxOverrun Receive FIFO overrun error.
  or
  0x200- StartBitErr - Start bit not detected on all data signals in wide bus mode.

The Kingston SDC 4/4GB 18 did a better job.
But in DMA mode with MCIClock=18MHz it took nearly 20 minutes (!!!) to store 31282kB.
Without DMA mode MCIClock had to be reduced to 4,5MHz. The time required for the same amount of data was about the same.
It still has to be checked whether or not data is stored reliably, i.e. each time the whole amount of data. But that is too slow anyway.

Perhaps a class 10 SD card of another manufacturer might do a better job?
What SD card did you use for testing?
Or can you recommend a special type / manufacturer?
Did you do the tests with a large data block or just a small one?

Regards,
Martin

9

NXP^TM LPC2XXX and LPC17XX / Re: SD card: Boot sector not readable

« on: September 22, 2013, 12:43:12 PM »

Hi Mark,

I did some further investigation on that issue and it seems - as you said - that the MCI_CLK_PwrSave is not responsible for the
trouble.
I have made some progress and meanwhile can write files to the SD card.
The tests I made so far were limited to small files, so no further errors arised.

Now, to store nearly 32MB of data to a SD card, I am running a loop that puts 512 bytes per loop cycle into the file:

Code: [Select]

   while(j) {      // j here is 62765
      Sd.Anz = 512;
      result = utWriteFile(&Sd.utFile, Sd.ptSrc, Sd.Anz);
      if(result != UTFAT_SUCCESS) {   // Fehler
        ErrorPrint("File write error: ", -1); printf("%x %s", result,Sd.ptWrFileName);
      }
      SendMsgU0(" %x", k-j);  // to monitor how many loops are done finally
      // some results: 0x5fE, 0x60fE,0x269E, 0xE8DE

      j -= 1;
      Sd.ptSrc += Sd.Anz;  
    }The programme still hangs in function _fnGetSector() at

Code: [Select]

  while (!(MCIStatus & DataEnd)) { }   // wait until the DMA has completed the transfer to the destination bufferbut this time lots of write operations were succesful.
(The contents of location 0xe008c034 (MCIStatus) remains at 0x200,
i.e. StartBitErr - Start bit not detected on all data signals in wide bus mode.)

The clock already has been reduced from 18 to 9MHz as I remembered your comment regarding 18MHz.
Also the 2 delay times in function _fnGetSector() have been increased temporarily.
The test was done in debug mode and as a release.
I might try reduce the clock to a value beneath 9MHz but that would slow down the whole process and I can't imagine that this would solve the problem.

Perhaps it would be best to have a time-out loop and try to rewrite the last memory block.
But when I do that, re-initialize the SD card and try to open the last file, utOpenFile() returns a UTFAT_DISK_READ_ERROR.
Does anybody have a better suggestion? One that eliminates the reason for that fault?

Thanks!
Martin

10

NXP^TM LPC2XXX and LPC17XX / Re: FTP access to SD card

« on: September 12, 2013, 03:44:33 PM »

Hi Mark,

thanks for your reply.

1) Would you suggest to put something like the following into ctTaskTable[]
   { "R_MassSt",    fnMassStorage,  MEDIUM_QUE,  0, 0, UTASKER_GO},
and set iMemoryState = SD_STATE_STARTING to stard card initialisation?

The intention is to schedule utasker just once during a cycle (duration of 20...30ms) by invoking 'uTaskerSchedule()'.
Then data shall be stored to the SD card. But it shall also be possible to prevent storing data for some cycles. Accessing the SD card must be done at a defined position within the cycle, i.e. after sampling has been finished. A uTasker timer would not meet that requirement, I am afraid.

2) Using DOS FTP (Windows 7) the 'dir' command is accepted.
The command 'get file222' however results in this:
  200 OK.
  150 Data.
Nothing more.
After some seconds uTasker runs in an infinite loop at 0xF4:
  b 0x000000f4
The call stack from Rowley's CrossStudio just says '(Unknown Function)', no further information about previous steps.
In this special case it is the data abort exception.
Restoring the last command lead to the function
  uMemcpy(ptrValue, fnGetFlashAdd(ParLocation), Size);
which is invoked in
  static void fnGetPars(unsigned char *ParLocation, unsigned char *ptrValue, MAX_FILE_LENGTH Size)
The call stack shows these values
  Size         0x4000f73c
  ptrValue     0x4000f73c
  ParLocation  0x4000f8a7
Size obviously is wrong.
So it looks like a memory problem. (MEM_FACTOR for the heap has already been increased to 1.2.)


I also tried to exchange ftp.c, but the file you attached did not contain a definition for
  _TCP_SOCKET_MASK
  _TCP_SOCKET_MASK_ASSIGN
It could not be found in uTasker version 8 either.
Could you let me know what the definition is, please?


Regards,
Martin

11

NXP^TM LPC2XXX and LPC17XX / Re: FTP access to SD card

« on: September 10, 2013, 01:52:31 PM »

Hi Mark,

the problem was caused by an additional line I had added to the macro CONFIGURE_SDCARD_INTERFACE:
  ...
  PINSEL2 &= ~(3<<10 || 3<<6 || 3<<4 || 3<<12 || 3<<14 || 3<<22 || 3<<24);
           //  MCIPWR  MCICMD  MCICLK  MCIDAT0  MCIDAT1  MCIDAT2  MCIDAT3 
  ...
The intention was to set the bits to its default status to asure that the OR operation in the next line
  PINSEL2 |= (  PINSEL2_P1_3_MCICMD | PINSEL2_P1_2_MCICLK | PINSEL2_P1_6_MCIDAT0 | PINSEL2_P1_7_MCIDAT1 | PINSEL2_P1_11_MCIDAT2 | PINSEL2_P1_12_MCIDAT3);
would set the right bits.
For some reason that failed and that code had to be removed.

1. SD card access
Now with the following code in the main loop I can establish a ftp connection to the SD card.
    ...
    uTaskerStateChange(TASK_MASS_STORAGE, UTASKER_ACTIVATE);  // status when fnMass_Storage() is reached: MemoryOperation == _INITIALISED_MEMORY
    uTaskerSchedule();
    ...
I can see the file names on the SD card but I cannot copy/open the files (deleting is possible!).
(Reducing the clock rate from 18MHz to 9MHz did not make any difference.)

Instead I get an error message "Error downloading file" after some time.
The following events are monitored at the beginning of fnFtpListener() (before 'switch') after trying to copy a file:
 5   TCP_EVENT_CLOSE
 1   TCP_EVENT_ABORT

 8   TCP_EVENT_CONREQ
 2   TCP_EVENT_CONNECTED
 3   TCP_EVENT_ACK
 4   TCP_EVENT_DATA
 3 4 .. 3 4
 a   TCP_EVENT_PARTIAL_ACK
 7    TCP_EVENT_REGENERATE
 a 7 .. a 7
 a   TCP_EVENT_PARTIAL_ACK
 1   TCP_EVENT_ABORT

 8 2   
 3 4 ... 3 4
 1

 8 2
 3 4 ... 3 4
 3
 5
 1

 In fnFTP_Data_Listener() (seperate test) the following events were logged twice:
 8   TCP_EVENT_CONREQ
 2   TCP_EVENT_CONNECTED
 a   TCP_EVENT_PARTIAL_ACK
 7   TCP_EVENT_REGENERATE
 a   TCP_EVENT_PARTIAL_ACK
 3   TCP_EVENT_ACK
 ...
 3
 1   TCP_EVENT_ABORT

Does that information lead to any conclusion?

2. File system access (for bootloader)
Now that I can connect to the SD card (but still not being able to copy files), how can I connect to the file system to load an update?
When the TASK_MASS_STORAGE is not activated periodically in the mainloop then a ftp connection to the file system is achieved and uploading a file is fine.
But how would I select either the SD card or the file system using the ftp client (for instance TotalCommander in this case)?

3. File size
Is there a size limitation for files on the SD card?

TCP is basically operating, a simple html file (uploaded to the file system) was invoked by the browser.

Regards,
Martin

12

NXP^TM LPC2XXX and LPC17XX / FTP access to SD card

« on: September 06, 2013, 12:15:09 PM »

Hello,

with my LPC2468 project, which is based on uTasker vs.4, I am able to update the code using ftp (BARE MINIMUM BOOTLOADER).
Now I have implemented mass_storage.c from uTasker vs.8 and I can create files and perform write and read operations to/from a 32GB SD card.

The problem is that it is no longer possible to get a FTP connection.
That means the Bare Minimum Bootloader cannot be used any longer (which was fine before) and there is no access to the SD card via FTP of course.

fnConfigureFtpServer() still is reached (invoked from the application task), but fnFTPListener() is not.
I have tracked the problem down to fnTaskEthernet():
  When the FTP connection is initiated on the client side, fnTaskEthernet() receives IP_UDP instead of IP_TCP.
   
Compared to the version that is running (ftp ok, mass_storage.c not implemented) just 'R' has been added (TASK_MASS_STORAGE):
W, A, E, T, a, R, D, d, S, X, V

Does anybody have an idea what might have gone wrong?
Any suggestions how to procede are highly appreciated!

Regards,
Martin
attached: TaskConfig.h

13

NXP^TM LPC2XXX and LPC17XX / Re: Performance of TELNET like protocoll

« on: June 14, 2013, 03:08:54 PM »

Hi Mark,

thank you for your immediate reply.

Increasing the buffer made it possible to send more data.
But as this buffer is in the heap and the amount of data I have to transfer in each cycle is rather high (it is sampled data), I cannot pass the whole size to fnSendBufTCP() as a parameter.

3 basic questions regarding the TELNET like protocol (raw mode) I would like to ask:
- Is it correct that  I do not have to care for the ACK and TCP will automatically free buffer occupied by fnSendBufTCP() as soon ACK is received?
- Will retransmission be done automatically? Or is it necessary to care for the event TCP_EVENT_REGENERATE?
- Will TCP_EVENT_PARTIAL_ACK be handled automatically?

I thought I could do the following to handle a bigger amount of data::
- In the  task that is called periodically I check for sufficient memory and then send 2 frames,  each with a length of 1400 (=TCP_BUFFER_FRAME).
(2 frames to avoid delayed acknowledge from the client.)

Code: [Select]

jj = fnSendBufTCP(Tx_Telnet_Socket,(unsigned char *)&OurTask, BlockLen, TCP_BUF_CHECK);
if (jj) {
    DataLen -= BlockLen;
    qt = fnSendBufTCP(Tx_Telnet_Socket, ptBuf, BlockLen,  (TCP_BUF_SEND | TCP_BUF_SEND_REPORT_COPY)   ); where BLOCKLEN=2800 and DataLen is the total amount of data to be sent, for instance 2900.
The result is qt=1400, probably because the second block is sent a bit later. Wireshark reports 2 frames of 1400 bytes each.

- The remaining bytes (100 in the example) shall be sent in the listener function when TCP_EVENT_ACK is received (and TCP has freed the buffers).
I set breakpoints and - as expected - the sending task is invoked first  and then the debugger stops when TCP_EVENT_ACK is received.

In the listener function:

Code: [Select]

UTASK_TASK OurTask = TASK_TELNETCMD;  // 'x'
jj = fnSendBufTCP(Tx_Telnet_Socket,(unsigned char *)&OurTask,           BlockLen, TCP_BUF_CHECK);
Curiously the 100 bytes only get sent at the beginning.
It seems that I am making a principal mistake as 2*1400 bytes are always sent(Wireshark). Also the listener is not invoked at least once per period.
Most likely the question is “Which event frees the buffers?” Would you agree?


Which setting in tcpip.h reduces transmission delay? Why would I want to have a delay?

Regards,
Martin

14

NXP^TM LPC2XXX and LPC17XX / Performance of TELNET like protocoll

« on: June 12, 2013, 02:55:52 PM »

Hi Mark,

I am currently testing the TELNET like protocol for data transfer to a TCP client. The aim is to achieve a maximum transfer rate and retransmission if necessary.

The task
  fnSendTelnetCmd(TTASKTABLE *ptrTaskTable)
is invoked periodically every 50ms.

This task checks if buffer is available
   jj = fnSendBufTCP(Tx_Telnet_Socket,(unsigned char *)&OurTask, TelTx.usLen, TCP_BUF_CHECK);

and if so it transfers the data:
  if (jj >0) {
qt = fnSendBufTCP(Tx_Telnet_Socket, (unsigned char *) &TelTx.Buf , TelTx.usLen,  (TCP_BUF_SEND  |  CP_BUF_SEND_REPORT_COPY)   );

    }

The following settings have been left unchanged:
    #define TCP_BUFFER  2800   
    #define TCP_BUFFER_FRAME      1400

Everything is ok as long as 2100 or less bytes have to be transferred, i.e. every 50ms that amount of data goes out in 2 blocks - 1 is 1400 bytes long and the other one contains the remaining bytes. For instance 2100-1400=700 bytes.
I have checked that with WireShark.

Greater payloads lead to jj=0 (check for  available buffer size). jj then is 0 for several periods. No data is sent.

The decision whether or not to return 0 is made here in fnSendBufTCP():

#ifdef WAKE_BLOCKED_TCP_BUF 
if (tcp_tx->usWaitingSize + tcp_tx->usPacketSize + usDataLen > TCP_BUFFER) {
            tcp_tx->WakeTask = *ptrBuf;                // mark task to wake when buffer free
            return 0;                                       // not enough space to send intended buffer
        }
        else { …}
 }
 #endif

where
  tcp_tx ->usWaitingSize = 0
  tcp_tx->usPacketSize = 900 = 0x384
  usDataLen = 2300

tcp_tx->usPacketSize seems to be the second block that not yet has been sent.
What could be the reason for that?
Is it a missing ACK? How should that be handled?

I could try to run fnSendTxBuf() several times with usDataLen<=1400, i.e. activate the Task and run uTaskerSchedule() several times
But is that really the recommended procedure?


Regards,
Martin

15

NXP^TM LPC2XXX and LPC17XX / Re: TCP_WINDOW_UPDATE received by FTP listener

« on: June 06, 2013, 07:55:35 AM »

Hi Mark,

thanks a lot for your reply.

We meanwhile received the latest update of C++ Builder. Your remark regarding multiple data connections caused us to modify some options. Finally, disabling the option 'UseHost' for the compilation of the ftp client most likely solved the problem.
I say 'most likely' because the job has not yet been finished. But at least the client can connect to the server and receives a response, I was told.
We will still have to do some further investigation.

Regards,
Martin