Hello friends,
I have a DEVKIT-MPC5748G and am now trying to get an example program for UART working on it.
I am using the example named 'linflexd_uart' available in DEVKIT-MPC5748G-LAB package downloaded from NXP's website.
IDE is S32DS and am using OpenSDA to program and debug.
However, I see junk characters randomly on the serial window.
JFYI, I have an MPC574xG EVB and this code is working perfectly in it.
Debugged the program and verified that the RX line is working perfectly and character written to the Transmit buffer is also correct.
Baud rate and serial settings have to be correct since I don't see junk characters all the time.
Could you please help me in sorting this out?
Thanks
Sandeep
Original Attachment has been moved to: linflexd_uart.zip
已解决! 转到解答。
I had the same problem at first. Then I realized that the Tx need to be pulled up. PC6 is my TX pin.
SIUL2.MSCR[PC6].B.PUS=1;
SIUL2.MSCR[PC6].B.PUE=1;
Hi Sandeep,
Have you fix the problem now?
I had the same problem, when I use Uart to send message through OpenSDA, the beginning of message was junk character. And if I print a long empty message in advance, and then send the message i really want to show. It can works well.
Could you please tell me how to solve this problem? Thanks~
Unfortunately, the question is not answered. Please change 'Assumed Answered' status.
@Martin - Thanks for the response. I tried adding 1ms delay before transmitting each character. Still I am getting the junk characters on serial console. Did you get time to investigate this issue deeper?
Hi,
Please do not deal with post status because even if the post is marked as assumed answered and there is not final solution, we try to resolve the problem to the end.
I contacted my colleague this morning about this issue and we have already met with it. It seems that OpenSDA firmware does not properly handle messages from UART. We are in touch with PE Micro. I will contact you as soon as I have any information for you.
Regards,
Martin
Hi Martin,
Is there any update? Its almost a month since I raised this issue.
There are a couple of other observations as well, in addition to the junk characters.
1. If I continuously transmit a character byte stream, some of the characters are lost occasionally.
2. Serial console will stop showing the messages after a short while. Need to close the terminal and if I reopen the terminal, messages will again show up and stop. I am using 'putty' as terminal.
I tried both polling and interrupt driven methods to see if it has to do with any timing issues. Played around by putting some delays after transmitting each character. But in all cases I am getting all the above mentioned issues. In fact, increasing the delay after sending each character worsened the situation.
Is there anything which we can do in the OpenSDA firmware side? Or do we need to configure something in OpenSDA side? How does OpenSDA recognize the baud at which MPC5748G is communicating to it? Is there an auto baud rate detection or something like that? Currently I am just configuring the LinFlex2 in MPC5748G.
Thanks
Sandeep
Hi Sandeep,
I am really sorry, but I do not have any advice for you. We logged this issue to PEMicro three weeks ago, but we still do not have any answer. I tested it on my side and I know the behavior is incorrect. I got stuck at the same point as you did. We try to get any information, but unfortunately it is not up to us right now.
I am sorry for any inconvenience and I hope it will be resolved soon.
Regards,
Martin
Hi Martin,
A couple of positive things happened yesterday, though I need your help to explain the observation.
I did some investigation on this. Observation was that always the characters sent at the beginning of a message are getting corrupted. Hence suspected like it could be something related to start character detection at the OpenSDA end.
The OpenSDA controller in NXP Devkit is MK20DX128VFM5. I looked in to the reference manual of K20 series, just to see how the UART might have been configured in it. In the RM, under description for UART Control Register 1, there is a WAKE bit whose reset value is 0. If this is not programmed by the OpenSDA controller, then it means that Receiver Wakeup Method Selected is Idle line wakeup. This indicated that the OpenSDA could have been going in to an Idle state and we have to wake it up before sending the messages. Hence tried sending 10 bits of logic 1's as mentioned in RM under Idle Line Type Select bit description. This improved situation much better but still I was getting junk characters. occasionally. Then there was a Receiver Wakeup Control bit and Send Break bits. Reading through the description, I got an intuition to send 0's instead of 1's. Hence I decided to send 0's instead of 1's, before sending stream of characters. This made it work.
I can now easily recreate the situations where junk characters can be displayed and fix them. Sending 16 bit logic 0's before each string (not each character) will show the messages cleanly on serial terminal and if I comment it, it will show up junk characters.
I need your help to verify whether this is a reliable solution and if possible I need a theoretical explanation for this observation. I have attached the project I used.
Now it seems to be reliably transmitting the characters without junk characters.
Then I was left with the other two issues - a) losing characters occasionally and b) Serial terminal hangs after printing a few screens of messages.
For a) I thought it could be because of some Rx FIFO overflows and hence reduced the baud from 57600 to 19200 which did the trick. I am not getting the issue a) and b) after reducing the baud rate to 19200. I cannot authentically explain this as well.
Regards
Sandeep
Does this have to do some thing with the OpenSDA? The difference I see between the Freescale MPC574xG EVB and NXP DEVKIT is that EVB has FTDI (FT2232) as USB to serial converter and NXP Devkit has the OpenSDA.
Hi,
I did some simple investigation and the behavior is strange. Could you please try to add some delay (for example 1ms) before every character transmission and check, if there is any change?
As soon as I have more time, I will investigate this issue deeper.
Regards,
Martin