topic Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data in i.MX Processors

i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Wed, 26 Feb 2014 18:56:38 GMT

Hi,

We are using the i.MX28 with the current BSP and have noticed that the UART serial interface is losing data. On closer inspection of the driver I think I have found a bug in the code and could do with some support to resolve this.

The serial receive interrupt handler function is defined as ULONG SL_RxIntrHandler(PVOID pContext,PUCHAR pTargetBuffer,ULONG *pByteNumber) at the following path:

C:\WINCE600\PLATFORM\COMMON\src\soc\COMMON_FSL_V2_PDK1_9\SERIALAPP\COM_PDD\serialhw.c

The parameters are defined as:

// pContext

// [in] Pointer to device head.

// pTargetBuffer

// [in] Pointer to the target buffer in which to put the data.

// pByteNumber

// [in] Pointer to, on entry, the maximum number of bytes to read. On exit, the number of

// bytes read.

This follows the Microsoft function prototype for HWRxIntrHandler.

I have found that the pByteNumber value is not the number of bytes to read but a decrementing value each time a block of data is received. On the first receive the value is 2047, and then for each block of received data this value decrements by the size of the last received block each time the RX interrupt handler runs.

Eventually the pByteNumber passed gets lower than the size of the next block of data received. In this case the remaining data is thrown away and the value reset to 2047. I have some debug output to show this:

Below I am sending chunks of 409 bytes into the serial port. The 'len' value in the SL_RxIntrHandler+ debug output is actually the *pByteNumber value - clearly not the number of bytes received and also decrementing on each receive.

The ByteRead value is what the RX interrupt got out of the receive - not always 409 bytes.

4491457 PID:400002 TID:1a50006 Rx Event

4491457 PID:400002 TID:1a50006 SL_RxIntrHandler+ : len 2047. EvtChar 0x1a

4491457 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=0,W=0,BA=0,L=2048) ByteRead=409

4491907 PID:400002 TID:1a50006 Rx Event

4491907 PID:400002 TID:1a50006 SL_RxIntrHandler+ : len 1639. EvtChar 0x1a

4491907 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=409,W=409,BA=0,L=2048) ByteRead=409

4494129 PID:400002 TID:1a50006 Rx Event

4494129 PID:400002 TID:1a50006 SL_RxIntrHandler+ : len 1230. EvtChar 0x1a

4494129 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=818,W=818,BA=0,L=2048) ByteRead=409

4494753 PID:400002 TID:1a50006 Rx Event

4494753 PID:400002 TID:1a50006 SL_RxIntrHandler+ : len 821. EvtChar 0x1a

4494753 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=1227,W=1227,BA=0,L=2048) ByteRead=409

4497799 PID:400002 TID:1a50006 Rx Event

4497799 PID:400002 TID:1a50006 SL_RxIntrHandler+ : len 412. EvtChar 0x1a

4497799 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=1636,W=1636,BA=0,L=2048) ByteRead=409

4498068 PID:400002 TID:1a50006 Rx Event ********** 409 chars are sent in here but after the function it only reads 3 and throws the rest away *************

4498068 PID:400002 TID:1a50006 SL_RxIntrHandler+ : len 3. EvtChar 0x1a

4498068 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=2045,W=2045,BA=0,L=2048) ByteRead=3

4500466 PID:400002 TID:1a50006 Rx Event

4500466 PID:400002 TID:1a50006 SL_RxIntrHandler+ : len 2047. EvtChar 0x1a ********** len 'counter' value back to 2047 *************

4500466 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=0,W=0,BA=0,L=2048) ByteRead=409

4500906 PID:400002 TID:1a50006 Rx Event

4500906 PID:400002 TID:1a50006 SL_RxIntrHandler+ : len 1639. EvtChar 0x1a

4500906 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=409,W=409,BA=0,L=2048) ByteRead=409

The calling function SerialEventHandler() is in the freescale file mdd.c at the following path and calls the above using a function pointer as pFuncTbl->HWRxIntrHandler:

C:\WINCE600\PLATFORM\COMMON\src\soc\COMMON_FSL_V2_PDK1_9\SERIALAPP\COM_MDD2\mdd.c

As part of this function it calculates a 'RoomLeft' variable and passes a pointer to this in to the HWRxIntrHandler as the 'pByteNumber' parameter. Clearly this is not the correct thing to be passing.

if ( RxRIndex == 0 ) {

// have to leave one byte free.

RoomLeft = RxLength(pSerialHead) - RxWIndex - 1;

} else {

RoomLeft = RxLength(pSerialHead) - RxWIndex;

}

if ( RxRIndex > RxWIndex ) {

RoomLeft = RxRIndex - RxWIndex - 1;

}

if ( RoomLeft ) {

pSerialHead->DroppedBytesPDD +=

pFuncTbl->HWRxIntrHandler(pHWHead,

RxBuffWrite(pSerialHead),

&RoomLeft);

} else {

BYTE TempBuf[16];

RoomLeft = 16;

pFuncTbl->HWRxIntrHandler(pHWHead,

TempBuf,

&RoomLeft);

I would have thought that the RX handler would be passed the number of bytes to extract from the DMA memory and return how many it managed to read on that interrupt. Therefore I do not understand why it is a decrementing number.

Anyway it is clear that the Freescale i.MX28 Windows CE 6.0 BSP throws serial data away due to the above issue.

Can anyone help me with this?

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Thu, 27 Feb 2014 14:23:17 GMT

Testing this a little further it seems the buffer pointer calculations made in mdd.c for the application serial port are incorrect. I need to try and understand a little more about the driver but running through with the debugger it seems that the receive buffer read pointer does not always keep up with the write pointer.

In the instance that the two are equal and not zero the calculation for buffer space remaining is:

RoomLeft = RxLength(pSerialHead) - RxWIndex;

Which is odd. If both pointers are the same and at say byte 2040 then it thinks that there is only 2048-2040 = 8 bytes available to use? Technically the whole buffer is available to use?

I will keep looking through the code but I assume this same driver code is cloned for other Freescale i.MX BSPs? Does anyone else see this issue?

Regards, Mark

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Thu, 27 Feb 2014 14:49:20 GMT

Looking back at my debug output again you can actually see that after getting the serial bytes the Read and Write pointer values are updated but are the same:

4491457 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=0,W=0,BA=0,L=2048) ByteRead=409

491907 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=409,W=409,BA=0,L=2048) ByteRead=409

4494129 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=818,W=818,BA=0,L=2048) ByteRead=409

4494753 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=1227,W=1227,BA=0,L=2048) ByteRead=409

4497799 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=1636,W=1636,BA=0,L=2048) ByteRead=409

4498068 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=2045,W=2045,BA=0,L=2048) ByteRead=3

4500466 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=0,W=0,BA=0,L=2048) ByteRead=409

4500906 PID:400002 TID:1a50006 After HWGetBytes, Fifo(R=409,W=409,BA=0,L=2048) ByteRead=409

The problem seems to be the buffer space remaining calculation in mdd.c, which I have now found must originate from Microsoft as I have seen the same calculation in other BSPs.

if ( RxRIndex == 0 ) {

// have to leave one byte free.

RoomLeft = RxLength(pSerialHead) - RxWIndex - 1;

} else {

RoomLeft = RxLength(pSerialHead) - RxWIndex;

}

if ( RxRIndex > RxWIndex ) {

RoomLeft = RxRIndex - RxWIndex - 1;

}

In the case where RxRIndex != 0 but RxRIndex == RxWIndex the calculation uses RoomLeft = RxLength(pSerialHead) - RxWIndex;

So each time the receive interrupt occurs the buffer R and W pointers are equal but incrementing. The space left does not account for a cyclic buffer and therefore is also decreasing on each received value.

Mark

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Thu, 27 Feb 2014 15:15:31 GMT

It seems the issue with the i.MX28 serial port stems from the circular buffer calculations. These go back to early Microsoft code though so I am not sure why no one else has seen this issue.

if ( RxRIndex == 0 ) {

// have to leave one byte free.

RoomLeft = RxLength(pSerialHead) - RxWIndex - 1;

} else {

RoomLeft = RxLength(pSerialHead) - RxWIndex;

}

if ( RxRIndex > RxWIndex ) {

RoomLeft = RxRIndex - RxWIndex - 1;

}

The ‘Room Left’ variable is supposed to contain the buffer space remaining. RxLength is the buffer size, 2048. RxRIndex is the read index, and RxWIndex the write index.

Initially the R/W indexes are both 0 so I guess the R index is where to read from next and the W must be the last written byte?

In that first instance RxRIndex is 0, so the first calculation is used = 2048 – 0 – 1 = 2047. This is how much buffer space is reported to the receive interrupt handler (i.e. you can get this many bytes from DMA into my buffer).

After receiving some data the next time the receive interrupt fires both R and W indexes are the same but some other value depending on how many bytes came in last time. I.e. if 2000 bytes were received R and W would both be 2000. The calculation for space should still return 2047 (or 2048?) but the calculation uses:

RoomLeft = RxLength – RxWIndex = 2048 – 2000 = 48 bytes available in the buffer.

The net result is that the available space calculation result is reduced until it is less than the next received chunk of data and some is thrown away.

The last case above seems to cover when the read index is > than the write index. I.e. the write index has wrapped round beneath the read. This seems correct.

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Thu, 27 Feb 2014 15:57:44 GMT

It looks as though the PDD part of the driver in serialhw.c cannot accept a circular buffer which is now making me doubt that this is the intention.

It uses a memcpy function to copy the bytes into the buffer which cannot account for rolling over the end.

If anyone has experience in the Serial mdd/pdd code I would appreciate some help!!

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Fri, 28 Feb 2014 12:08:34 GMT

I have been going round in circles here (which interestingly is what the receive buffer is supposed to do!), but I am finally making sense of the Serial Receive.

Serial data received by hardware under DMA
Interrupt gets data into what is supposed to be a circular buffer in mdd.c in the serial port structure moving on the write pointer if space is available
The higher level application gets data using the COM_Read function in mdd,c, probably called from the top level stream driver ReadFile function

Looking at the COM_Read function it moves the read pointer on as data is extracted by the higher level application / com control and wraps around the buffer if necessary. I.e. if the read pointer is at 2040 (of 2048) and 50 bytes come in, then COM_Read first copies out 8 bytes, then loops around the pointer and copies the remaining 42 leaving the read pointer back at the same location as the write pointer (assuming no more data has been received).

I am now under the impression it is actually the pdd part of the driver that is at fault, which would make sense as I am sure there are loads of BSPs out there using the microsoft mdd part of the serial driver without error.

There are two issues in the Freescale driver:

1) If the received characters cause the buffer to roll round the receive gets the remaining characters to the end of the buffer first, resets the pointer to the beginning but does not return to collect the rest. This is because mdd.c only grabs chars from the DMA buffer while there is an an interrupt to process but the receive interrupt status is clear on the second pass i.e. demonstrated as a 16-byte buffer below:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

R W

If 6 chars are received the first call gets 4 (into 12, 13, 14, and 15) but never returns to put two more at the beginning of the buffer.

2) The DMA handling in SL_RxIntrHandler (serialhw.c) toggles the DMA buffer used each time the function is called to extract data. So even if you did call back in to get the rest of the data it is now pointing at a different buffer

From what I can see the SL_RxIntrHandler function needs to handle copying into the buffer in a circular fashion and keep copying until either the write pointer catches up with the read, or all the bytes received have been successfully copied.

I will try and modify the code but I was wondering if anyone else has had this issue using the i.MX28 BSP?

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Fri, 28 Feb 2014 14:00:48 GMT

I have looked at the i.MX51 BSP and although the SL_RxIntrHandler function has a different implementation it too expects 'Room Left' to be a linear region of memory (current write pointer to end of buffer) without handling an wrap-around.

The SL_RxIntrHandler expects a pointer to the buffer and a length to read. Therefore the SL_RxIntrHandler does not know where the beginning of this buffer is to loop around. It can therefore only read the remaining bytes and it is up to the caller to then ask again for the remaining bytes after wrapping around its circular buffer.

Therefore I believe this will affect the i.MX51 and any other device supported in that BSP too.

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

YixingKong — Thu, 10 Apr 2014 07:25:06 GMT

Mark

Thanks you for your so much input. Are your issues still there? If not, we are going to close the discussion in 3 days. If you still need help, please feel free to reply with an update to this discussion.

Thanks,

Yixing

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Mon, 14 Apr 2014 09:00:52 GMT

Yixing,

Another forum member sent me some code to use but I am not 100% confident in the fix as I do not understand how the two DMA buffers are intended to be used. It does appear to work in testing.

Did Adeneo write the BSP for these parts? Is it possible to obtain support for the BSPs from them? We plan to put this in a production product and we need reliability in the serial port comms.

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

YixingKong — Mon, 14 Apr 2014 09:14:33 GMT

William

Adeneo did not write BSP, instead works as supporter. You may contact Adeneo directly and ask details.

As to DMA buffers, I may find an engineer from Freescale to help you in the question. But that engieer may answer you general DMA question, not Wince questions. Please put your DMA question here.

Thanks,

Yixing

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

JDFAE — Tue, 15 Apr 2014 20:40:24 GMT

Please attach the code to this post so others can check it out.

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Mon, 19 May 2014 11:35:05 GMT

Hi all,

I finally got round to looking at the code for the serial port driver and I believe I have fixed the issue. From my testing I am now receiving all data (whether it wraps-around or not). There are still some parts of the driver I am not too sure about in terms of the decisions made by the original designer to implement the DMA in the way it currently is.

Just to summarise the original issue - the Freescale-supplied Windows CE Application UART driver (C:\WINCE600\PLATFORM\COMMON\src\soc\COMMON_FSL_V2_PDK1_9\SERIALAPP\) does not handle wrapping of the MDD serial receive buffer. If more data is received than there is room at the top of the buffer for, then the additional wrapped data is thrown away. In a packet-based comms protocol this could mean partial packets are lost. With message retries this would potentially be hidden and still work.

The receive is handled by the APBX DMA controller. The DMA command chain for the serial receive consists of two transfers that attempt to transfer the buffer size before generating an interrupt. If a small packet is received a time-out will generate the interrupt. The first DMA command in the chain copies data to buffer 0, the second one to buffer 1.

After the second DMA command the chain is re-initialised (DMA commands reloaded). I am not sure why two DMA buffers are used - if there is enough time to re-initialise the DMA in the interrupt handler then a single buffer could be used.

The problem with the original code was caused by the implementation of the PDD part of the driver. The MDD will call into the PDD while the interrupt is to be processed. To handle buffer wrap-around we need to:

MDD - check the interrupt source by calling into the PDD function SL_GetIntrType - do not clear the status flags at this point
MDD - Calculate the space to the end of the buffer (ignoring wrap around)
PDD - Linearly copy as many bytes from DMA as we can get into the top of the buffer
PDD - Clear the interrupt flag if we copied them all and toggle / re-init the DMA
PDD - Leave the interrupt if the received bytes exceeds the top of buffer space and need to wrap-around - at this point we need to store how many bytes left to read and where in the DMA buffer to get them from
MDD - Move on the write pointer
MDD - see the interrupt is still set (for wrap) and recalculate space to read pointer
PDD - realise we are back in to collect more data from the previous attempt and copy the rest - then clear the interrupt flag
MDD - Move on the write pointer and signal to the read function that there is serial data available

I have implemented this as changes to the PDD. You can see my changes in the two functions: SL_GetIntrType() and SL_RxIntrHandler(). Use a diff tool with the original file for a true comparison. The MDD is the same as supplied.

The file to edit is:

C:\WINCE600\PLATFORM\COMMON\src\soc\COMMON_FSL_V2_PDK1_9\SERIALAPP\COM_PDD\serialhw.c

I will try and attach the code. I would appreciate it if anyone experiencing this issue could 'peer review' for me and let me know if there are any issues. I need to check how this handles errors in the serial data or overrun conditions.

Mark

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

YixingKong — Tue, 10 Jun 2014 06:19:56 GMT

Deactivated user, could you see if you could decide this DI can be closed?

Thanks,

Yixing

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

YixingKong — Tue, 10 Jun 2014 06:27:23 GMT

karinavalencia, could you see if you are able to find someone to help this one?

Thanks,

Yixing

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

YixingKong — Mon, 16 Jun 2014 07:27:03 GMT

Mark

How is the progress of your issue after Adeneo's response? If it is resolved, we are going to close the discussion in 3 days. If you still need help, please feel free to reply with an update to this discussion.

Thanks,

Yixing

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Thu, 19 Jun 2014 10:17:59 GMT

Please do not close this issue yet as it is not resolved! I thought I had a fix but Adeneo have since commented.

Please note that this appears to also be in your Compact 7 BSP in the common folder so probably affects your Windows CE serial receive for the i.MX28, i.MX51 and i.MX53 platforms.

C:\WINCE700\platform\common\src\soc\COMMON_FSL_V3\SERIALAPP\COM_MDD2

How do I get Freescale to help resolve this issue? Serial transfer is pretty fundamental in an embedded application so really needs to be working in a reference BSP.

Kind regards,

Mark

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

codejingle — Thu, 19 Jun 2014 14:38:47 GMT

If you are having trouble with DMA, have you tried the driver with DMA support forced as disabled (set useDMA to FALSE in the function that normally sets it based off of a registry or register setting)?

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Fri, 20 Jun 2014 11:22:05 GMT

Unfortunately it won't make any difference. The MDD controls the circular buffer. Even if using direct serial port hardware a received length causing a MDD buffer circular wrap will throw away part of the packet that wraps.

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Tue, 24 Jun 2014 14:02:04 GMT

I have been looking further into the SDMA implementation used by the serial port driver. It appears to work as follows (correct me if I am wrong):

The SDMA is set up in serialhw.c in the SL_Open() function initially, then in the SL_RxIntrHandler() function after completion of each DMA command chain.

The function SetupRXDescDESC() initialises a chain of commands in memory that is later passed to DDKApbxStartDma() function to load into the DMA registers. There are SERIAL_MAX_DESC_COUNT_RX (2) commands in the chain and a different RAM buffer used for the received data for each DMA command.

When serial data is received it triggers an SDMA command complete interrupt either through filling the buffer or a timeout condition (i.e. some data received but not enough to complete the SDMA command, after timeout the command is terminated so the data can be processed)

On the first SDMA interrupt the data is collected and the pSerHead->currRxDmaBufId set to 1 to flag to the PDD the second buffer is being used for the next interrupt

On the second SDMA interrupt the command chain is complete (just two commands). After extracting the data the pSerHead->currRxDmaBufId is set to 0 and the whole DMA chain reinitialised. Presumably this means that while extracting data from the second command DMA buffer the DMA chain has no more commands to process and therefore any data received filling the UART hardware buffer will be lost until the DMA chain is reinitialised.

I have read the section on SDMA in the reference manual. Is it possible to set the second DMA command in the chain to point back to the first? I.e. after completing receiving data into the second buffer the command chain switches automatically back to receiving into the first buffer?

It looks like I would just need to change SetupRXDescDESC() to make the second command point back to the first so the two commands continually run in a loop without having to re-init the chain on completion.

Can anyone provide and help or advice?

Regards, Mark

Re: i.MX28 Windows CE BSP Serial Port Bug Missing Received Data

markwilliams — Tue, 24 Jun 2014 14:22:37 GMT

Further to the above it looks like the usage of the semaphore counter may need to change. The DMA commands are set up to decrement the semaphore counter for the channel on completion. The DDKApbxStartDma() call sets the DMA counter to the number of commands in the chain.

If I was to implement a continuous loop of commands I presume I would need to clear the 'decrement semaphore' flag bit in the SetupRXDescDESC() function to prevent the DMA going idle on completion of the second DMA DESC so they loop forever. Is this ok to do?

Mark