FRDM-KL43Z virtual serial port not able to transmit binary data?

[thomasedel]

I'm trying to send binary data (bytes with random values) over the virtual com serial port on the FRDM-KL43Z board (from the KL43Z chip to a host PC).  The OpenSDA serial interface seems to do fine with bytes with values correlating to standard ASCII characters, but seems to ignore many byte values that aren't standard characters (they don't get passed on to the host, they just seem to disappear).  Should I expect to be able to transmit binary data over the virtual com connection?

[kerryzhou]

Hi Thomas Edel,

   Actually, the virtual serial port is just using the uart to send the data.

   If you send the binary data, your host PC side also need to change the mode to receive the binary data. If PC side still the ascii receive mode, then it will lost some data.

   So, please check your PC side at first.

   If you still have problem, give me more details, take an example, you send what binary data, and your PC can't receive it. I will check it on my side.

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[thomasedel]

Greetings Kerry:

Thanks for your prompt response.

I'm use RealTerm to show the byte data in hex.  I'm using the following subroutine to send 5 bytes repeatedly to try to resolve the problem (I run this about once/0.7 seconds):

void print_lpuart0_data() {
  char a [5];
  a[0] = 0xFF;
  a[1] = 1;
  a[2] = 2;
  a[3] = 3;
  a[4] = 0xAF;
  for (int i = 0; i < 5; ++i) {
    while (!(LPUART0_STAT & 0x800000)){}  // Wait for TDRE flag to clear
    LPUART0_DATA = a[i];
  }
}

At the RealTerm end it displays:

01 02 03 01 02 03 01 02 03 01 02 03 01 02 03 (etc.)

The point of the RealTerm software is to display this kind of serial data accurately, so I'm thinking the problem is more likely in the OpenSDA interface.  However, I'm no serial communication expert, so I could be missing something basic here.

I checked the COM settings in Device Manager (I'm running Windows 7) and tried to update the driver, and the system seemed to think I have the most current PE Micro driver (OpenSDA - CDC Serial Port; Driver Date 4/24/2009; Driver Version 1.1.2600.1).   I could not find any other settings at my host computer or in RealTerm that seem to be relevant.  

I also updated the FRDM-KL43Z board to the most recent PE Micro driver (Installed Application: PEMicro FRDMKL43Z48M Mass Storage/Debug App; Application Version is: 1.18), and the problem remains.  

Again, thanks for your help.

-Thomas

[mjbcswitzerland]

Thomas

I tested doing this on the FRDM-KL43Z, and using RealTerm (115'200 Baud 8 Bits No parity).
The binary is attached - load with drag and drop onto the OpenSDA disk.
It sends the message that you want to send every 0.7s.

As you an see it doesn't have any problems over OpenSDA so I expect that it is a coding problem.

Regards

Mark

[thomasedel]

Greetings Mark:

Thanks for your help with this.  I ran your code, and it did produce the right results.  So, I put a scope on the KL43Z transmit pin with my code running and indeed found that the missing bytes were NOT being transmitted by the KL43Z to the OpenSDA chip.

So, now I am at a loss as to why the subroutine I included above does not work.  As it is above, only the 1, 2, and 3 get transmitted.  If I change the "2" to "0x6A" I still get the middle three bytes transmitted (0x01, 0x6a, 0x03).  If I change the middle byte ("2") to 0xAF, then only 0x01 and 0x03 get transmitted.  It seems to me that something odd is happening with the LPUART0 that does not appear to be documented, apparently related to the MSB being 1.  Am I missing something obvious here, or is there an anomaly with the MCU?

Any additional help is appreciated.

-Thomas

[thomasedel · Accepted solution]

Ugh!!!   Looks like the problem is with the "char a [5];" in my code.  Changing that to "unsigned char a [5];"  solves the problem.  Not sure why that should matter, but it obviously does.

Thanks for helping me find my coding error.

-Thomas

[mjbcswitzerland]

Thomas

char a = 0xff; // assume compiler set to default char to signed char (often the case)
LPUART0_DATA = a;

gives (probably)
LPUART0_DAT = 0xffffffff;

unsigned char a = 0xff;
LPUART0_DATA = a;

gives
LPUART0_DAT = 0x000000ff;

Regards

Mark

[thomasedel]

Greetings Mark:

Thanks for your further clarification.  One step further, by writing all those extra 1's to LPUARTx_DATA, bit 13 (FRETSC, Frame Error / Transmit Special Character) gets set, which prevents the data from being sent.  So, the LPUART was just doing what the data sheet indicates it should.

[mjbcswitzerland]

Thomas

Looks like it.
As I noted previously:
>> so I expect that it is a coding problem.

Therefore it was in fact a programming "bug". One needs to be specific as to how the compiler should interpret the code. Generally avoid "char" since it is not specific. I would also have expected a compiler warning to have been generated when you built the original code, therefore never disable compiler warnings since they are already telling you that there may be an issue. Also don't ignore compiler warnings that are displayed because they are shown for a reason - try to change code or cast (after understanding why the warning was generated) so that you never has (inexplicable) warnings in a project.

I don't want to sound snooty because I have of course also be caught out by chars.

Eg.

void myRoutine(char thisValue)

    switch (thisValue) {

    case 0:
        fnDebugMsg("We received a 0\r\n");

        break;

    case 1:
        fnDebugMsg("We received a 1\r\n");

        break;

    case 128:
        fnDebugMsg("We NEVER receive this ;-(    \r\n");

        break;

    }

}

but the last time (like this case) was probably 15 years ago now since one tries to learn from mistakes so that they are not repeated ;-)

Regards

Mark

[mjbcswitzerland]

Hi Thomas

I know of no problems with the LPUART, however I never used it in polling tx mode as you do. The binary I posted is using DMA based transmission and the result is the same with interrupt driven.

You can get complete and proven KL43 code (I took 2 minutes to do your test) if you need solutions to this and all potential KL43 issues in the future from the uTasker project, including KL43 simulation. It is open source or supported but has everything you will need if doing real product design.

If your interest is in some peripheral learning rather than project development I would study the status register flags in more detail. Check what happens when you step the code (rather than running it through the loop) to distinguish between configuration and dynamic usage errors.

Regards

Mark