Kinetis K64 UART0 Baud Issue ?

[Designer11]

Hi All,

I'm facing with a really bizarre issue related to UART0 on the K64 microcontroller, and i don't know whether the issue is related to baud rate being shifted after letting UART0 idle (no Tx/Rx command). 

The issue only happened after letting UART0 idle for a minute or 2, but doesn't happen on power up or after a reset.  It will send the correct commands after the initial junk command is sent to the target receiver. 

For instance, if i tell  UART0 to send the following command string 81 01 04 07 25 FF to a target system after letting UART0 idle (without sending any command) for a minute or two, it will send out this string of command 60 40 D0 50 D2 to the target system instead.  After the junk command is sent,  it will send the correct command if i tell it to send the same command. 

I've looked at memory location where the data is held, and the data content is valid.

I'm using processor expert to generate the UART0 Tx code

Setting: polling 8N1

baud: 9600

Thank you very much in advance.

Vu

[Designer11]

Hi Mark,

Thank you for your suggestion on using a logic analyzer, I found out what caused the issue. The serial chip i'm using has an auto shutdown feature, after 30 seconds of inactivity the serial chip will go into shutdown mode. It will wait until a valid tx signal is received, then it will turn on. I found out about the issue by using a logic analyzer.

Thanks,

Vu  

[Designer11]

So, i just tested a baremetal metal code for transmit data via UART0 without using Project Expert generated code and that confirm my fear as mentioned in the above thread.

Does anyone have any suggestions ? 

[mjbcswitzerland]

Hi

When you write that it confirmed your fear, do you mean that you worried it would work with bare metal code (ie. problem with PE generated code) or that it also wouldn't (ie. a general problem)? Does it now work or not?

I have used the K64 in dozens of product developments on all UARTs in DMA and interrupt driven modes and in ombination with various low power modes and never experienced any transmission difficulties:
Therefore
a) - measure the baud rate with an oscilloscope or logic analyser to see whether it is wrong after the idle time and then this can be excluded or not
b) - set a break point on the TXD write of the first byte after a pause to see what value is actually being written in order to distinguish between a code problem or a peripheral problem.

Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html
Kinetis K64:
- http://www.utasker.com/kinetis/FRDM-K64F.html
- http://www.utasker.com/kinetis/TWR-K64F120M.html
- http://www.utasker.com/kinetis/TEENSY_3.5.html
- http://www.utasker.com/kinetis/Hexiwear-K64F.html
UART: http://www.utasker.com/docs/uTasker/uTaskerUART.PDF
Low power with UARTs: https://community.nxp.com/message/421247#421247

Free Open Source solution: https://github.com/uTasker/uTasker-Kinetis
Working project in 15 minutes video: https://youtu.be/K8ScSgpgQ6M

Professional Kinetis support, one-on-one training and complete fast-track project solutions: http://www.utasker.com/support.html

[Designer11]

Hi Mark,

Thank you for your reply. The fear is that the  baremetal codes would yield the same result as the generated codes. Which it did.

Im using Realterm and a hardware cable to spy on the serial communication between the two systems.

I haven’t used the logic analyzer to capture the UART data . However, I did checked the memory content and they are not corrupted.

My baremetal code is based on the below link

https://community.nxp.com/docs/DOC-102540 

Thanks,

vu

[mjbcswitzerland]

vu

Is this problem on a reference board or on your own HW?

Regards

Mark

[Designer11]

This is on my own hardware. I haven’t tested on the reference board. My problem is very similar to the problem mentioned in the following thread

https://community.nxp.com/message/976985?commentID=976985#comment-976985