search

grandideastudio / jtagulator

JTAGulator: Assisted discovery of on-chip debug interfaces
https://grandideastudio.com/portfolio/security/jtagulator/
661 stars 91 forks source link

UART Passthrough at 921600 baud rate #64

Open santiac89 opened 1 year ago

santiac89 commented 1 year ago

Hi, I was trying to use the UART passthrough feature at 921600 but received a Value out of bound error and based on the spin code is not supported, max is I think 307200. But I see that when doing the UART pin scanning this baud rate (and higher) are checked anyways.

What I ended up doing is adding the value to the BaudRate list and flashing the jtagulator again, this worked for me but I'm not sure if there is any specific reason why this is not included in the current version.

Thanks in advance.

joegrand commented 1 year ago

Nice find!

In commit fe0b3a7 (March 2018), I had optimized the UART passthrough functionality with higher-speed routines. It's possible that I left the maximum allowable baud rate at 307200 due to the maximum capability of the routines used in the UART_Scan command or because higher baud rates could cause characters to get dropped/missed.

The UART_Scan_TXD automatic baud rate detection functionality was added later in 02f982b (November 2020) which uses a different method of detecting UART (and at baud rates > 1.5M). This is why you can detect faster speeds with that command than the UART passthrough mode allows.

It's good to know that you can get 921600 on the passthrough. Can I ask what target you encountered that uses that speed? Would you mind also doing some captures to ensure no bytes are being dropped? You might need to use an off-the-shelf USB-to-Serial adapter (e.g., FT232R or FT231X) as comparison.

I'll also run some tests on my side to make sure the data transfer is reliable enough to include in the allowable list.

santiac89 commented 1 year ago

I'm targeting an Echo Dot 3rd Gen, it uses UART@115200 at the beggining of the boot process and it quickly changes to 921600.

I'm pretty sure bytes are being dropped anyways, comparing to other logs I see on the internet and also some weird cut strings:

!!wait bsi write done!!
BSI Write Done
rite Done
!!wait bsi read done!!

I even think that entire lines cut sometimes, but it was good enough for me to see some data :)