08-23-2018, 01:43 PM
(08-22-2018, 02:54 PM)Bullet64 Wrote: Not every usb-TTL adapter works with 1500000. I have tested three before i found an working adapter.
But i think your board isn't dead. The last image looks good.
1. Erase SPI or set the jumper.
2. Flash an new image to an working sd-card
But the main part is to get an working UART connection. Without it, it's hard to find the problem.
When I erased the SPI flash (at least I think it was erased, I cant see the register values or view it in some other manner to verify it). I used the u-boot-erase-spi-rockpro64.img.xz image, flashed it to a secondary SD card, and then I inserted it and powered it on. The indicator LED lit up and began flashing in 1 second intervals as described in https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md (Although this process is described for the Rock64, the directory it links to contains versions for the rockpro64, so it should work... right?) which links to https://github.com/ayufan-rock64/linux-u-boot/releases/tag/2017.09-rockchip-ayufan-1033-gdf02018479
Because this appeared to be working so well, I took that same SD card (used for erasing the spi), and then burned the latest RockPro64 linux image to it. (Part of me was hoping that because this SD card is just a standard 16gb class 10, and not an extended capacity SD card like I was using before, maybe there was a problem with the board recognizing the extended capacity card. I have heard of that sort of thing happening in different contexts, so it was worth a shot). However this had no effect and the LED did not come on this time.
Yup, a working UART connection would be super helpful...
(08-22-2018, 02:57 PM)dukla2000 Wrote: ...
I have not done a serial connection myself but everything I have read around the ROCKPro64 indicates that is the best guide and 1.5M is absolutely the correct setting.
...
(08-22-2018, 01:55 PM)DIDquest Wrote: I then tried to enter OTG mode, and it looks like the recovery button and the LEDs work. However, the I don't see anything when connected via a usb (tried it in linux and windows) and according to the wiki "In all cases the USB device made available at the host has device ID 18d1:d00d. " That ID does not appear when I use "lsusb" to search the attached usb devices. (If there is a different command I should be using please let me know)I did this myself last night and then wrote that section in the wiki - yup I did a plain lsusb. Again a success/fail result!! For completeness I used the USB-C connector on my ROCKPro64 so I know that works. But I cannot confirm the top USB2 actually works - I copied that into the wiki from elsewhere and it could be wrong.
...
As I was writing the wiki and learning from the schematic and trying to phrase it simply, I think my conclusion is (as per the wiki) that the 2 jumpers are perfectly legit suppression options. If you can try with first disable SPI, then with both could be an option?
...
A last check: a chap on IRC last night seemed to have a duff ROCKPro64 that would not boot. His observation was that the ethernet transceiver chip (between the RJ45 socket and the CPU, has no number on the wiki exploded diagram) was getting too hot to touch after a few seconds. That is at odds with mine (generally just warm), but may be a common symptom of failure?
1. Thanks for confirming the 1.5M baud rate it checks one more thing off the list of possible problems.
2. I used the top USB 2.0 port, but I will try it again with the type c connector just in-case
3. I am not sure that when I tried the 2 jumper suppression, I was doing it correctly. The wiki seemed to say that pins 23 (CLK) and 25 pin (GND) should be connected together. If that is the case, I tried it and it had no effect on the boot behaviour of the SD card. (If I was mistaken, please correct me).
4. I did not try the other flashing modes, but I will give it a shot (just for the sake of curiosity).
5. I allowed the board to heat up again and then touched the chip sitting behind the ethernet jack and it was only peripherally warm. (I think a byproduct of the whole board heating up I think).
As an added treat, I literally just remembered as I was writing this out that one of the other companies that we share our office space with, has several thermal imaging camera modules....so I took some pictures of what happens when I leave the board plugged in (with the fan, which I was powering externally, turned off) for 2 minutes. Please note that the number in the left hand corner is not a temperature value it was a voltage reading coming off the chip, and they didnt have the conversion calculator handy, so we dont have a temperature to go with it. I doubt any of this will be useful, but I just think it is cool (and something you guys might get a kick out of).
Images 1 and 2 were taken with the heatsink ON
Image 3 is with the heatsink off but the thermal spreading pad still on.
The only think I found surprising was in img1cut.jpg the the PCI bus was hotter than the surrounding components, dispite never having used that port. Although part of me thinks that this would be caused by the tons of lanes that have to go between it and the cpu (or all of the metal pins right there) and the excess plastic which might hold on to the heat longer. I could be wrong about that though.
