Hello world example on FRDM-KL46Z prints strange characters

[carlosmendoza]

Hello all,

The hello world example source code is printing strange characters on the terminal. I get the "KL46 Hello World" message on the terminal followed by a continuous stream of "ÿ" (a letter "y" with an umlaut - the two dots on top). I can only get the stream of "ÿ" characters to stop by stopping the debugging session within CodeWarrior.

The first time I imported the project I got it to work correctly. I configured the terminal (I'm using PuTTY) according to the accompanying "FRDM-KL46Z_CW_rev1" PDF and I got the hello world message and I could see that any character I typed was echoed to the terminal followed by a character return/new line feed.

Today I opened up the project again and I get the described error. Strangely, I have made no changes to the code, or project settings (at least not that I was aware of). What's even stranger is that I have deleted all the examples and then re-installed them and I still get the same error. I re-installed the examples by running the KL46_SC.exe file that one can download from the freescale.com/frdm-kl46z website. One would think that by re-installing the files one would eliminate the possibility of having changed the code or settings on the previous install.

For accuracy's sake:

-I'm using CW 10.5 Special Edition.

-My PuTTY v0.62 serial terminal session is configured to 115200 baud, 8 data bits, 1 stop bit, no parity bits and no flow control. It is running on COM16 since that's what Windows 7's Device Manager shows for the OpenSDA CDC serial port. This is all according to the "FRDM-KL46Z Sample Code Guide for CodeWarrior Rev.1" PDF.

Like I said, I saw the program run perfectly fine yesterday.

I haven't tried re-installing CodeWarrior because that seems overkill just to get an example running again. But I'll do it if I have to. I'm not aware of making any changes to CodeWarrior's settings except that I made the font for the code bigger since the default size is too small for me. Anyway I restored the font settings by clicking on "Restore Defaults" on the Preferences > General > Appearance > Colors and Fonts options.

The only thing I can think of is that maybe some Windows app is printing the "ÿ" character and perhaps the CodeWarrior project etc are all fine. I have already restarted my computer and even plugged in the FRDM-KL46Z board onto a different port (it showed up as COM17) and the problem is still the same. I know that there's no keystroke stuck on my keyboard because otherwise I wouldn't be able to type this post without getting the "ÿ" character to overload the screen. I am running the OpenSDA debug app like it was mentioned in the PDF guide.

Any suggestions would be appreciated. I will post an answer if I find the solution myself so everybody can benefit.

Thanks,

Carlos

[nasreenshaikh]

Hi Carlos,

           Try using the hyperterminal or the Terminal utitlity from PE kinetis.  Some time back i ran into the same problem. But changing to hyperterminal got my hello world working fine. I never did find out what was wrong. Might be some issue with Putty.

[carlosmendoza]

Hello Nasreen,

Thank you for your suggestion. I tried using RealTerm v2.0.0.70 (another terminal app) and I still have the same problem. I get an endless stream of "ÿ" characters. I downloaded the P&E Micro Embedded Multilink Toolkit but it gives me an error when I try to install it. So I haven't been able to try P&E Micro's terminal app. (I have already reported this installation error to P&E Micro).

Getting the same problem using two different terminal apps leads me to believe the problem is either with the board, the project settings or CodeWarrior/Eclipse. As I said before, I deleted the example project's files and re-installed them again and I still have the problem. I was able to get the code to work the first time I opened the project. Maybe some setting in CW/Eclipse is messed up? The attached images are proof that I got the code to run once and they show the current problem. Realterm shows a character that looks like an "F". When I copy and paste somewhere else it comes out as a "ÿ".

[carlosmendoza]

Hello everybody,

Today I tried the following things:

• Reinstalled both CodeWarrior and the examples in case I messed up a setting that's preventing the hello world COM port example from working.
  • It didn't work.
• I changed the CPU component to "MKL46Z256VLL4 in LQFP 100-pin package" since that's the actual processor on the FRDM-KL46Z. For some reason the project comes set to: "MKL46Z256VMC4 in MAPBGA in 121-pin package".
  • This didn't make a difference. Probably because most of the MKL46Z variations are mostly pin compatible.

I realized that about 99% of the project code was generated with Processor Expert. The meat and potatoes of the code (the user generated code) is composed of:

• A "printf" statement printing "KL46 Hello World".
• A condition that checks if CodeWarrior is being used (if true then it configures the printf function so we don't need a CR character to output messages to the console).
• A for loop that waits for user input (one character at a time).
• A statement that prints out the last character entered by the user.

So I tried:

• Adding a second printf statement below the Hello World message.
  • That worked but I still had the endless stream of "ÿ" characters.
• Then I tried commenting out the for loop that receives and echoes user input to the terminal.
  • That also worked and I no longer experienced the endless stream of characters.

Therefore either:

• a) My terminal apps (PuTTY and Realterm) are configured the wrong way.
  • This could be, but I doubt it since I've seen the code work once using PuTTY and the Freescale guide only asks for 8 data bits, 1 stop bit, no parity, no flow control and 115200 baud. That's simple and I've triple checked the configuration on both terminal apps.
• b) There's a problem with the Freescale or ARM GNU libraries regarding either collecting user input or echoing it back to the terminal.
  • I tried executing the code from the for loop only once. This consists of the statements:

    • InpData[0] = getchar();

      printf("%c",InpData[0]);
  • The result was that the "ÿ" character was printed once to the terminal.
    • I tried using my own character variable "TestChar" instead of an array of character type.
      • I still got the "ÿ" character printed once.

Switching my terminal to binary instead of ASCII output reveals that the "ÿ" character is hex value 0xFF. So this could also mean that the KL46's UART thinks that it is receiving a 0xFF character when in reality the Rx line has stayed at logic high. This could explain why with the for loop I get an endless stream of 0xFF characters. The UART interface is thinking that a constant logic high on Rx means an infinite stream of 0xFF characters.

But why?

Any suggestions would be appreciated. Also if any of you have a basic working UART Hello World example for the FRDM-KL46 I would be happy to take a look at it.

Thanks,

Carlos

[nasreenshaikh]

Hi Carlos,

           There are two thing still left to try out.

          First lower your baudrate to 9600 in code  and check once again.

          Second check your hardware. Particularly the RX line to your controller . It should be logic low for no data.

[carlosmendoza]

Hello Nasreen,

Today I tried your other suggestion. I checked the UART0's Tx and Rx lines with an oscilloscope and they are held at logic high unless a character is transmitted. This is the expected behavior. The problem is either:

a) In the C library's "getchar()" function.

b) Within the KL46Z's UART0 Rx electronics. I tried all available UART0 Rx and Tx pins on the FRDM-KL46 board and they all showed the same problem.

c) Some configuration problem that I haven't learned about yet.

It seems like the KL46Z's UART0 seems to not be checking for the start bit in the transmission protocol. So it's just interpreting Rx's stable logic high as a 0xFF character (all "ones"). But the strange thing is that if I press any key on my keyboard the Realterm terminal (or PuTTY) will send the character, detect activity on the Rx line and the KL46 will echo back that character. I can also see the character on the oscilloscope. So if a character is physically produced on Rx then the KL46 detects it. That should tell us that the KL46 is able to detect the start bit of all the characters that are in fact electrically produced on the Rx line.

So still the question is why does the KL46 "detect" fake 0xFF characters on UART0?

I also tried hooking up an FTDI232R serial USB adapter to the FRDM-KL46Z's other UART0 port located on pins PTA14 and PTA15. The default UART0 pins are hardwired to the OpenSDA USB interface so I'm forced to use a serial USB adapter to talk to the KL46's other UART ports. Using Realterm I opened up COM12 (for the FTDI chip) and saw the same problem. The FTDI chip also has LEDs that light up when the Rx and Tx lines are in use. But the KL46's UART0 still "detected" the 0xFF characters even though the FTDI chip's Tx LED did not indicate any outgoing characters and even though of course the oscilloscope was not detecting any outgoing characters either.

Tomorrow I'll try to check UART2's behavior. Unfortunately UART1 is unavailable on the FRDM-KL46Z board. So we'll see if the problem is in general with the UART0 port's Rx line. At least today I learned that the problem is before the multiplexer that feeds the UART0's Rx line to the different pins on the FRDM-KL46Z board. If UART2 has the same problem then definitely the problem is caused by some configuration within Processor Expert or something in the "getchar()" implementation for the KL46Z MCU.

Thanks again Nasreen for your help!

Carlos

[carlosmendoza]

Hello everybody,

Today I tried UART1 and UART2 and they also present the same problem. The KL46 "detects" 0xFF characters when in fact the Rx line is at logic high. However, any character I send to the KL46Z is detected and properly echoed back to the terminal.

Reading through the forums, I found a post by Erich Styger which recommends to avoid statements such as printf() because their behavior depends on the library buffer and how each vendor/compiler implements them. Is this also the case for getchar() ?

Are there more reliable uart send and receive methods as opposed to printf and getchar? Where can I read about them or find examples of their usage?

Erich's post included mentions of AS1_RecvChar and AS1_SendChar. Are these the way to go? Like maybe encapsulating them within other function calls?

Thanks again everybody and have a good weekend!

Carlos

[carlosmendoza]

Hello everybody,

Today I got the UART communications to work based on Erich Styger's tutorial on the following link:

Tutorial: printf() and “Hello World!” with the Freedom KL25Z Board | MCU on Eclipse

The tutorial is intended for the FRDM-KL25Z board but it works just fine with the FRDM-KL46Z board if one edits the CPU settings and the Serial_LDD pins to use the corresponding pins on the KL46Z board. On the tutorial, Erich implements his own reception and transmission routines instead of relying on printf() and getchar().

I will not mark this question as answered since the original post is about getting the Freescale-provided example code to run. I was never able to get the example to run no matter how I tweaked it. I don't have enough experience to solve it on my own. But I believe that Freescale should:

a) Edit the PDF instructions provided with the sample code so they match the contents of the example. For example, the instructions say that the board's RGB LED will change colors every time a character is received. This is not possible since the FRDM-KL46Z board does not contain an RGB LED. Also the example code does not include any lines to turn the red and green user LEDs on or off.

b) Make sure that the example code runs out-of-the box. The precompiled apps don't run either on the board and this has been a known problem for a while (although it is not widely known). I'm sure many people also thought that there was something wrong with their board or that they had bricked it. I did.

*I am very thankful for the fact that some form of example code is provided.

*I am thankful for people like Erich Styger writing tutorials.

*I understand that the Freescale folks are busy trying to answer all of our questions and I appreciate their efforts.

*I will continue to recommend the KL46Z MCU to my clients because it is a great product.

I am only suggesting these courses of action because they will help increase the number of consumers of KL46Z chips. The easier it is to transition to Freescale's products (silicon and IDEs) the more people will adopt them and recommend them to their developer friends. But a lot more tutorials are needed so people from different embedded backgrounds can adopt Freescale's products. People in general are more drawn to easy-of-use than the quantity of features. The quantity of features, dev boards and code libraries increases almost by itself when the core product is easy to adopt (think Arduino).

[marks]

If you are reading this far down you must have the same issue of getting the y with the two dots. The cause is that GETCHAR is defined as DbgConsole_Getchar and every time it runs it will return  a -1 or 0xff which is the y with two dots. I'm not sure if this is the correct fix but it worked for me. I changed this:

#define SDK_DEBUGCONSOLE 1U 

to this:

#define SDK_DEBUGCONSOLE 0U 

Which caused GETCHAR to be defined as getchar. And it worked! Hope this helps!

Regards,

Mark

[carlosmendoza]

Hi Nasreen,

Thanks again for your suggestions. I changed the baud rate to 9600 and I still experienced the same problem. However, I noticed that the FRDM-KL46Z board is actually able to echo back characters that I type on the keyboard in between the unwanted 0xFF character stream. For example, if I hold down the "x" key I can see it on the terminal screen. If the FRDM-KL46Z detects my keyboard input then the 0xFF character is not echoed back.

Next I will try your other suggestion of using an oscilloscope to check UART0's Rx pin. According to the FRDM-KL46Z's schematic I should be able to tap into Rx through the PTA1 pin. I'm used to UART having active low Tx and Rx pins. I would have thought that would be the same with the FRDM-KL46Z's UART. I've never seen terminal settings for configuring the polarity of the Tx/Rx lines.

What do you think I should do if I find that this pin is permanently at logic high? Would you then say that my FRDM-KL46Z's UART0 interface is damaged?

I placed an order for some extra FRDM-KL46Z boards and a P&E Micro USB Multilink FX probe. It would be good for me to check if the Hello World example works fine on new boards. Maybe with the Multilink FX I'll be able to dig deeper into the signals. I'm used to using JTAG debugging with Xilinx's ChipScope and FPGAs hopefully debugging ARM with a probe is not so different.

Thanks again and I hope others are also benefiting from these troubleshooting steps that have been posted in this thread.

Carlos