[Solved] Cudy WR1300 what are J12 and J14?

Hi,

today I got a Cudy WR1300, failed to install OpenWrt using the methods described by Cudy and by the respective OpenWrt commit log, and while playing around with it a bit more, bricked it. :frowning:

Only afterwards I discovered the Cudy WR1300 bricked thread that describes my situation pretty good.

So, thanks to @baquilla I know now that I could restore the device by desoldering the RF shield and (at least partially) desoldering the flash chip. But I would like to avoid desoldering the shield, and so I wonder if J14 is a JTAG connector through which U-Boot could also be re-flashed and what its pinout is. So far I've found the positions of VCC and GND on J14 (continuity to the respective pins on the UART connector), but I haven't been able to find any JTAG pinout that matches this.

     _____
VCC / o o | GND
    | o o |
    | o o |
    | o o |
    | o o |
     ¯¯¯¯¯
      J14

Additionally I wonder what J12 is, and found the power pins in these positions

_____
| o | VCC
-----
| o |
| o |
| o | GND
| o |
¯¯¯¯¯
 J12

Any input on the purpose and further pinout of these two connectors is welcome.

I´d guess, J12 is a serial console. There should be Rx and Tx on 2 of the missing pins, maybe the last pin ist just NC?

_____
| o | VCC
-----
| o | Rx
| o | Tx
| o | GND
| o | NC
¯¯¯¯¯
 J12

Just a shot in the dark...

HTH

The two WiFi chips don't seem to have serial consoles and the MT7621 has its primary serial console on J4, but it might be one of its other two UARTs.

OTOH, on J4 I can measure a pulldown of 1k on RX and a pullup of 10k on TX, but I cannot measure any pullups or pulldowns up to 2M on the non-power pins of J12 and J14.

Hi @rmax ,

No clue about J12, nonetheless I don't think it could be useful for recovery matters. Makes no sense to wire a second console, and such amount of pins could just be a serial debugger or anything else, none useful without the right documentation.

J14 looks like a JTAG, non-standard but has enough pins to fit it all. Why did I discard it?
a) I couldn't find good JTAG documentation for that MCU to use JTAG to program the SPI flash.
b) Some pins of J14 are connected to the LEDs: SYS, USB, WPS,...; That could be useful to identify pin layout but it's also possible that the J14 can be only used for debugging in lab removing some components. I don't recall exactly but I think the LEDs are connected directly, no transistors.

I was just looking for recover the device and desoldering the shield is easy and fast. I didn't try but it's possible that the SPI flash can be programmed without desoldering any pin, just using a clamp. To achieve that, it's mandatory to keep the MCU in reset state. If we agree that J14 could be a JTAG, a RST pin must be available. Following the flash tracks could also show up some alternative points to connect the flash programmer (vias or tracks in bottom layer...).

Tell us about your findings.

Thanks a lot, @baquilla

In a quick test, I couldn't find any direct connections between LEDs and J14 besides 330 Ohm current limiting resistors that go from one end of each LED to one of the power pins, which is of course unrelated to the functionality of J14.

I cannot test know, but I'm pretty sure I found that connection between LEDs (resistors) and J14. My apologies if I were wrong.

After closer inspection it looks like we were both right to a certain degree. :wink:

There are traces running from the eight non-power pins of J14 to the LEDs, but they are not connected there, due to unpopulated resistors between these traces and the kathode of the respective LED. For completeness, here is the schema of these unconnected traces:

      _____
 VCC / o o | GND
  5G | o o | WPS
LAN1 | o o | 2.4G
LAN3 | o o | LAN4
 WAN | o o | LAN2
      ¯¯¯¯¯
       J14

In the dts I noticed that SYS, USB and WPS are controlled by GPIOs that are alternate functions of three of the JTAG pins. So, unless the dts is wrong here, J14 cannot be a complete JTAG connector, but it might still have the remaining JTAG signals.

But I am pretty sure I have found the RESET signal (PORST): There is an unpopulated SOT-23 footprint called U19 between the SoC and the oscillator. Two of the pins are connected to VCC and GND, the third one runs to the CPU, and the pinout matches with typical SOT-23 reset delay circuits. It looks like the RC circuit RC1 located next to U19 is being used for the RESET delay instead, as the capacitor connects to the suspected RESET pin and GND.

Update: I can confirm my assumptions about the PORST line. With that grounded, I was able to read out the flash with a clamp. It turned out that the uboot and firmware partitions were erased. I reflashed uboot with the flashrom tool and then used TFTP to recover the firmware.

Update2: In the end I decided to replace the flash chip with a W25Q128 I had still laying around here, so now I finally have OpenWrt on that box without having to wait until OpenWrt and Cudy support the new XM25QH128C.

But beware! Cudy's own Firmware didn't seem to like the chip swap. After recovery the FW booted, but login to the web interface was greyed out saying something like "invalid boardinfo". From there I went back to TFTP recovery, but gave it Cudy's OpenWrt image as recovery.bin. That worked fine, and then I was able to sysupgrade to an official build of 21.02.2.

1 Like

Hey... great job!

So seems that they fit those resistors when the need to use JTAG for debugging purposes but it's not available on standard devices.

Regarding flash swap, don't forget to copy the whole flash, or at least the bdinfo partition. Each device has its own factory configuration like MAC addresses and RF calibration values. Looks you did it, so I don't understand that failure and why OpenWrt image recovered from that. Good to know anyway.

I don't think anymore J14 is for JTAG at all, because only one of the LEDs that is controlled by a JTAG pin also has a trace to J14 (WPS). All the LAN and WAN LEDs are controlled by hardware, so either J14 and the missing resistores are an alternate way to controll these LEDs (if the pins of J14 are also connected to GPIOs, which cannot be seen on the board), or J14 is a way to "watch" the LEDs for automated testing.

Yes, I started with the full flash dump I had taken from the original flash before recovering, then I copied the first 192 kB from recovery.bin over that file, flashed that to the new chip and finally swapped them. Then flashed recovery.bin via TFTP and finally flashed Cudy's OpenWrt image from Feb, 2nd, again via TFTP, because I wasn't able to log into the web interface of the vendor firmware. Not sure if that intermediate step was really needed. Maybe I could have gone directly from the new flash with the recovered U-Boot to Cudy's OpenWrt image with TFTP.

You mean t hat "invalid boardinfo" error I got? I guess that the vendor FW checks certain parameters of the board and got upset when it found a different type of flash than expected. As I wasn't interested in the vendor FW anyway, I didn't bother investigating this any further.

pro tip, never assume which pin is power, use a multimeter between each pin and a metal shield or the ground plate to tell

personally, once I find which one is power, I bend it a little, so I never forget :+1:

1 Like

And actually a good one! Cudy support has finally told me the requested pinouts:

_____
| o | VCC
-----
| o | RXD3
| o | TXD3
| o | GND
| o | EXT_RESET
¯¯¯¯¯
 J12 (Ext-UART)

So, this seems to be a serial interface to connect some external hardware, including the possibility to reset that hardware if needed. I guess that EXT_RESET is actually connected to a GPIO. At least it is not connected to the pad I identified as PORST and there is also no pin named EXT_RESET on the MT7621.

According to Cudy J14 is connected to the LEDs through unpopulated resistors (as I beeped out before), but it does not seem to have additional connections to the SoC. But there is one inconsistency between my measures and Cudy's information. They say that the pin I labeled "WPS" would be connected to GPIO15 through an unpopulated resistor, but according to the dts file, GPIO15 drives the SYS LED whereas the WPS LED to which the connection from that pin is actually leading is driven by GPIO13. But I do not yet have tested the GPIO to LED relationships in the dts file for correctness.

1 Like

15 posts were split to a new topic: Cudy WR1300: Issues switching to OpenWrt on devices with a XM25QH128C flash chip

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.