TMS570LS1224: TMS570LS1224 – UART baud rate ~15x slower (possible PLL / clock configuration issue)

Timis Claudiu

Part Number: TMS570LS1224
Other Parts Discussed in Thread: BQ79616EVM-021, , BQ79616, USB2ANY, HALCOGEN, TMS570LC4357

Hello,
My name is Claudiu Timiș, and I am developing a Battery Management System (BMS) setup using TI development boards: specifically, the BQ79616EVM-021 BMS board and the Hercules LaunchPad TMS570LS microcontroller.
I am working with a Hercules TMS570LS1224 (LAUNCHXL2‑570LS1224), but it is failing to communicate with the BQ79616EVM-021 BMS.
The UART frames generated by the MCU are structurally correct; however, the baud rate, delays, and "ping" signals are approximately 15.5 times slower than they should be.

Mr. Arnold Venter, from the BQ79616 team, analyzed the logic analyzer captures and confirmed that the communication timings on the TMS570 side are significantly off. He suggested that the issue is likely caused by an incorrect configuration of the PLL, oscillator, or external clock on the TMS570LS1224.

I am attaching the CCS project (version 12.4.0, TI ARM Compiler v18.1.2.LTS) as well as logic analyzer screenshots so you can observe the transfer rates. The frames were captured and saved using Saleae Logic 2 software.
I am also including the link to the discussion where Arnold assisted me.

Could you help me resolve this communication and data transfer issue between the TMS570 microcontroller and the BQ79616EVM-021 BMS?
Please note that I also own a USB2ANY interface, which works correctly with the BQAutoEval application. In the attached file, you will find screenshots from USB2ANY and the TMS570, covering both the startup phase and the debugging process.
https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1646251/bq79616evm-021-bq79616evm-021-charging-balancing-and-mcu-interface-questions/6482047?tisearch=e2e-sitesearch&keymatch=%20user%3A699687#

TMS570LS.zip

I would appreciate your assistance.
Thank you in advance.
Have a wonderful day.

Thank you for your help.

Best regards,
Claudiu Timiș

1 month ago

0 Fleenor 1 month ago

TI__Mastermind 39963 points

Hi Claudiu,

Your ~15.5x baud rate slowdown is a strong signature of the SCI's BRS prescaler being calculated for the PLL-target VCLK1 frequency, while the actual running clock is much lower — not a UART protocol/framing issue. This is a documented failure pattern on TMS570, and the math confirms it.

How the SCI baud rate is generated

The SCI baud clock is derived directly from VCLK1 divided by the 24-bit BRS prescaler (P):

Baud = VCLK1 / (16 × (P + 1)) (for P ≠ 0) 1

Since the prescaler value is fixed once compiled, any drop in the actual VCLK1 frequency shows up as a proportional drop in baud rate — with everything else (frame structure, bit widths) staying correct. That matches your report of structurally-correct-but-slow frames exactly.

A confirmed case with the same signature

On a separate TMS570LS1224 E2E thread, a user configured GCLK at 220 MHz / VCLK1 at 110 MHz in HALCoGen. When the GCLK source dropped to 10 MHz at runtime (same prescaler, unchanged), VCLK1 fell to 5 MHz and the SCI baud rate collapsed from 9600 to 438 — a ~22x drop 2. Your ~15.5x ratio is consistent with this same class of fault: the CPU/peripheral clock domain feeding SCI is running at something other than what your BRS calculation assumes.

Two documented erratum mechanisms that can silently cause this

Erratum	Mechanism	Severity
SSWF021#45 – PLL Fails to Start	On rare power-on events, PLL doesn't lock properly. CSVSTAT may still read as "locked" while the ESM PLL-slip flag is set, or the PLL frequency (measured via DCC) is simply wrong. If your startup code doesn't check both CSVSTAT and the ESM slip flag, the system can run on an unintended (lower) clock indefinitely 3	High
GCM#59 – Oscillator disabled while PLL depends on it	If the oscillator is disabled while only the PLL relies on it, the PLL slips, the RF SLIP flag (GBLSTAT.8) sets, and the clock source autonomously switches away from the PLL back to a fallback — with a multi-millisecond recovery delay and slip flags that must be manually cleared before the PLL can be reused 4	Low

Action items to isolate the fault

Check CSVSTAT and the ESM PLL-slip flag immediately after startup, before SCI init. TI's recommended workaround for SSWF021#45 is to retry the PLL lock sequence with proper flag checking — minimum 5 attempts 3.
Measure the actual VCLK1 frequency — via ECLK pin output or the DCC (Dual Clock Comparator) — rather than trusting the HALCoGen-configured nominal value.
Confirm your HALCoGen GCM oscillator input frequency matches the actual crystal/oscillator on the LAUNCHXL2-570LS1224 board; a mismatch here skews the PLL math even if multiplier/divider fields look correct.
Recompute BRS from the measured VCLK1, once confirmed, using the formula above.
Ensure firmware never disables the oscillator while the PLL is enabled and dependent on it (GCM#59) 4.

Can you share your HALCoGen GCM (clock domain) configuration screenshot along with the CSVSTAT and ESM PLL-slip flag values read right after startup, so we can confirm whether the PLL is actually locking to your intended frequency or falling back to a slower source?

Best Regards,

Zackary Fleenor

0 Timis Claudiu 1 month ago in reply to Fleenor

Prodigy 20 points

Hi Fleenor,

Thank you for your reply; I appreciate it.
I tried checking what you recommended and took a few screenshots, which I have attached.
I hope I understood your explanations correctly and captured the right registers.
Thank you for your help.
I look forward to hearing from you.

Have a wonderful day.

Best regards,

Claudiu Timis

GCM HallCodeGenerator.zip

0 Fleenor 1 month ago in reply to Timis Claudiu

TI__Mastermind 39963 points

Hi Claudiu,

Thank you for sharing your register dumps — this is exactly what we needed to narrow the diagnosis. Here is a full decode and what to do next.

Register Dump Analysis

CSVSTAT = 0x000000FB → Binary: 1111 1011

Per the CSVSTAT bit-field definitions (SPNU515C, §2.5.1.19):

Bit	Clock Source	Status
7	EXTCLKIN2	Valid
6	PLL2	Valid
5	HF LPO	Valid
4	LF LPO	Valid
3	EXTCLKIN1	Valid
1	PLL1 (main PLL)	Valid
0	OSCIN	Valid

PLL1 reports as valid (bit 1 is set). This rules out SSWF021#45 Signature 2 (CSVSTAT not set). However, it does not rule out Signature 3 (CSVSTAT set but PLL not actually running correctly), which can only be confirmed via DCC measurement.

GhvSrc = 0x00000001

Per the clock domain table (SPNS190B, §6.6.2.1), GHVSRC controls the clock source for GCLK/HCLK/VCLK/VCLK2. A value of 0x1 maps to PLL1 as the GCLK/HCLK source — which is correct and expected for normal operation.

So GCLK is sourced from PLL1, and PLL1 reports as valid. The clock chain looks correct on the surface.

PLLCTL1 = 0x20057700 — Decode

Using the PLLCTL1 bit-field table (SPNU515C,2.5.1.26):

Field	Bits	Raw Value	Decoded
ROS (Reset on PLL Slip)	[31]	0	No reset on PLL slip
MASK_SLIP	[30:29]	01	Bypass on PLL slip enabled
PLLDIV (R)	[28:24]	0x00 = 0	R = 0+1 = 1 (no post-divide)
ROF	[23]	0	No reset on oscillator fail
REFCLKDIV (NR)	[21:16]	0x05 = 5	NR = 5+1 = 6
PLLMUL (NF)	[15:0]	0x7700	NF = (0x7700 / 256) + 1 = (119) + 1 = 120

PLL1 output = (OSCIN / NR) × NF / R = (OSCIN / 6) × 120 / 1 = OSCIN × 20

If OSCIN = 8 MHz (typical for the LAUNCHXL2-570LS1224 board): PLL1 = 160 MHz → GCLK = 160 MHz

If OSCIN = 16 MHz: PLL1 = 320 MHz — which would exceed device limits (max GCLK is 160 MHz for this device) and could itself cause erratic behavior.

Critical question: What crystal/oscillator is populated on your board? The LAUNCHXL2-570LS1224 uses an 8 MHz crystal by default, but please verify. If your HALCoGen project has OSCIN set to a different value than the actual hardware oscillator, the PLL math will be entirely wrong and the system will run at the wrong frequency.

ESM Registers — All Clear

Your ESM Stat1, Stat2, Stat3, and Stat4 are all 0x00000000, and ErrPinStat = 0x00000001 (normal idle state). This means:

No PLL slip flag is set in the ESM — this rules out SSWF021#45 Signatures 1 and 2
No oscillator fault has been flagged
GCM#59 has not triggered

What Is Still Missing — Two Critical Registers Not in the Dump

1. GLBSTAT (address 0xFFFFFFEC)

This register contains the RFSLIP (bit 8) and FBSLIP (bit 9) flags, plus OSCFAIL (bit 0). These are the hardware-level PLL slip flags that the TRM references directly for GCM#59 (SPNZ199F,GCM#59). The ESM PLL-slip flag and the GLBSTAT slip flag are separate — GLBSTAT is the raw hardware slip indicator. Please read and report this register.

2. DCC Measurement (or ECLK pin output)

Because your CSVSTAT shows PLL1 as valid and ESM shows no slip, you are now in the territory of SSWF021#45 Signature 3: CSVSTAT set, ESM clear, but PLL is not actually running at the correct frequency (SPNZ218C,SSWF021#45). The only way to confirm or exclude this is to measure the actual PLL output frequency independently, either via the DCC module or by routing PLL1 to the ECLK pin using CLKTEST[3:0] = 0x1.

Most Likely Root Cause Given Current Evidence

Since ESM is clean and CSVSTAT shows PLL1 valid, the two most probable explanations are:

OSCIN frequency mismatch in HALCoGen: Your PLLCTL1 encodes NR=6, NF=120. If HALCoGen was configured assuming OSCIN = X MHz but the actual board crystal is Y MHz, the PLL output will be proportionally wrong. A ~15.5x baud slowdown corresponds to VCLK1 being ~1/15.5 of its intended value. Check HALCoGen's "System" → "Clock" tab and confirm the OSCIN input frequency matches your physical crystal.
SSWF021#45 Signature 3: PLL appears locked (CSVSTAT=1, no ESM flag), but is not actually running at the correct frequency. This can only be ruled out with a DCC-based frequency check before trusting PLL1 as the clock source.

Immediate Next Steps

Read GLBSTAT (0xFFFFFFEC) and share the value — specifically check bit 8 (RFSLIP) and bit 9 (FBSLIP).
Verify the oscillator frequency on your LAUNCHXL2-570LS1224 board (check the crystal marking) and confirm it matches what HALCoGen has as the OSCIN input.
Route PLL1 to the ECLK pin: Set CLKTEST[3:0] = 0x1, then measure the ECLK output with your logic analyzer to get the actual PLL1 frequency. This is the most direct confirmation.
Implement SSWF021#45 workaround: Add a DCC-based PLL frequency check in your startup code before switching GHVSRC to PLL1, with at least 5 retry attempts if the frequency is wrong. The application note "Hercules PLL Advisory SSWF021#45 Workaround" has ready-to-use source code.

Let us know what you find for GLBSTAT and the ECLK measurement — that should close the remaining gap.

Best Regards,

Zackary Fleenor

0 Timis Claudiu 29 days ago in reply to Fleenor

Prodigy 20 points

Hi Zackary,

Thank you for your reply.
Please accept my apologies for the delay.

I have taken the requested screenshots and checked the microprocessor crystal, which is 160 MHz. I have attached photos of the TMS570.
I was unable to complete steps 3 and 4 because there is no ECLK pin on the microcontroller.
Even though the crystal is configured correctly in HalCoGen, it still does not work. I have also attached a few additional images that I thought might be relevant regarding the external clock.
I hope these screenshots and my findings lead to a solution.
Thank you very much for your help.
I am grateful to you.

GLBSTAT&TMS570.zip

Best regards,
Claudiu Timiș

0 Fleenor 29 days ago in reply to Timis Claudiu

TI__Mastermind 39963 points

Hi Claudiu,

Thank you for the additional screenshots — this is very helpful. The new HALCoGen images have given us a significant breakthrough in the diagnosis. Here is a complete analysis of what they reveal.

Critical Finding: Your HALCoGen PLL Configuration Shows OSCIN = 16 MHz

The Clk Source tab screenshot clearly shows:

Crystal Freq: 16.0 MHz
This is the OSCIN input HALCoGen is using for all PLL calculations.

The PLL tab screenshot confirms:

Osc Freq: 16.0 → Clk Div: 6 (NR = 6+1 = ... wait — looking more carefully at the PLL tab, Clk Div = 6 maps to NR = 6, giving INTCLK = 16/6 ≈ 2.667 MHz) → Multiplier: 120 (NF = 120) → Post Output Div: 2 → PLL1 Div: 1

The full PLL1 math with OSCIN = 16 MHz:

PLL1 = (OSCIN / NR) × NF / (OD × R) = (16 / 6) × 120 / (2 × 1) = 160 MHz ✓ (matches the "PLL Freq: 160.00" shown in HALCoGen)

The Clock Tree screenshot confirms:

Oscillator = 16.0 → PLL1 = 160.00 → GCLK = 160 MHz, VCLK1 = 80 MHz
SCI is clocked from VCLK1 = 80 MHz per the clock tree

So HALCoGen's math is internally consistent — the entire configuration assumes OSCIN = 16 MHz on your hardware.

The Diagnosis: Physical Crystal vs. HALCoGen OSCIN Setting

Your previous message indicated the "crystal is 160 MHz" — but as discussed before, 160 MHz is the PLL output, not the crystal. The crystal/oscillator on the LAUNCHXL2-570LS1224 board is the component that feeds OSCIN.

Your HALCoGen is configured for OSCIN = 16 MHz. Now we need to confirm the physical oscillator on your board actually matches this. Please look for a small silver metallic can or ceramic resonator package on the board (typically near the MCU) and report the frequency marked on it.

Here is what a mismatch would look like:

Physical Oscillator	HALCoGen OSCIN	Actual PLL1	Actual VCLK1	Baud Rate Error Factor
16 MHz	16 MHz	160 MHz	80 MHz	None (correct)
~5.16 MHz	16 MHz	~51.6 MHz	~25.8 MHz	~3.1× slow
~1.03 MHz	16 MHz	~10.3 MHz	~5.16 MHz	~15.5× slow ← your symptom

A ~15.5× baud slowdown corresponds to your actual OSCIN being approximately 1/15.5 of 16 MHz ≈ 1.03 MHz — or alternatively, the clock domain is running on the LPO HF (10 MHz) fallback, which at your VCLK1 divider of /2 would give 5 MHz vs. the expected 80 MHz — about a 16× slowdown. This is extremely consistent with your symptom. ¹

Your CCS register dump screenshot shows:

GlbStat = 0x00000001

Per the TRM (SPNU515C §2.5.1.51), GLBSTAT bit 0 is OSCFAIL:

Bit	Field	Your Value	Meaning
9	FBSLIP	0	No PLL over-cycle slip
8	RFSLIP	0	No PLL under-cycle slip
0	OSCFAIL	1	Oscillator failure has been detected

OSCFAIL = 1 is the root cause. This flag means the clock monitor detected that OSCIN was out of the valid frequency window (fHFLPO/4 < fOSCIN < fHFLPO×4), flagged an oscillator failure, and switched all OSCIN-sourced clock domains to the HFLPO (limp-mode clock, ~10 MHz). ² Your PLL lost its reference, VCLK1 collapsed, and SCI inherited the drastically lower clock — which is exactly the ~15.5× baud rate slowdown you are seeing.

This also explains why CSVSTAT still shows PLL1 as "valid" and ESM shows no slip — the system didn't see it as a PLL slip; it saw an oscillator fault, autonomously switched to HFLPO, and set only the GLBSTAT.OSCFAIL bit.

Most Likely Root Cause

Your physical crystal/oscillator frequency does not fall within the clock monitor's valid window relative to the HFLPO (nominally 10 MHz). The valid OSCIN range is:

fHFLPO/4 < fOSCIN < fHFLPO×4 → 2.5 MHz < fOSCIN < 40 MHz

If your board actually has a 16 MHz oscillator, this should be within range. However, there are two remaining possibilities:

The physical oscillator is not 16 MHz — and falls outside the valid window. Please physically verify the marking on the oscillator component.
The oscillator is failing to start — power-on sequencing issues (e.g., insufficient startup capacitance, a marginal crystal) can cause OSCIN to fail the clock monitor check at startup even if the oscillator is technically the correct frequency.

Immediate Actions

Confirm GLBSTAT = 0x00000001 is present at runtime (not just at a breakpoint prior to system init) — your screenshot appears to be captured very early at the main() entry point, which is good.
Physically inspect the oscillator component on the LAUNCHXL2-570LS1224 board and report the exact frequency marking.
Add OSCFAIL detection to your startup code: Before switching GHVSRC to PLL1, check systemREG1->GLBSTAT & 0x1. If set, the system is already in limp mode — do not switch to PLL1 until the fault is cleared and the oscillator is confirmed stable.
Implement the SSWF021#45 workaround from SPNA233B — the _errata_SSWF021_45_both_plls() function also runs a DCC-based frequency check internally, which will catch this class of fault. ³ For a 16 MHz crystal, the maximum execution time for 5 tries is ~930 µs.
Check the ECLK HALCoGen screenshot you provided — it shows VCLK1 = 80 MHz feeding ECLK with a divider of 8, giving ECPCLK = 10 MHz. If this is enabled and you can probe the ECLK pin on your board, this would directly confirm whether VCLK1 is running at its intended 80 MHz or has fallen to a much lower value.

Summary

Register	Value	Interpretation
CSVSTAT	0xFB	PLL1 reports as valid
GhvSrc	0x01	GCLK sourced from PLL1
GLBSTAT	0x00000001	OSCFAIL = 1 — oscillator failure detected, system in limp mode
ESM Stat	0x00	No ESM flags

The GLBSTAT OSCFAIL flag is the smoking gun. Please confirm the physical oscillator frequency and add the OSCFAIL check to your startup code — this should resolve the baud rate issue entirely once the oscillator fault is addressed.

Looking forward to your findings.

Best Regards,

Zackary Fleenor

0 Timis Claudiu 27 days ago in reply to Fleenor

Prodigy 20 points

Salut Fleenor

Mulțumesc pentru răspunsurile concrete.

În ceea ce privește GLBSTAT, am făcut două capturi de ecran - o în timp ce MCU rulează și o în timp ce este suspendat - iar rezultatul a fost 0x00000001 în ambele cazuri. Am atașat cele două capturi de ecran.
Cât despre componenta oscilatorului cu cristal, aceasta este marcată cu „A160H87” și funcționează la 16 MHz; am atașat o imagine care arată numărul piesei.
Am încercat să adaug cod pentru a detecta OSCFAIL și a implementa soluția SSWF021#45 din SPNA233B în codul de pornire, dar am întâmpinat sau eroare de compilare.

Capturile de ecran și imaginile sunt incluse în fișierul zip.
Vă mulțumesc foarte mult pentru ajutor.

Oscillator component.zip

0 Fleenor 27 days ago in reply to Timis Claudiu

TI__Mastermind 39963 points

Hi Timis,

Unfortunately, I don't speak Romanian, but I was able to use TI's internal translation tool to work with it

1. Physical crystal matches HALCoGen (16 MHz = 16 MHz) Since your "A160H87" oscillator is confirmed to be 16 MHz and your HALCoGen OSCIN setting is also 16 MHz, the frequency-mismatch theory is now ruled out. 16 MHz is also well inside the clock monitor's valid window (2.5 MHz – 40 MHz), so a simple out-of-range condition doesn't explain why OSCFAIL is still latching.

2. GLBSTAT = 0x00000001 (OSCFAIL) persists in both running and suspended states This is the important new signal. A separate TI E2E thread confirms that GLBSTAT.OSCFAIL and ESM Group 1 / Channel 11 report the exact same oscillator-fault event — so there's no ambiguity in what this bit means 1. A related thread on the same clock-monitor behavior describes a case where OSCFAIL triggered a fallback to the ~10 MHz HF LPO after unstable power delivery to the board — and the issue was fully recoverable once the power/oscillator instability was resolved 2.

Given that:

Your OSCIN frequency setting matches the physical crystal, and
OSCFAIL is latched persistently (not transient) regardless of run/suspend state,

the remaining explanation is that the oscillator is not meeting the clock monitor's amplitude/stability requirements at startup — i.e., it is "running" at approximately the right frequency but failing the clock-monitor's qualification check (weak start-up margin, marginal loading capacitance, or a soldering/PCB issue around the resonator). This is a hardware-level oscillator health issue rather than a configuration math issue at this point.

Next steps

Probe OSCIN directly with an oscilloscope (not just the logic analyzer) to check the actual waveform shape and amplitude at the crystal/oscillator pins. A clipped, low-amplitude, or noisy waveform will fail the clock monitor even if the counted frequency looks like 16 MHz.
Try clearing OSCFAIL manually (write to clear the bit per the TRM procedure) and check whether it re-latches immediately — if it re-asserts right away, the fault is continuous/real-time, confirming a hardware oscillator issue rather than a one-time startup glitch.
Inspect the crystal/resonator solder joints and load capacitors on the LAUNCHXL2-570LS1224 board near the "A160H87" package for any visible defects.
Share the exact build error you hit when adding the SSWF021#45 workaround (SPNA233B) — the error text/log wasn't included in your message, so we can't diagnose that specific compile issue yet. Please paste the full build log or screenshot.

Once OSCFAIL clears and stays clear, VCLK1 should return to its intended 80 MHz and the SCI baud rate/BQ79616 "ping" timing should resolve automatically — no SCI-specific code changes should be needed at that point.

Follow up: Can you share the exact build error text/log from adding the SSWF021#45 workaround code, and an oscilloscope capture of the OSCIN pin waveform if possible?

Best Regards,

Zackary Fleenor

0 Timis Claudiu 12 days ago in reply to Fleenor

Prodigy 20 points

Hi Fleenor,

Sorry for the delay in responding. I’ve been dealing with some technical issues regarding my hardware setup and my PC.

I’ve gone through the troubleshooting steps again and checked the following:

Crystal waveform and amplitude: As shown in the attached images, both crystals connected to the Hercules microcontroller are operating correctly at 16 MHz. I tested both of them to completely rule out any hardware defects.

Hardware integrity: I inspected the solder joints for both crystals and found no issues; I also verified the continuity of the traces to definitively rule out any hardware problems related to the microcontroller.

To reach a solution more quickly, would you be open to a brief screen-sharing session, during which you could take control of the software and code within CCS?

Photo Crystal.zip
Best regards,

Claudiu

0 jagadish gundavarapu 6 days ago in reply to Timis Claudiu

TI__Guru* 80626 points

Hi Claudiu,

First of all, apologies for the delayed response!

I am not completely expert with BQ79616, however i performed your code and captures verification and here is my findings.

As per my understanding the issue is not in the SCI, SCI is properly configured for 1Mhz frequency.

I understood you want to perform same wakeup sequence that USB2ANY is doing,

for example, as highlighted below on start of communication it is sending one low pulse of duration 7us like as shown below:

However, the low pulse duration which is generated with TMS570is 108us and which is 15 times of the USB2ANY right, so thinking this is the problem right.

However, my verification and finding is this:

In your wakeup sequence code, you are converting SCI TX pin into one GPIO and then you are writing logic-0 to it and then you are calling some delay followed by re-initializing SCI.

And here delay routine is generating using RTI, so my understanding is that here SCI or its clock is not an issue. Here we are calling wakeup delay as 2.5ms? is it intentional?

I want to know is this code is your custom code or you get from TI? And is this code particularly developed for BQ79616 or for any old BMS? So, if you are talking other BMS code then may be we need to verify these delays and should modify according to the device you are using.

--
Thanks & regards,
Jagadish.

0 Timis Claudiu 2 days ago in reply to jagadish gundavarapu

Prodigy 20 points

Hi Jagadish,

Thank you for your detailed response.
My goal is to have the microcontroller work with the BQ79616EVM-021 BMS for cell monitoring. Currently, the Hercules microcontroller is not communicating with the BMS; however, I also have a USB2ANY interface, which works correctly for cell monitoring, and I would like to replace this USB2ANY interface with the TMS570 microcontroller.

I attempted to troubleshoot this communication issue by comparing the USB2ANY and the TMS570 with your colleague, Arnold, but without success. Based on our findings, it appears that the UART transfer rate is approximately 15 times slower.

The 2.5ms delay is not intentional. The code is not custom-written by me; it was provided by Arnold—code created by your colleagues specifically for communication between the BQ79616 BMS and the Hercules TMS570. I also asked Arnold to set up the hardware configuration and use the same code he provided to me; the result was positive—the hardware configuration works correctly in his setup, whereas it does not work in mine, despite using the same hardware equipment.

The code is developed for the BQ79616EVM BMS.
I will attach the link to the thread where I communicated with Arnold.

I have also attached the provided code.

https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1646251/bq79616evm-021-bq79616evm-021-charging-balancing-and-mcu-interface-questions/6489399?tisearch=e2e-sitesearch&keymatch=%2520user%253A699687#

bq79616_sample_code.zip

I look forward to your response.
Have a wonderful day.

Best regards,
Claudiu Timis

0 jagadish gundavarapu 2 days ago in reply to Timis Claudiu

TI__Guru* 80626 points

Hi Claudiu,

As i mentioned before i verified UART wise settings and there is no issue with UART baud rate because it is set perfectly for 1Mhz baudrate. I am suspecting the issue lies with delay generation only, but the problem is that the source code delay generation setting doesn't match with waveforms that you shared. For example, as i mentioned there is some 2.5ms low pulse generation at the start of the communication however i didn't find that low pulse in your waveforms. I could only see 108us low pulse at the beggining.

Are your waveforms being from the same code?

Currently i am lack of TMS570LC4357 at my end to give a test on your code, mean while could also check with Arnold again, and mention that the issue is not with SCI and ask him to verify delay settings once?

Meanwhile at my end i will try to do further verifications and testings.

--
Thanks & regards,
Jagadish.

0 Timis Claudiu 19 hours ago in reply to jagadish gundavarapu

Prodigy 20 points

Hi Jagadish,

Thank you for your response.

The waveforms I provided were generated using the same source code that I received from Arnold.
Do you think it would be easier to resolve this issue if I granted you access to my computer via a remote control application of your choice?
I look forward to hearing from you.
Have a great rest of your day.

Best regards,
Claudiu

Arm-based microcontrollers

Arm-based microcontrollers forum

TMS570LS1224: TMS570LS1224 – UART baud rate ~15x slower (possible PLL / clock configuration issue)

How the SCI baud rate is generated

A confirmed case with the same signature

Two documented erratum mechanisms that can silently cause this

Action items to isolate the fault

Register Dump Analysis

CSVSTAT = 0x000000FB → Binary: 1111 1011

GhvSrc = 0x00000001

PLLCTL1 = 0x20057700 — Decode

ESM Registers — All Clear

What Is Still Missing — Two Critical Registers Not in the Dump

1. GLBSTAT (address 0xFFFFFFEC)

2. DCC Measurement (or ECLK pin output)

Most Likely Root Cause Given Current Evidence

Immediate Next Steps

Next steps