• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 183 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4AEN-Q1: Is UART0 (F19/F20) the only uart port needed for bootloader debug on new board to be designed? -- what about R5 tispl.bin uart output?

kenji konaka
Prodigy 90 points
Part Number: TDA4AEN-Q1
Other Parts Discussed in Thread: J722SXH01EVM, BEAGLEY-AI

Tool/software:

hi,

on the evaluation board J722SXH01EVM, I see the below UART ports of J722S are connected to FTDI FT4232HL (beside RTSN/CTSN for each):

A) F19/F20 (UART0_TXD/RXD)
B) C8/B3 (WKUP_UART0_TXD/RXD)
C) B4/B8 (MCU_UART0_TXD/RXD)
D) H27/J27 (SOC_UART5_TXD/RXD)

Could you suggest which are needed for designing a new board and do software development on it.
(UART to USB bridge like the FTDI chip won't be present on the board to be designed, and we might want to debug R5 tispl.bin-uboot as well).

The usecases inlude both "boot from UART and flash firmware" and "MCU R5F application runtime debug UART prints".

1. A) + B)
2. A) + B) + C)
3. A) only (re-route output to this by firmware change)
4. all of A) B) C) D) (I don't think D is quite needed though)

Less number of pins preferred if possible.

If we went for option 3. would it complicate development of boot code (R5 side uboot) or MCU R5F application uart debug?

please suggest.

BeagleY-AI's layout (uart) puts F19/F20 to one of JST 3pin header, and one linux console gets assigned to its USB-C port,
Other (application use) UARTs going to the 40-pin expansion header, as it seems. Was R5 tispl.bin console printout routed to F19/F20 on BeagleY-AI?

Thanks in advance!

pages that I'm looking at:

* 3.1.1.9.1. Booting U-Boot from the console UART

* J722S MCU+ SDK - Booting Tools

* J722S MCU+ SDK: Flashing Tools

  • 0
    Prodigy 90 points

    noted also this: j722s/EVM_SETUP_PAGE.html#CCS_UART_TERMINAL

    =>

    • We use the 3rd USB serial port, as seen in the device manager, for below in the SDK
      • Flashing application via UART
      • Booting application via UART
      • Uboot and Linux terminal
    • We use the 3rd USB serial port, as seen in the device manager, as terminal output for examples which run from DM R5F (WKUP R5F)
    • We use the 4th USB serial port, as seen in the device manager, as terminal output for examples which run from MCU R5F


    (ie., is MCU R5F on 4th USB software reconfigurable to go to 3rd USB instead?)

  • 0
    Prodigy 90 points

    SPRSP96A datasheet: (comment in device tree k3-j722s-evm.dts mentions other balls but address register values do match the below)


    additionally:

    $ grep -n UART0_.XD mcu_plus_sdk_j722s_11_00_00_12/source/drivers/pinmux/j722s/pinmux.h
138:    PIN_UART0_TXD            = 0x01CC,
139:    PIN_UART0_RXD            = 0x01C8,
302:    PIN_MCU_UART0_RXD                = 0x0014,
303:    PIN_MCU_UART0_TXD                = 0x0018,
308:    PIN_WKUP_UART0_RXD               = 0x0024,
309:    PIN_WKUP_UART0_TXD               = 0x0028,
$

  • +1 in reply to kenji konaka
    TI__Mastermind 20860 points

    Hi,

    Using the image below from the J722S EVM, by default UART0 is used for flashing and booting via UART. MCU_UART is used for logs from MCU R5F core and WKUP_UART is used for logs from WKUP_UART.

    kenji konaka said:
    The usecases inlude both "boot from UART and flash firmware" and "MCU R5F application runtime debug UART prints".
    kenji konaka said:
    If we went for option 3. would it complicate development of boot code (R5 side uboot) or MCU R5F application uart debug?

    All of the UARTs are configurable, however, I would say it is easier to use another UART for MCU R5F application debug rather than using another UART for developing R5 boot. You are also able to adjust which UART is used for UART flashing but it is slightly more complicated than changing a UART for simply debugging. 

    Thanks,

    Neehar

  • 0 in reply to Neehar Sawant
    Prodigy 90 points

    Thank you so much   for clarification.

    That makes sense. 

    Let us retain two ports and go with the arrangement.