AM3358: UART transmission stumbles/is inconsistent on AM3358 (sometimes)

Hi,

I have assigned your query to our expert. Due to a public holiday in TI India, your response might be delayed.

Apologies for the delay.

Best Regards,

Suren

Hello Michael,

Thanks for reaching out to Texas Instruments E2E Support Forum.

I believe you can start with the Baud Rate for UART which is currently set to 115200 by default in our SDK Examples.

You can try switching between callback and blocking mode, and apart from this one important factor to look at would be is the UART module operating in Interrupt or Polling Mode.

Regards,

Vaibhav

ARM Based Processors | FAQ AM62x & AM62A | FAQ AM64x

OK; that's not really an answer to my question?

Hi,

I am supporting UART in Linux, but never had such issue report that the stop bit is corrupted. I am routing your query to our UART hardware expert for comments.

Hello Michael,

From the hardware side, i see the below note. I assume this behavior is intermittent and depends on some specific firmware condition. 

Now sometimes (may be when some other stuff in the firmware is running, the exact circumstances are no clear) the transmitted signal is more or less damaged, most often it seems the stop-bit is trashed because the last data bit is too long. Sometimes it also seems other bits are too long. So the timing of the whole data transmission seems to be out of sync.

Would you please describe the UART connection to the processor.

Is this UART directly connected to the processor or is there a transceiver in between.

Do you have pulls on the receiver pin and are the UART interfaces externally protected?

Do you see this issue on a specific UART?

Regards,

Sreenivasa

Hello Kallikuppa,

from hardware side there is a ST232CDR connected to the UART1 to do signal conversion to and from RS232 signal levels:

Hello Michael,

Thank you.

Can you add a resistor on the RX input as below and test.

Regards,

Sreenivasa

Hello Michael,

Could you help me understand the power supply you are using and the baud rate.

https://www.st.com/resource/en/datasheet/st232b.pdf

5 V powered multi-channel RS-232 drivers and receivers

Regards,

Sreenivasa

Hello everybody,

OK, the resistor does not make a difference.

The converter is powered with 5V and running with a maximum of 115600 bps.

But I think we're on the wrong path here, I don't think it is a hardware issue because of the following reason:

- the output of the serial port works properly most of the time

- under some SOFTWAE condition, means with exactly the same hardware connected, the problem appears

And: when the problem happens, the output is not damaged, but the bits are really shifted. Beams when the last transmitted bit is longer (so that it overlaps the stop-bit), the whole frame is longer. Means the data itself are still there, but  delayed/stretched somehow. I don't think that external hardware can do that.

I'll try to provide some scope-traces later.

OK, as discussed earlier, this is what the output looks like. The upper trace shows a proper transmission with no errors. The lower trace shows the transmission of exactly the same data but with the problem happening:

The red lines show the boundaries of the single bytes. This is what happens when comparing the upper to the lower trace:

- the first byte is transmitted correctly

- in second byte the stop-bit is about three times too long in lower case

- in third byte the last data bit is about three times too long in lower case

This all results in the wrong byte-length marked by the lower light-blue lines. In both cases the shape of the signal at the output is fine, so I don't think there is a problem with the external hardware.

In same firmware several other interrupts are running. But assumed, one of the interrupt service routines takes too long, this should not influence the length of a single bit in the transmission as this is done in hardware, right?

Hello Michael,

Thank you. 

Please note that the processor IOs are not 5V tolerant.

I am not sure if this is an issue but the processor seems to be operating out of the recommended supply range.

Can you please use a 3.3V capable transceiver and perform some tests.

user6544278 said:

The converter is powered with 5V

Regards,

Sreenivasa

OK, this all is related to the INPUT (aka RX) of the SoC. There is a small buffer in between which converts the signal for the SoC to 3.3V, so there everything is fine.

My problem happens with the OUTPUT (aka TX) of the SoC.  Please refer to my posting above, when the problem occurs, single bits of the transmission are three times longer than they should be. So I'm quite sure this is not a wiring or signal problem as this would not explain why the bits (and following by them the whole data bytes) need a longer TIME.

Hello Michael,

Thank you for the inputs.

I will assign to Bin if he has any thoughts.

Quick questions:

Did you try reducing the speed for testing and did you have similar observations?

is this observed on a specific board or multiple boards. Did you probe the clock?

Regards,

Sreenivasa

Hi Kalikuppa,

the problem happens also on lower transmission speeds and with other boards (tried 5 different BBB meanwhile).

Where can I measure the clock? 

Hello Michael,

Thank you.

user6544278 said:

the problem happens also on lower transmission speeds and with other boards (tried 5 different BBB meanwhile).

Please elaborate. Can you add the speeds where you observe the issue and where you do not observe the issue.

user6544278 said:

Where can I measure the clock? 

I understand you are using the beale bone? 

Regards,

Sreenivasa

In range used range from 9600 to 115200 bps there is no speed where the problem does not happen. Other speeds are not used. Please refer to my explanation above: the problem happens to some (unknown) state/condition of the firmware. So with exactly the same UART parameters it once happens and it once works perfectly.

Yes it is a Beagle Bone.

Hello Michael,

Thank you.

I understand you tries on 5 numbers and seeing issue on all.

I guess this may not be the clock.

Please refer below for the clock information.

Regards,

Sreenivasa

Hello Kallikuppa,

OK, that's the general clock input of the SoC, not a UART-specific one? Which one do you want  to have checked, the 24MHz clock, the 32kHz clock or both?

Michael

Hello Michael,

The 24 MHz.

Regards,

Sreenivasa

It is stable at about 24 Mhz

Hello Michael,

Thank you.

I will reassign to the software expert.

Regards,

Sreenivasa

Hello Michael,

Looks like there are no issues with the hardware. Are you using any software stack from TI in your bare-metal firmware? Please note that TI has stopped supporting bare-metal SW development for AM335x devices. I can point you to some resources if you're using TI software stack such as starterware, Processor SDK, etc.

Regards,

Jianzhong

Hello Jianzhong,

thanks for your feedback. Originally this bases on StarterWare, but - as it is no longer supported - it is an own implementation meanwhile.

I don't expect there is really a issue in the hardware, I think this is some side effect of something else. That's why I asked, WHAT could cause such an effect where the length of single bits during transmission is expanded.

Hi Michael,

I'm afraid that we won't be able to provide much SW help on this. Please refer to this announcement and hopefully you can find some helpful resource from there.

Regards,

Jianzhong

OK, then let me repeat this for the third time: I do NOT want any specific software help! All I'm looking for is some information under which conditions the hardware may show this behaviour! I don't want you debug my application, I don't want you to provide a ready-to-use solution out of some sofzware-snippets, I just want to have the information what could let the HARDWARE behave in that wrong way.

As neither the reference manual of the AM335 nor the silicon errata sheet describes something like that, I don't know of an other place to ask for this problem.

Hello Michael,

user6544278 said:

In range used range from 9600 to 115200 bps there is no speed where the problem does not happen. Other speeds are not used. Please refer to my explanation above: the problem happens to some (unknown) state/condition of the firmware. So with exactly the same UART parameters it once happens and it once works perfectly.

Based on the above, can you please elaborate the failure percentage. If you test 20 times how many times do you see the issue.

Does the issue depend on the length of the transmission or is there a specific pattern you observe or the bit that extends changes with iterations.

Regards,

Sreenivasa

Hello Michael,

Can you please confirm the reception is consistent and you do not see any error.

Please share the UART configuration that you are using.

Regards,

Sreenivasa

Kallikuppa Sreenivasa said:

Based on the above, can you please elaborate the failure percentage. If you test 20 times how many times do you see the issue.

When the problem happens, a damaged bit can be seen on every 2nd to 3rd byte transmitted

Parameters like transfer speed, or stop-bit-length do not have an influence on the problem, it happens with all possible values.

Beside of that the UART is running with no parity, config mode B, divisor latch disabled, no break condition enabled, UART16X operation mode, 48 MHz base clock. Anything else you need to know?

Hello Michael,

user6544278 said:

Based on the above, can you please elaborate the failure percentage. If you test 20 times how many times do you see the issue.

When the problem happens, a damaged bit can be seen on every 2nd to 3rd byte transmitted

Please help me understand the frequency of damaged packet transmission.

Regards,

Sreenivasa

Kallikuppa Sreenivasa said:

Please help me understand the frequency of damaged packet transmission.

OK, what is your question exactly? As described: the problem happens within every 2nd to 3rd byte transmitted. What frequency do you mean?

Hello Michael,

user6544278 said:

When the problem happens, a damaged bit can be seen on every 2nd to 3rd byte transmitted

If you try 10 transmissions, how many transmissions have this problem? 

Does the next 10 transmission show similar pattern?

Regards,

Sreenivasa

Kallikuppa Sreenivasa said:

If you try 10 transmissions, how many transmissions have this problem? 

What is a "transmission" for you? When a transmission consists of at least 3 bytes, then each transmission shows the problem. When the problem happens, it happens always, restarting/retrying a transmission does not solve anything.

Hello Michael,

Thank you.

Transmission means sending a known size of data, once the know size is sent, pause for some time . repeat the same. 

This was the initial input where you mentioned sometimes.

Now sometimes (may be when some other stuff in the firmware is running, the exact circumstances are no clear) the transmitted signal is more or less damaged, most often it seems the stop-bit is trashed because the last data bit is too long. Sometimes it also seems other bits are too long. So the timing of the whole data transmission seems to be out of sync.

Now i understand every time a transmission of packets more then 3 bytes happens, this error is observed every time.

Can you confirm the understanding.

Regards,

Sreenivasa

Yes, I can confirm this being correct.

Hello Michael,

Thank you.

I have not had any other customer report similar issue.

I will have to check internally with the team.

Can you please confirm the beagle bone revision or version you are using.

Regards,

Sreenivasa

Kallikuppa Sreenivasa said:

Can you please confirm the beagle bone revision or version you are using.

It happens with the latest revision of the BeagleBone Black as well as with the BeagleBone Green (also latest revision). We tried a total of five different boards.

Hello Michael,

Thank you.

Let me check with the team internally.

Regards,

Sreenivasa

Any news regarding this issue?

Hello Michael,

Thank you.

I have reached out to the device experts and following-up internally.

I have not yet heard from them.

I will update you with any inputs i receive.

Regards,

Sreenivasa

Some news from my side: Updating the compiler from v18LTS to v20LTS seems to have at least improved the situation. As we can not verify if this really solves the problem completely or if it is only more unlikely to happen, two questions from my side:

- could the compiler version be responsible for this?

- what change in compiler could have fixed this?

Hello Michael,

Thank you for the inputs.

Regarding the complier question - i would suggest starting a new thread quoting the complier version and asking your query.

Regards,

Sreenivasa