0006126: Check for Improvment

ID	Project	Category	View Status	Date Submitted	Last Update

0006126	PicoCoreMX93_HW	MISC	public	2024-02-21 17:36	2024-04-18 07:40

Reporter	Weber	Assigned To
Priority	normal	Severity	feature	Reproducibility	N/A
Status	resolved	Resolution	fixed
Product Version	1.00
Target Version	1.XX	Fixed in Version	1.10

Summary	0006126: Check for Improvment
Description	Hallo Herr Weber, so wie ich das verstanden habe, haben Sie die PicoCoreMX93 entworfen. Bei der Implementierung haben sich nun Probleme mit dem PCA9634-LED-Treiber herausgestellt, z.B. weil es dafür keinen Treiber im U-Boot gibt und wir deswegen die Werte direkt über I2C konfigurieren müssen. In diesem Zuge habe ich mir mal den ganzen Pinmux angeschaut, und ich sehe hier noch ein paar Möglichkeiten zur Optimierung, die meines Erachtens gar nicht so aufwendig sind. Ich habe Ihnen mal unten die dafür notwendigen Änderungen zusammengestellt. Zudem gibt es in ... S:\Doku\F&S-Board-Standards\PicoCore-F+S-Implementations+PinMUX_V0.4.ods ... am Ende eine Tabelle, auf der der neue Vorschlag zu sehen ist. Die zu ändernden Pins sind mit roter Schrift markiert. Viele Grüße, H. Keller ---------------- Pinmux PicoCoreMX93 =================== Grundidee ========= Der i.MX93 unterstützt einen Low-Power-Mode, bei dem Cortex-A abgeschaltet wird und nur Cortex-M läuft. Dann dürfen aber auch nur noch Devices an sein, die in der Domäne AON (Always On) sind. Das sind typischerweise die ersten ein bis zwei Devices einer Art, also: UART1+2, I2C1+2, I3C1, SPI1+2, CAN1, SAI1, MQS1, TPM1+2 (PWM) Der Rest der Devices ist in der Domäne Wakeup, die in diesem Modus dann inaktiv sind. Damit dieses Konzept auch halbwegs nutzbar wird, sollten wir schauen, dass wir zumindest eines dieser AON-Devices jeweils als eines unserer regulären Devices zur Verfügung haben. Wenn das zweite noch inoffiziell über den Pinmux zur Verfügung steht, umso besser. Konkrete Überlegungen ===================== Schritt 1 --------- Bei den UARTs ist bei uns die UART_C als Debug-Port für den Cortex-M vorgesehen. Diese sollte also unbedingt UART1 oder UART2 sein. Das ist schon der Fall, nämlich UART1. Damit landet aber auch automatisch ein Teil von SPI2 dort. Das heißt wenn wir noch eine SPI im AON-Bereich haben wollen, dann muss das SPI1 sein. Die ist leider in der Rev. 1.00 sehr verstreut auf UART_A_RTS/CTS, PMIC_IRQ und ETH_B_PHY_INT. Wir müssen diese Signale also zusammen auf SPI_B legen und können stattdessen den dort freiwerdenden UART7 als UART_A nutzen. Damit wir aber den UART2, der ja ebenfalls im AON-Bereich liegt und bisher UART_A war, nicht verlieren, muss der folglich auf UART_D geschoben werden. Das ist gar nicht so dumm, weil dann haben wir alternativ auch den vollen UART_C zur Verfügung mit RTS/CTS auf den UART_D-Pins, so wie es bei PicoCoreMX8MP auch ist. Pin Nr. Name künftiges Signal (Pad-Name) --------------------------------------------------------- J1_14 UART_A_RTS UART7_RTS (GPIO_IO11) J1_16 UART_A_CTS UART7_CTS (GPIO_IO10) J1_18 UART_A_RXD UART7_RXD (GPIO_IO09) J1_20 UART_A_TXD UART7_TXD (GPIO_IO08) J1_34 UART_D_RXD UART2_RXD (UART2_RXD) J1_36 UART_D_TXD UART2_TXD (UART2_TXD) J1_56 SPI_B_SS0 SPI1_SS0 (SAI1_TXFS) J1_58 SPI_B_MISO SPI1_SOUT (SAI1_RXD0) J1_60 SPI_B_MOSI SPI1_SIN (SAI1_TXC) J1_62 SPI_B_SCLK SPI1_SCLK (SAI1_TXD0) Schritt 2 --------- Durch die obigen Aktionen sind nun die CPU-Pads GPIO_IO14+15 frei. Wenn man die nun auf die Pins J2_1 und J2_7 legt, kommen auch wieder schöne Zweitbelegungen mit UART3/4/8 sowie SPI8 zustande. Außerdem brauchen wir ISI_D6/D7, falls wir eine parallele Kamera betreiben wollen. Pin Nr. Name künftiges Signal (Pad-Name) --------------------------------------------------------- J1_1 I2C_B_IRQ GPIO2_IO15 (GPIO_IO15) J1_7 GPIO_J1_7 GPIO2_IO14 (GPIO_IO14) Schritt 3 --------- Bei SPI kann man die Richtung auf SIN/SOUT umkehren. Wenn man MISO/MOSI tauscht, sind die Zweitfunktionen (I2C, UART) konsistenter. Pin Nr. Name künftiges Signal (Pad-Name) --------------------------------------------------------- J1_66 SPI_A_MISO SPI6_SIN (GPIO_IO01) J1_68 SPI_A_MOSI SPI6_SOUT (GPIO_IO02) Schritt 4 --------- Der PCA9634 für die PWM-Signale und als GPIO-Expander ist nicht optimal. Erstens gibt es Probleme, da das PWM dann nur 93 kHz oder 190 Hz kann. das mag für dieverse Displays nicht geeignet sein, wenn die z.B. nur 1 kHz bis 15 kHz unterstützen. Und da ja auch der reguläre PWM damit erzeugt wird, also für beliebige PWMs funktionieren soll, ist es sogar sehr wahrscheinlich, dass das öfter mal nicht passt. Da der i.MX93 eigentlich sehr viele PWMs zur Verfügung stellt, wäre es doch seltsam, wenn gerade die dedizierte PWMs nicht damit möglich sein sollten. Zweitens gibt es Probleme im U-Boot. Dort können die LEDs nicht als PWM und nicht als GPIO angesprochen werden und müssen entsprechend kompliziert "von Hand" über I2C programmiert werden. Diese Probleme gibt es nicht, wenn ein regulärer digitaler I/O-Expander eingesetzt wird. Der ist (bei neueren U-Boot-Versionen mit Device-Tree) auch im U-Boot als GPIO ansprechbar und stellt damit konzeptionell keinen Unterschied zu nativen GPIOs dar. Zudem ist so ein Expander möglicherweise sogar billiger. Das Ziel ist also, den PCA9634 durch einen PCA9534 oder eine entsprechende PCAL-Variante mit 8 digitalen I/Os zu ersetzen. Da dürfen dann nur langsame Outputs drauf, z.B. Reset-Signale. Mein Vorschlag wäre: I/O0: ETH_A_PHY_RST I/O1: ETH_B_PHY_RST I/O2: USB_HOST_PWR I/O3: USB_OTG_PWR I/O4: WLAN_RESET (der PDn-Pin des WLAN-Chips ist 3,3V-tolerant) I/O5: BL_ON I/O6: GPIO_J2_83 (bzw. GPIO_J1_52, siehe 5.) I/O7: GPIO_J2_85 (bzw. GPIO_J1_54, siehe 5.) Damit ergeben sich dann noch folgende Änderungen: Pin Nr. Name künftiges Signal (Pad-Name) --------------------------------------------------------- J1_11 BL_PWM/PWM_A TPM5_CH2 (GPIO_IO18) J2_63 PWM_B TPM3_CH3 (GPIO_IO24) intern PMIC_IRQ GPIO4_IO29 (CCM_CLKO4) (1,8V, passt) intern ETH_A_PHY_INT GPIO2_IO28 (GPIO_IO28) intern ETH_B_PHY_INT GPIO2_IO29 (GPIO_IO29) J1_13 VLCD_ON GPIO1_IO10 (PDM_BIT_STREAM1) Schritt 5: ---------- (Dieser Schritt ist nicht ganz so wichtig, würde aber das Bild abrunden.) Falls Ethernet auf RGMII (ohne PHYs) konfiguriert ist, könnte man stattdessen die ETH_B-RGMII-Signale auf die AUDIO_B-Pins führen und so einen weiteren SAI mit 1,8V (wie bei PicoCoreMX8MP auch) nach draußen führen. Das würde eher der Pinbeschreibung entsprechen. Das würde aber bedeuten, dass man die ADC-Signale stattdessen auf SPI_C legt. Damit man trotzdem noch CLKIN und TAMPER hat, könnte man die optional auf RXC/RXFS oder TXC/TXFS legen. Je nachdem ob ein Kunde dann eher das eine oder das andere braucht, kann man den jeweils anderen CLKIN/TAMPER-Pin nutzen. Die beiden überzähligen GPIOs vom GPIO-Expander könnten stattdessen auf J1_52 und J1_54. Pin Nr. Name künftiges Signal (Pad-Name) --------------------------------------------------------- J2_65 AUDIO_B_I2S_MCLK SAI2_MCLK (ENET2_RD2) (1,8V) J2_67 AUDIO_B_I2S_TXFS SAI2_TXFS (ENET2_TX_CTL) (1,8V) J2_69 AUDIO_B_I2S_TXC SAI2_TXC (ENET2_TXC) (1,8V) J2_73 AUDIO_B_I2S_TXD SAI2_TXD0 (ENET2_RX_CTL) (1,8V) J2_75 AUDIO_B_I2S_RXD SAI2_RXD0 (ENET2_TD3) (1,8V) J2_77 AUDIO_B_I2S_RXFS SAI2_RXFS (ENET2_MDC) (1,8V) J2_79 AUDIO_B_I2S_RXC SAI2_RXC (ENET2_MDIO) (1,8V) J2_83 SPI_C_SS0 ADC_A (ADC_IN1) J2_85 SPI_C_MISO ADC_B (ADC_IN2) J2_87 SPI_C_MOSI ADC_C (ADC_IN3) J2_89 SPI_C_SCLK ADC_D (ADC_IN4) J1_52 GPIO_J1_52 (PCA9554_IO6) J1_54 GPIO_J1_54 (PCA9554_IO7) Schritt 6: ---------- Bei GPIO_IO25 und GPIO_IO27 muss der Jumper in den Zweig zu GPIO_J1_44 bzw. GPIO_J1_46 rein statt in den WLAN/BT-Zweig. Sonst hat man das Signal bei WLAN/BT noch auf dem B2B-Stecker und dort anliegende Signale können den WLAN-Betrieb stören. Schritt 7: ---------- Muss bei BT nicht das UART-Interface wie bei Null-Modem über Kreuz angeschlossen werden? Also RX<->TX und RTS<->CTS statt 1:1? Schritt 8: ---------- Das WLAN/BT hat ebenfalls JTAG. Macht es Sinn, die JTAG-Signale auch dorthin zu führen, damit man auch dort mal was Debuggen kann? Verfügbare Features =================== Alle acht UARTs sind verfügbar: = UART1 als UART_C, ggf. auch mit vollen Modemsignalen verfügbar + UART2 als UART_D, ggf. auch mit vollen Modemsignalen verfügbar = UART3 oder UART_4 auf J1_1/J1_7, mit RTS/CTS wenn Audio-Codec nicht bestückt = UART5 mit RTS/CTS sowohl auf SPI_A, als auch auf JTAG-Pins = UART6 als UART_B mit RTS/CTS (genutzt für Bluetooth falls WLAN/BT bestückt) = UART7 als UART_A mit RTS/CTS = UART8 auf J1_1/3/5/7 Alle acht SPIs sind verfügbar: + SPI1 als SPI_A, ggf. mit SS1 auf CAN_A_RX + SPI2 kompakt auf UART_C/D, ggf. mit SS1 auf VLCD_ON = SPI3 auf UART_A, ggf. mit SS1 auf UART_B_RTS = SPI4 und SPI5 sind zwar verfügbar, sogar mit SS1 und SS2, aber sehr verstreut und nur wenn Audio-Codec nicht bestückt = SPI6 auf SPI_A = SPI7 auf UART_B (sogar mit SS1 auf GPIO_J1_44 wenn WLAN/BT nicht bestückt) + SPI8 auf J1_1/3/5/7 kompakt beisammen Alle acht I2Cs sind verfügbar: = I2C1 als I2C_A = I2C2 als I2C_D + I2C3 auf SPI_A_SS0/MISO kompakt beisammen, zusätzlich mit 1,8V auf J2_21/37, falls Ethernet auf RGMII + I2C4 auf SPI_A_MOSI/SCLK kompakt beisammen + I2C5 als I2C_C, alternativ nochmal kompakt auf SPI_A_SS0/MISO + I2C6 auf UART_B_RXD/TXD, alternativ nochmal kompakt auf SPI_A_MOSI/SCLK + I2C7 auf UART_B_RTS/CTS, alternativ nochmal kompakt auf UART_A_RXD/TXD + I2C8 als I2C_B, alternativ nochmal kompakt auf UART_A_RTS/CTS Beide CANs sind verfügbar: = CAN1 als CAN_A, alternativ nochmal auf SPI_B_MOSI/SCLK = CAN2 auf JTAG_TDI/TDO, auf SD_A_DAT0/1, auf J1_44/46 falls WLAN/BT nicht bestückt und mit 1,8V auf J2_13/15 falls Ethernet auf RGMII Beide I3Cs sind verfügbar: = I3C1 auf I2C_A (PUR auf I2C_D_SCL) = I3C2 auf SD_A_CD/CLK (PUR auf SD_A_CMD), alternativ mit 1,8V auf J2_1/3 (PUR auf J2_11), falls Ethernet auf RGMII Beide MQS sind verfügbar: + MQS1 auf CAN_A und SPI_B_SS0/MISO verfügbar = MQS2 auf JTAG_TDI/TDO und SD_A_DAT2/3 verfügbar Alle drei SAIs sind verfügbar: + SAI1 auf SPI_B/UART_D_RXD verfügbar, ggf. sogar mit RXFS/RXC auf I2C_D + SAI2 mit 1,8V als AUDIO_B verfügbar falls Ethernet auf RGMII = SAI3 als AUDIO_A Parallele und serielle Kamera: = Serielle Kamera auf MIPI_CSI + Parallele Kamera mit 8 Bit auf SPI_A/UART_B_RTS/UART_A/J1_1/J1_7, jetzt etwas kompakter Sonstige: + PWMs vom i.MX93 sind besser regelbar, da beliebige Frequenzen möglich + Es ist kein LED-Treiber, sondern nur normaler GPIO-Expander notwendig Anmerkung: Bei den dedizierten PWM-Pins hat der Wunsch, mindestens einen Channel aus dem AON-Bereich zu haben, leider nicht geklappt. Aber es sind genug PWM-Signale auf anderen Pins verfügbar, so dass man auch im Low-Power-Modus PWM-Signale zur Verfügung haben kann.

View Issue Details

Activities