Messages

16

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

« on: June 03, 2013, 10:21:16 AM »

Hi Mark,

we are using uTasker's ftp-server to update the embedded application. Together with TotalCommander this does a good and reliable job.
Now we intend to integrate TotalCommander's part into the application that runs under Windows using the Indy ftp-client from C++ Builder XE4.
That does not work.
I compared the events received by fnFTPListener() and found that our Windows application (created by C++ Builder, i.e.the Indy ftp-client) sends
event 0x0B (TCP_WINDOW_UPDATE), which TotalCommander does not do.
This happens at a very early stage:
   events received
   08   TCP_EVENT_CONREQ
   02   TCP_EVENT_ACK
   04   TCP_EVENT_DATA
   0b   TCP_WINDOW_UPDATE
   ...
Indy's documentation offers several settings for the ftp-client but it is very unprecise about which one to chose.

Ignoring this event on uTasker's side by adding 'case TCP_WINDOW_UPDATE: break;' to the event listener did not help.

I understand that this event is used for flow control between the peers, but the question remains how uTasker should react.
Or - as 0x0B obviously is not required - perhaps somebody knows (or could give some hints) what settings are required for creating the ftp-client.

Regards,
Martin H.

17

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

« on: April 05, 2013, 01:09:07 PM »

Hi Mark

no, I am not sure, but I did not find another explanation so far.
Until I have found one, I am afraid I will have to toggle the bit.

Regards,
Martin

18

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

« on: April 02, 2013, 02:40:47 PM »

Hi Mark,

yes, that is the loop.
Independently of whether SD_CONTROLLER_DMA is defined or not it comes to an infinite loop in _fnGetSector().
Either at

Code: [Select]

    while (!(MCIStatus & DataEnd)) {    // wait until the DMA has completed the transfer to the destination buffer
    }or at

Code: [Select]

    while ((MCIStatus & (DataEnd | RxDataAvailbl)) != DataEnd) {         // while data is still being received
The reason for that is that I had changed initialization in SET_SPI_SD_INTERFACE_FULL_SPEED().
I had NOT set the MCI_CLK_PwrSave bit for register MCIClock and this caused the malfunction.
That is a little bit annoying because MCICLK (18MHz) is needed as a masterclock in the project and setting the bit means that clock output is only enabled when the bus is active.
Is there a chance to have the clock output always enabled and nevertheless access the SD card?

Regards,

Martin

19

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

« on: March 20, 2013, 02:24:03 PM »

Hello,

I am just trying to adapt parts of mass_storage.c from version 8 to my project (derived from version 4, LPC2468).
The SD card I am using is a Kingston SDHC 4GB class 4 card.
MCIClk has been raised to 18MHz. The card shall run in 4-bit-mode, no DMA so far.

The problem is that the bootsector cannot be read.
In _fnGetSector() the condition
    (MCIStatus & RxDataAvailbl)
never is met, which results in an infinite loop.

The SDHC card has been formatted (FAT32) by WINDOWS, hence it has no password and is not locked I should think.

The initialisation phase is passed without obvious problems.

Coming to Cmd16, I found that the command array is
static const unsigned char ucSET_BLOCK_LENGTH_CMD16[5]  = {SET_BLOCKLEN_CMD16, 0x00, 0x02, 0x00, 0x02};
It seems that the block size here is >512 bytes which results in setting the BLOCK_LEN_ERROR bit.
But as SDHC cards always use a block size of 512 bytes this may not be important.

READ_SINGLE_BLOCK_CMD17 is passed with ucresult==0.
But with the following function
fnGetSector(ptr_utDisk->ptrSectorData)
the infinite loop in _fnGetSector() is reached.

Can anybody thing of a reason why the boot sector cannot be read?

Regards,
Martin

20

NXP^TM LPC2XXX and LPC17XX / Re: Ethernet DMA for LPC23XX project

« on: January 21, 2013, 10:20:00 AM »

Hi Mark,

the transfer rate has been increased to about 71Mbit/s ( tested with 8 data blocks: 11036 bytes pure payload in 1.23ms).
The checksum of the payload, however, has not been calculated, due to the great amount of time that would be required.
I am quite happy with the result, perhaps that can be improved in the future by arranging the source buffers in a different way.
But for now it is ok.
Your hints have been very helpful!
Thank you very much!

Regards,
Martin

21

NXP^TM LPC2XXX and LPC17XX / Re: Ethernet DMA for LPC23XX project

« on: January 11, 2013, 03:21:51 PM »

Hi Mark,

the first test was successful. With the buffers in external SDRAM transfer was ok.

I would prefer to avoid using the scatter-and-gatter capabilities - for simplicity reasons.
But putting the IP/UDP header before the payload means to overwrite previous data (at least for the second and all following blocks). And - as you wrote  - data has to be held stable until transmission has finished.
Principally I might fill the IP/UDP header immediately after fnStartEthTx() has been called. But I fear that doing so might overwrite the previous block before it has been sent.
Do you know of a criteria that tells us if the contents of  the buffer has been completely sent and the buffer is free for writing?

Regards,
Martin

22

NXP^TM LPC2XXX and LPC17XX / Re: Ethernet DMA for LPC23XX project

« on: January 09, 2013, 02:00:38 PM »

Hi Mark,

I must admit that I over and over again had ignored that passage in the manual because everything seemed to be so obvious.

As in my case, the amount of data that has to be transmitted is a multiple of 1472. I thought about transmitting the data blocks directly from SDRAM (0xA000 0000…).
The idea is to send the first block as usual, i.e. the data is copied to the Ethernet RAM first (for instance ptTTYQue->ETH_queue.put=0x7fe02a70). When it comes to the following blocks, there is enough free memory before that next block in SDRAM . This memory can be overwritten by that ucData[MAX_IP] block that is created in fnSendIP().
So if the pointer at ucData[] (in the SDRAM, before the data block)  could  be given to an appropriate routine the whole amount of date could be transmitted block by block directly from the external SDRAM. So using memcpy() for that large amount of data would be avoided. And as the transfer protocol is udp, retransmission of erroneous data is not necessary.
My investigations so far ended at fnStartEthTx() where data is sent.
Though I am not yet familiar with that EMAC_TxDescriptor and EMAC_TxProduceIndex, is that a possible way to safe time?
Or is it a stupid idea? I mean if the data that needs to be sent has to be in the Ethernet RAM, all that would make no sense.
What is your opinion?

Regards,

Martin

23

NXP^TM LPC2XXX and LPC17XX / Re: Ethernet DMA for LPC23XX project

« on: November 16, 2012, 09:13:47 AM »

Hi Mark,

that is surprising me.
I am using LPC2468 and the manual says:

“30.3 Features of the GPDMA
…
• Memory-to-memory, memory-to-peripheral, peripheral-to-memory, and
peripheral-to-peripheral transfers”

I am aware that the project was made for LPC2368, but the manual for LPC2368 contains the same information.

Regards,
Martin

24

NXP^TM LPC2XXX and LPC17XX / Re: Ethernet DMA for LPC23XX project

« on: November 15, 2012, 04:12:20 PM »

Hi Mark,

so with other words the suggested way to speed up the whole transfer is to use uMemcpy() with DMA ?
Has that DMA transfer with uMemcpy() already been realized in the project?
At least I did not find the DMA initialisation. Could you give me a pointer?

Regards,
Martin

25

NXP^TM LPC2XXX and LPC17XX / Ethernet DMA for LPC23XX project

« on: November 08, 2012, 09:17:05 AM »

Hello,

we are using the LPC23XX project to transfer data via ethernet (UDP protocol). Now that the amount of data has increased we are looking for a way to speed up transfer.
As a first step checksum calculation in fnSendUDP() has been cancelled.
That led to a transfer rate of 2,93ms per 11060 bytes, i.e. 265ns/byte as an average.

The next idea is to use DMA for transfering the data.
Has such an ethernet DMA transfer ever been realized with that LPC2XXX project?
Does anybody know of an appropriate project or can give some hints where to start?
Any comment would be welcome.

Martin H.