[UART] Issues detecting correct baud rate & Passthrough is not working

[Commifreak]

Hi,

I use a new JTAGulator with FW 1.10 and wanted to verify already known UART interface - to test if my JTAGulator works like it should ;)

However, I noticed two "issues": Baud rate detection is not working, I dont know why, maybe its because the target does not output text in a way JTAGulator recognizes? It detects RX and TX correctly but with wrong baud rate (different results every time, but never the correct rate of 115200).

And the passthough with the correct data outputs nothing. However, I can send data to the target and it reacts (I see reaction in changing LED behaviour) but the Propeller Tool console output is blank. CTRL+X ends the passthrough mode.

Can we debug here something?

Once the device is powered on, It prints:

U-Boot 2014.10-rc2 (May 04 2016 - 10:33:03)

CPU:   Freescale i.MX6SOLO rev1.3 at 792 MHz
Reset cause: POR
Board: Vaillant comDialog/2
       Watchdog enabled
I2C:   ready
DRAM:  512 MiB
MMC:   FSL_SDHC: 0
In:    serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Hit any key to stop autoboot:  0

Any ways to improves UART Passthrough and baud detection?

Thanks in advance!

[joegrand]

Hi there- As mentioned in the Wiki, please provide as much information as possible about your environment, including a description of your target hardware, high-resolution photos showing connections/wiring, and screenshots or log files showing JTAGulator output. The UART passthrough and UART scan modes have existed in the JTAGulator for many years without issue, though the implementation of UART Scan TXD has changed as of version 1.10. It's possibly a connection issue or something target-specific.

[joegrand]

I'd also be interested in your results with version 1.9 (in particular using the UART Scan TXD command). That way, we can isolate if it's a recent firmware change that's causing the issue or something else. For reference, here's a video of using UART Scan (based on an old version of firmware). I'm in the process of creating a new video showing the updated features.

[Commifreak]

Okay, I think I found it.

I first downgraded to 1.9 - no change.

The board is working with 3v3 but I had to set UART to 1.4V. The Device has a 4 Pin array of test holes. 3 of those has soldering pads on which a test connector seems to fit.

The 3rd, not pad-having test pad has constant 3,322V, which result in 3.3V for the JTAGulator. But the TXD PIN measures 1.2V. So I tried to set system volate to 1.4 (which is lowest possible) and then it worked!

Even the passthrough is working now.

Upgraded to 1.10: Same. 1.4V working, passthough as well.

The default setting for Ignore non-printable characters? changed to N for 1.10? Why?

Anyway, thanks for all the help 👍

[joegrand]

That's great news! Thanks for the update.

The 3rd, not pad-having test pad has constant 3,322V, which result in 3.3V for the JTAGulator. But the TXD PIN measures 1.2V. So I tried to set system volate to 1.4 (which is lowest possible) and then it worked!

Nice find! I hadn't considered the situation where the target's signal levels would be different than its main system voltage. I'll add that into the FAQ as something to look out for.

I appreciate you trying both versions of firmware, too. I'm glad things are behaving properly.

The JTAGulator used to support down to a 1.2V target I/O voltage (VADJ), but the TXS0108E level translator minimum allowable voltage specification was changed from 1.2V to 1.4V. So, I updated the firmware to conform to their spec, which is why we now have a minimum of 1.4V. The levels should be close enough that it will work reliably with 1.2V targets, so I'm OK with that. If anyone encounters a problem and needs lower VADJ, they could reimplement the code that has the lower limit, though it would then be operating outside of the level translator's recommended range.

The default setting for Ignore non-printable characters? changed to N for 1.10? Why?

I thought it would be better to default to return all results for a given scan and then give the user the option of limiting the results if there are too many. As vendors try to be more stealthy in obfuscating their interfaces, they might choose to use some encoding that results in non-printable characters. If we defaulted to ignoring them (as we did in earlier firmware versions), then basic users might miss critical results/information. So, better to return more than less and let the human make the final decision :)