Other Parts Discussed in Thread: IWR6843
Tool/software:
Setup:
IWR6843ISK EVM with Mainboard, Mainboard contains FTDI chip for UART to USB, Laptop connected with this board to view UART logs. IWR6843ISK mated with mainboard using 60-pin B2B connector, DC adapter used to power both boards ie. B2B used to deliver power from mainboard to IWR643ISK
Issue:
Initially, UART communication was not working upon powering on the supply, unless the IWR6843ISK was power cycled. Probed the entire UART path, from FTDI to IWR6843 UART pins to realize that the FTDI was working fine, whatever was typed on the console was getting converted to its UART packet. The only way to resolve the issue was to power cycle the IWR6843ISK board with the UART pins connected to mainboard. Power cycle of IWR6843ISK without UART connected to powered mainboard does not resolve the issue.
Observation:
When UART TX and RX of IWR6843ISK are connected to mainboard, nRESET remains high due to the pullup on the mainboard UART side and this back-supplying the 3V3 rail on the IWR6843ISK to which the nRESET is also pulled up. First time power ON of both boards results in UART not working. During this condition, if we powercycle only the IWR6843ISK board (ie., UART connected to mainboard thereby nRESET in High state, and VIOIN turned OFF then ON), it resolves the issue. IWR6843 reads from the QSPI flash and UART logs can be observed. However, if we remove the UART connections (nRESET brought down to low) then power cycle the IWR6843ISK, UART does not work and there are no transactions on the QSPI lines. In short, IWR6843 works only when nRESET is de-asserted THEN VIO is supplied. This was verified by adding a load switch delay to the 5V supply. This time, the nRESET is pulled high earlier through the UART pins back-supplying the 3V3 rail on the IWR6843ISK, post which the 5V rises (thanks to the delay caused by load switch with an RC delay on its EN) and the VIO is supplied to the IWR6843.In this case, the IWR6843ISK works on first time power on itself.
This is contradictory to the clause mentioned on the IWR6843 datasheet, that nRESET must be deasserted only after the power rails have reached their stable state - it works only when its the other way round, when nRESET is deasserted and in HIGH state before VIO reaches its level. We also tried manually asserting the nRESET using the S2 switch on the board, while the board was in working state and UART logs were obsevable, and we found that the UART locked up again.
