LAUNCHXL-F28379D: SCI clock slightly out of phase on LAUNCHXL-F29379D

Hello,

Thank you for your question! To confirm, when you say out of phase, do you mean slightly different timings? If so, then a few things can be causing this:

1. It is possible that based on the device clock rate and BRR register setting, the device may not quite match the desired baud rate. Please try using the formula from the following E2E post to determine what the actual baud rate would be for the C2000 device (will need to re-arrange to solve for baud rate):

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/595267?TMS320F28377D-Question-on-Baud-rate-calculation-for-SCI

2. It is also possible that the ESP32 may have a similar configuration setting, and would be worth measuring the bit timing of the device with a scope/logic analyzer.

3. Make sure you are not utilizing mismatching logic levels on the UART line (5V vs 3.3V).

Additionally, in case this is what you are doing, but please make sure that you test without duplex communications. 

Lastly, and most importantly, if you are using a C2000Ware example as your base, please make sure you have set #define_LAUNCHXL_F28379D somewhere in the code to configure the clocks correctly for the LaunchPad (and not the Control Card which may utilize different settings).

I believe that one of these should help solve the issue, but let me know if not! If one of these does help you, please let us know which one, so that others who see this thread will find the solution!

Regards,

Vince

----------------------------------------------------------------------------------------------------------------------------

If I was able to answer your question, please press the green "Verified" button below, thanks!

Hi Vince,

Thanks for getting back to me.
I tried all three options you provided with no luck, but I'm suspecting its due to differential of internal clock from both F28379D and esp32. 

I'll try having F27379D's as clock source for esp32 first, but might have to do the other way from what I'm reading so far.

Will this method give me a better result?
Also, If I end up using esp32 as master clock source, F28379D will be running 32MHz based, will scaling it to 200 MHz becomes a potential issue? 

Regards,
Yang

Hi Yang,

Thanks for the follow up. 

It can definitely be due to differential of internal clock from both the F28379D and ESP32, especially if you are using long exteernal wires to utilizing the clock source.

* Is there any way for you to shorten the wires, or alternately, utilize two independent clock sources on each device? For example, utilize the XTAL on C2000 for just the C2000, and utilize the clock on the ESP32 for just the ESP32. I think this might significantly improve it, especially if your wiring has long distances/coils/insufficient shielding for high clock rates.

* One additional request: can you provide the location where you have placed the #define_LAUNCHXL_F28379D in the code you are using? This affects all the clock configuration, and if not set properly, can cause what you are seeing.

Regards,

Vince

Hi Vince,

Sorry I failed to clarify the problem. 

The behavior was monitored using oscilloscope and the boards are not connected to each other. That is when I find out about drifting between two chips.
What I know is that ESP32 is running 32 MHz Oscillator, and not on the same clock with F28379D (10MHz I believe?).

I used breadboard wire which is less than 8.75 inch for Rx to Tx.  

I tried added the define to the predefine symbols section in the CCS option and to the command line option to the compiler.
None of these fixed the issue, but did give different results. 

Regards,
Yang

Hi Yang,

Thanks for the clarification, that makes sense then. Like you said previously, it's possible then this could be one of the following two issues:

1. The slower clock on the C2000 (you are correct, it is 10MHz if XTAL is used) may end up appearing less accurate when compared to the faster clock of the ESP32. What does not make sense with this to me is that at 9600 baud rate, there should be almost no discernable difference between the chips, since this is within the resolution range of the device. So I don't really think it is a clock discrepancy if you are using XTAL on C2000. Which leads to another possiblity:

2. The internal oscillator on C2000 can have +/-3% accuracy error. If you are using the internal oscillator (INTOSC) and you are NOT using XTAL, then you may notice a difference of that percentage between the UART communication rates as well (since the clock affects the communication rate). Like you said, you can test if this is an issue by using either the ESP32 clock, or just using XTAL on the C2000.

3. The baud rate when set to 9600 on C2000 is actually 9601 due to the granularity of the BRR register (this is assuming SYSCLK=200MHz and LSPCLK=100MHz). If the granularity of the ESP32 baud rate settings gives you exactly 9600, then you could end up with ~0.01% error/drift between the two. If the ESP32 is also not able to achieve exactly 9600, then you could end up with greater mismatch. If you are seeing drift in the 0.01% percentage range, then this could be the cause.

Also, could you clarify what you mean by:

but did give different results

Let me know if any of this helps clarify the potential sources of the issue.

Regards,

Vince

Good Morning Vince, 

Sorry I wasn't able to get back to you yesterday, 

We used the F28379D's XTAL, and we took into account for the granularity of both ESP32 and F28379D, attempted to fine-tune the baud rate on both chips with no success.

I only notice the presaler settings were changed when "Define ..." were used.  

Thank you in advance for the insight

Regards, 

Yang

Hi Yang,

Thanks for letting me know, this shows at least that the granularity is likely not the issue. Can you provide scope shots of the two being out of phase? That will help give a better picture of what is happening.

Regards,

Vince

Hi Vince, 

https://i.imgur.com/BuTM6DN.gif 

Hi Vince, 

Looks like all my text were gone. :/

Yellow line is F28379D, while Blue is ESP32.

The F28379D was set to Baud rate of 9600 with a LSC divider of 2 to match ESP32 (9600 Baud rate also)

Gif link I provided is a lot faster than the real situation but you can see Yellow's frequency is bouncing while the Blue is fairly stable in contrast. 

Please let me know if there is anything else I can provide.

Regards,

Yang

Hi Yang,

This is great, thank you for providing this, this clears it up significantly! 

Both devices are repeatedly sending communications, and the frequency is being observed independently. Because of this, I think the issue could be related to the difference in the actual transmitting method between the two.

On the C2000, if you are using interrupts or writing to the TX buffer, depending on how you are doing the SCITXBUF writes, then you may actually have some (very small) delays between when you request the transmission to when it actually occurs. This is due to the interrupt overhead, TXENA, TXRDY, the emptying of the TX buffer, etc. See the following image for a breakdown of what happens when the a transmission is requested.

Following the diagram, you can see that you should try to avoid the toggling the other signals when sending lots of data. And you should definitely avoid interrupts and the overhead they require much as possible if you are trying to avoid delays.

In most SCI communications, sending individual characters/frames with some delay is perfectly acceptable as you will send characters (frames) to the receiving device, and each frame is interpreted individually. But if you're wanting to use it like a clock (not recommended, not typical), then the repeated toggling of the various status lines may add up to some phase shift as you are seeing.

All this to say -

ACTION STEPS:

To see if this is the issue, write a large char array (with SCI_writeCharArray) with a 1s delay after it. Use the scope in one-shot mode and see if the data is steady frequency during that time. The overhead will now be part of the 1 second now, so this will separate the overhead from the data.

If the result of this one-shot is steady, then the issue was the overhead in the code written. If the frequency is not steady, it could be a hardware issue, and we can debug from there.

Let me know what you see from this!

Regards,

Vince

Hi Vince, 

I tried the method you suggested with no difference, 
I also forgot to mention that the F28379D's signal frequency seems stable when locked on in the oscilloscope, while the other appears to be experiencing the phase shift and instability. The opposite is also true when locking onto the ESP32's signal.

I was able to generate a 10MHz clock from the ESP32, output it on one of its pins, and solder it in to replace the clock on the F28379D to see if using the same clock would solve the problem. However, this did not work either. 

Could there be any other possible issue?

Regard,

Yang

Hi Yang,

This is actually a bit strange as this almost sounds like the device receiving the clock source is actually conflicting with its own clock signal. Can you confirm that the clock source on the receiving side is off when you connect it?

Basically, make sure that only one clock is active at a time by checking this on the scope.

Regards,

Vince