I recently bricked my colibri by trying to update u-boot and now it doesn’t boot. I tried entering recovery mode but no luck, the colibri is a VF50 V1.2B plugged in a Colibri Evaluation Board Rev. 3.2.
I followed the instructions in VFxx Recovery Mode | Toradex Developer Center, however, I couldn’t find the “update.sh” shell script, instead I cloned toradex “imx_loader” repo, built it and tried the following command:
./imx_uart /dev/ttyS0 vybrid_usb_work.conf /path/to/u-boot-nand.imx
and got the following message:
Do you actually put module in recovery mode? Do you keep recovery pins shorted while powering module up?
Are you sure /dev/ttyS0 is your serial device?
Some USB dongles may get reset due to noise from switching on power supply. As well imx_uart perhaps, I’m not sure, may stuck due to not clean RS232 input from VF while power is switching on.
USB dongle with LEDs is useful for recovery over RS232. Use oscilloscope if you don’t have LEDs as a clear indication of comms going on and not stuck. Update timeout is way too long. If LEDs are off, just retry recovery switching VF off, entering recovery mode and launching update.sh again.
Yes, I’m sure /dev/ttyS0 is the target serial port (the computer serial port) and I’m sure it is healthy because it works when I replace the colibri with a new one (showing the bootloader output).
I’m also sure I’m pressing the recovery button while turning it on for 2-3 seconds, additionally I tried shorting the recovery pads in the colibri too, but it didn’t work either.
If you are able to put other Colibri VF50 into but can’t but only this one, it might be some hardware issue.
But, I would like to ask some questions:
Have you tried not to use the flow-control pins, and also configure the software that you are using to view the serial console to also not use flow-control?
Just to be sure: you tried with another (or several others) Colibri VF50 as well right?
Yes, I tried shorting RTS/CTS and using the -n option, but got the same outcome.
Regarding the last question, I used a different colibri VF50 that is not bricked and got the normal boot output (u-boot count down), this confirms that the serial port is fine… I also attempted entering the recovery mode in that one, but got the same error, which seems to indicate this is not a hardware problem (at least on the colibri side)
Just let you know that I used a scope to check the RS232 signals, here is the result:
TX (from the computer point of view) sends the expected bytes correctly with levels -10V and +10V (the idle state is -10V)
RX is -5V all the time
RTS is 10V all the time
CTS is at 5V all the time
The RTS/CTS are asserted all the time so I don’t think they could be the problem, I also checked that the null modem cable is crossing 2<->3 and 7<->8 as expected
I’m not sure if they enter the recovery mode, given that the good vf50 doesn’t show the normal boot messages, I believe it is in the recovery mode but it’s not responding.
Finally I found a way to recover, though not using the recovery mode.
I used a jtag programer to load and run u-boot from memory, then used u-boot to write to the u-boot mtd partition. OpenOCD was used with target configuration vybrid_vf6xx.cfg which seems to work with VF50
EDIT: I consider this solved but I’m still curious to know why the recovery mode didn’t work, any hint will be much appreciated
Applying mods to VF booatloader accidentally I flashed u-boot for different board :-). Recovering I tried to notice what works and what doesn’t. It always was problematic to recover over imx_uart. Here my findings. Perhaps it is some race condition in imx_uart, perhaps bug in particular imx_uart binary. This is what was important in my case on my PC. After several unsuccessfgull attempts I started to think it depends on USB / COM on PCB, COM on PCI card. I turned to be independent of host OS, vbox or not vbox:
imx_uart seems not flushing COM port. I mean some garbage, that may get into host COM port when you power carrier board, seems being not discarded by imx_uart and it fails to receive right response from target machine. The same applies to imx_uart for Linux and imx_uart for Windows. You need to start minicom or some other terminal program, then power on Vybrid with recovery pins / recovery jumper closed. Once power is applied (recovery mode is entered), you may close terminal and go to imx_uart or update.sh. Terminal application step really helps.
don’t use -n switch, instead use full RS232 cable and short RTS/CTS? somewhere. On Iris carrier board you may short pins 4 and 6 of UART header. Using -n switch breaks things always. In the best case imx_uart will report non-zero but wrong and random association phase code.
If these ^ two are OK, starting imx_uart/update.sh will complete association phase in less than one second and start uploading u-boot.
Thank you Edward for looking into this, unfortunately, that procedure didn’t work in my case, I still get the same issue, I even tried flushing and sending the four magic bytes(0x23 0x45 0x45 0x23) using a simple python script but didn’t get them back (or any other response). I guess I’ll keep using JTAG for recovering in future, thanks anyways.
