Skip to content

Instantly share code, notes, and snippets.

@bigunclemax
Last active August 6, 2024 02:52
Show Gist options
  • Save bigunclemax/c566ecfc2f6d92e76e68446e46bdd944 to your computer and use it in GitHub Desktop.
Save bigunclemax/c566ecfc2f6d92e76e68446e46bdd944 to your computer and use it in GitHub Desktop.

How to flash reformat on FordSync3 through USB cable

Intro

This method allows to flash Ford Sync 3 multimedia module(APIM) through USB cable even if it was bricked 🧱. You don't need to solder either the eMMC card reader or any other wires. The only thing you need is to disassemble the Sync module and short circuit of two pads.

TL;DR ➡️

Hardware

Ford Sync 3 module consists of two boards:

  • Main board - IPC/CCPU with TI Omap5432 SoC as main CPU, RAM, eMMC flash.
  • Second board - VMCU. CPLD and microcontroller placed on it. This part is responsible for the CAN interface (since Omap5432 doesn't have it) and this board also acts as an external watchdog for the main CPU.

IPC and VMCU communicates through UART interface (speed 500kbps, for packets exchange uses COBS encoding). More on this maybe some other time 🙃

OMAP5432 boot mode

According to public datasheet OMAP5432 Multimedia Device we can get info about ways and order of Omap5432 booting (paragraph 2.6 SYSBOOT configuration).

Boot table. sysboot

Look at sys_boot3. Exact this pin corresponding to boot priority from USB. If pull down sys_boot3 pin to GND, then Omap SoC will be booting from USB at first.

But how to find sys_boot3 ? 🤔

Answer on this question we could find on another datasheet OMAP5432Multimedia Device Engineering Samples 2.0. This paper contains terminal description and ball locations(Figure 2-1. OMAP5432 AAN S-PBGA-N754 Package (Bottom View)).

Looking for sys_boot3 and see that it's located at V31 place. sysboot

But how to get access to V31 ball? 🧐

Since this ball is located under Soc. we can't get to it without a special tools.

Fortunately mate Cusco came to the rescue. He ring out Omap Soc pads and many test points which located at board.
And he found V31!

sysboot

USB boot MY18.5 (Thanks to IgorStr. for this find)

MY18 5_usbboot_short

So, now we ready to boot Sync 3 module from USB.

USBboot

Time to connect Sync to PC with Linux through miniUSB cable. Next we need to wake up Sync by CAN packages. Short two pads circled in red and then enable power 12V.
Look at dmesg log:

kernel: [431083.350475] usb 1-3: new high-speed USB device number 114 using xhci_hcd
kernel: [431083.499541] usb 1-3: New USB device found, idVendor=0451, idProduct=d011, bcdDevice= 0.00
kernel: [431083.499555] usb 1-3: New USB device strings: Mfr=33, Product=37, SerialNumber=0
kernel: [431083.499561] usb 1-3: Product: OMAP5430
kernel: [431083.499566] usb 1-3: Manufacturer: Texas Instruments

Perfect, TI SoC is enumerated on USB bus and awaiting to code download...

But what code we should load to SoC? 🤓

A small remark should be made here. TI Omap5432 USB boot is not actually boot from USB flash drive. Instead we must transfer our executable code (bootloader) to Soc via USB. Then in this bootloader we have to implement the functions to access the Sync eMMC.

After several days of googling, I managed to find links to articles about the TI OMAP5 5432 uEVM ES2.0 (Panda5) debug board refers to http://omapedia.org. Trying to open that links and ... it's redirected to www.ti.com. The site was removed. Fuck! 🤬

However, web.archive.org remember everything, or at least a lot 😌

Most of the links to the source code repositories are still alive. The most interesting tool is UsbBoot(Omapboot). Getting sources git clone git://git.omapzoom.org/repo/omapboot.git usbboot && git checkout 33af7cb409b603cf7988306ab2ea70f052a9a02b and try to compile them.

To build UsbBoot for Omap SoC, we need a toolchain for ARMv7. First option is to get it from Android repository which is linked in the Omap wiki article. Second and easier option is to get assembled toolchain from here.

Compile UsbBoot

export CROSS_COMPILE=/path/to/toolchain/bin/arm-linux-gnueabihf-
make MACH=omap5 BOARD=omap5uevm

And run...

user@pc:~/$ sudo ./out/omap5uevm/usbboot -f
reading ASIC ID
CHIP: 5430
rom minor version: 02
IDEN: 0000000000000000000000000000000000000000
MPKH: 0000000000000000000000000000000000000000000000000000000000000000
CRC0: 071a9a31
CRC1: 00000000
device is GP
using built-in GP iboot of size 23-KB
sending 2ndstage to target...
waiting for 2ndstage response...
received 2ndstage response...

After loading 2ndstage bootloader to Omap and receiving response from it we can try to attach to SoC with fastboot (yes, it's Android tool) and attempt to execute some commands.

fastboot

RE_format

The reformat package is intended for a factory (clean) installation of the Sync 3 OS. It consists of 2 parts:

  1. MLO - bootloader
  2. QNX-IFS-REFORMAT - OS image which performing a factory installation of Sync 3 system.

These are exactly the files that we want to flash on the Sync eMMC.
It remains to understand where exactly in eMMC they should be located.

To do this, let's see at the original reformat installation script. It contains the following line: update_boot -t -i /tmp/QNX-IFS-REFORMAT -m /tmp/MLO

So, there is some utility called update_boot that flashes the bootloader and OS firmware. Let's look under the hood...

First of all do strings update_boot:

Usage: %s [-i] [-m] raw partition

	-i   Path of IFS image file
	-m   Path of MLO image file
	-t   Toggle active IFS partition
	-r   replace current IFS with new one
	raw partition   Path of raw partition to write IFS and MLO image files, default value is /dev/hd0.

Great, we found a help strings, and now we know which params are accepted by this utility.

Well, let's find out what exactly this software does.

Take Ghidra🐉 and import update_boot to it. Deсompilation process will not be described in this article. If someone interesting here is link to shittypseudocode obtained by decompilation.

As a result, we get following layout of Sync 3 eMMC.

Sync3 eMMC layout

block offset name
0x0000 MBR
0x0002 0x0000400 (1024) boot bank info
0x0100 0x0020000 (131072) MLO
0x0184 0x0030800 (198656) IFS first bank
0x7cd2 0x0F9A400 (16360448) IFS second bank

Well, it's time to learn how to flash eMMC Sync with custom images transferred via USB from a PC.

Sync3flash

Omap usbboot which we previously compile already has fuctions for eMMC read\write. Let's modify it a bit by adding ability to flash custom images into MLO and QNX-IFS-REFORMAT offsets.

👉 sync3flash.

Flashing eMMC Sync3

Requirements:

  • PC with Linux (virtual machine may not work1, but you can use a livecd Linux on a flash drive, for example puppy linux)
  • sync3flash tool
  • MLO and QNX-IFS-REFORMAT files from REFORMAT package (you can get patched reformat package here)
  • miniUSB cable

So, now we have everything we needed for flashing Sync 3. Let's start:

  1. Disassembly Sync 3 module to get physical access to main board with Omap SoC.
  2. Connect Sync directly to PC through USB cable. (Don't try to connect through Sync 3 USB hub. This will not work)
  3. Start waking up Sync by sending CAN packages.
  4. Run sync3flash tool sudo ./sync3flash -i QNX-IFS-REFORMAT -m MLO
  5. Short contacts circled in red
  6. Enable 12V power supply to Sync module.

If everything goes smooth, you should see output like that:

user@user-PC:/tmp$ sudo ./sync3flash -m MLO -i QNX-IFS-REFORMAT 
waiting for device...
reading ASIC ID
CHIP: 5430
rom minor version: 02
IDEN: 0000000000000000000000000000000000000000
MPKH: 0000000000000000000000000000000000000000000000000000000000000000
CRC0: 071a9a31
CRC1: 00000000
device is GP
sending 2ndstage to target...
waiting for 2ndstage response...
sending image to target...size (22696-B/22-KB/0-MB)
sending image to target...size (9279956-B/9062-KB/8-MB)

After 30 seconds Sync 3 will reboot and reformat will start. That's it 😎

PS:

This article is for entertainment and educational purposes only. All characters are fictional and coincidences are accidental.

PPS:

Many thanks to Cusco for the hardware help, Sanek2033 and Au{R}oN for inspiration and Lynx for the idea. 🙏


NOTE:
You can use virtualized Linux on Windows to make it work. Below is example for VirtualBox:
Settings -> USB -> Add Empty Filter
Name: OMAP5 sEVM
Vendor Id: 0451
Product Id: d011

Then sudo ./usbboot -f and do as usual with your board:
* first time should fail as drivers will be installed
* next time will work OK.

Note: We don't support this, so if you have any issues please direct it to the omap5 mailing list. 

Footnotes

  1. How to flash using Virtual Box (from OmapWiki)

@m0nkeyc0de
Copy link

m0nkeyc0de commented Sep 8, 2022

You made my day ! There is hope for my Sync3 I just bricked. Thanks !

@ydupas1
Copy link

ydupas1 commented May 20, 2024

So I'm stuck in "waiting for device" screen even after shorting the pins. What about that 12v power supply? Do I have to add external power to it?

@m0nkeyc0de
Copy link

m0nkeyc0de commented May 20, 2024

So I'm stuck in "waiting for device" screen even after shorting the pins. What about that 12v power supply? Do I have to add external power to it?

The board has to be powered on in order to have this working as shorting the pins changes the boot mode. I did this directly in my car, with a switch soldered to the pins, and long wires. When it works a new USB device must appear. The watch -d lsusb command may help you to see if you did it correctly.

Note that you'll probably need to do a key cycle to turn power on/off on the infotainment system.

Once REFORMAT is booting, you'll need to find a full installation package. The update package you can download from Ford website will very likely not work. I heard that it may eventually be possible that modders forums could have a solution to propose but this is only a theory.

@TheWonderSock
Copy link

Hi! I have an APIM that was bricked after an update and now only shows a black screen.
MFG date 06/26/2017
ford escape
HJ5T-14G370-KCB

I have set up a test bench as per https://github.com/EtoTen/stm32_can_sim and with everything set up my bricked APIM starts the backlight only after receiving the can bus messages. When I remove the can bus wires and supply 12V the backlight instead does nothing which shows I set the bench up correctly at least.
I should also note my unit has a transistor populated between the 2 pads that you have circled for V31 and GND.
My unit has 2 USB ports a grey and a black one. I have my linux computer connected to the black one.
I can't get the watch -d lsusb suggestion to work nor can I get the sync3flash command to say anything other than waiting for device.

My order of operations:
Plug in the usb into the black connector.
Start the program.
"Waiting for device"
turn on the test bench.
Backlight comes on a second later.
short the 2 sides of the transistor V31 and GND with tweezers for a second
observe nothing changes and I'm still stuck at waiting for device.

Do you know what I could be doing wrong?

UPDATE!
I've soldered a male and female dupont wire to the pins on the board so it stays shorted during running the sync3flash.
After running watch lsusb, I noticed while holding the two pins together
I see for a second texas instruments OMAP5430 show up and then disappear. This looks like great news!

I'm pretty sure the reason it keeps disappearing after a couple seconds is because the canbus thing is sending the start message in a loop? Not sure. I need comments on if the code running in a loop from https://github.com/EtoTen/stm32_can_sim is safe to use or if I was just lucky.

I turned everything off.
I ensured the two wires I soldered to V31 and GND were attached together.
I started the sync3flash.
I applied 12V to the test bench.
I got past the waiting for device section and it uploaded the payload image correctly!

I got it into a Please Insert USB stick... screen.
It's got interesting background images including a mustang logo, a shelby cobra, and a ford logo.
Mine says version:306.

It's alive! now I just have to insert a usb stick with the appropriate update files. Watch me brick it again lol.

TLDR:
If your unit has a transistor where the screenshot doesn't this will still work.
make sure the pins are shorted together for the duration of the sync3flash operation.
monitoring lsusb is a great way to diagnose if you're having usb issues or not going into the boot mode correctly.

Can you update the readme to make sure the exact times when the pins should be shorted are made more clear?

@shgatev
Copy link

shgatev commented Jul 10, 2024

I am tring the process directly on the car, I have two soldered wires, when they are connected I can see for the second OMAP5430 and then disappear, where is my mistake? Can you help, please!

@m0nkeyc0de
Copy link

I read the notes I took and the devices also showed up for only a couple of seconds and this looks to be expected. The "flashing software" must be running and sending some boot code during this window. Below are notes I took when I saved my APIM.

This module is running QNX on a TI OMAP5432 with ARM Cortex A-15 cores (ARMv7-A architecture). Below are links to useful documentation.

ARMv7 toolchain

I used a "bare-metal" Linux Mint 21 to do that.

# Get build tools and fastboot
apt install build-essential gcc-multilib fastboot cmake

# Get toolchain
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6
# Load an older commit because repo has been emptied (why ?)
git checkout fafbf25b1b6e9c0af4b5e00f57a5a4f08ecbd09e

Booting over USB

We can see the APIM SoC appear in dmesg

[  302.441661] usb 1-2: New USB device found, idVendor=0451, idProduct=d011, bcdDevice= 0.00
[  302.441674] usb 1-2: New USB device strings: Mfr=33, Product=37, SerialNumber=0
[  302.441680] usb 1-2: Product: OMAP5430
[  302.441685] usb 1-2: Manufacturer: Texas Instruments
[  305.446208] usb 1-2: USB disconnect, device number 9
[  313.781460] usb 1-2: new high-speed USB device number 10 using xhci_hcd

With lsusb we also can see it show up but it disappears after a few seconds

Bus 001 Device 011: ID 0451:d011 Texas Instruments, Inc. OMAP5430

Without V31 grounded it doesn't appear at all.

omapboot (usbboot) and fastboot

If you're confident you can skip this but I'll make sure the toolchain as boot over USB are working. The installed toolchain provides arm-linux-gnueabi- executables. Let's use them with the provided Makefile

# Clone omapboot
git clone git://git.omapzoom.org/repo/omapboot.git usbboot
cd omapboot
# Load an older commit as the most recent one doesn't contain omap5 stuff
git checkout 33af7cb409b603cf7988306ab2ea70f052a9a02b

# Compile with the toolchain https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6
export TOOLCHAIN=~/arm-eabi-4.6/bin/arm-eabi-
make MACH=omap5 BOARD=omap5uevm clean
make MACH=omap5 BOARD=omap5uevm 

Now run usbboot as root and let's see what is happening:

#~/sync3$ sudo ./usbboot -f
[sudo] password for john:            
waiting for device...
reading ASIC ID
CHIP: 5430
rom minor version: 02
IDEN: 0000000000000000000000000000000000000000
MPKH: 0000000000000000000000000000000000000000000000000000000000000000
CRC0: 071a9a31
CRC1: 00000000
device is GP
using built-in GP iboot of size 23-KB
sending 2ndstage to target...
waiting for 2ndstage response...
received 2ndstage response...
#~/sync3$ 

A new device just popped-up in lsusb output:

Bus 001 Device 016: ID 0451:d022 Texas Instruments, Inc. omap5uevm

Let's have a look at dmesg

[ 1846.307059] usb 1-2: new high-speed USB device number 16 using xhci_hcd
[ 1846.456195] usb 1-2: New USB device found, idVendor=0451, idProduct=d022, bcdDevice= 2.00
[ 1846.456209] usb 1-2: New USB device strings: Mfr=44, Product=45, SerialNumber=46
[ 1846.456217] usb 1-2: Product: omap5uevm
[ 1846.456222] usb 1-2: Manufacturer: Texas Instruments
[ 1846.456227] usb 1-2: SerialNumber: ****************
[ 1875.657810] usb 1-2: USB disconnect, device number 16

If we run fastboot right after usbboot we're able to see some variables

#~/sync3$ sudo fastboot getvar all
(bootloader) product: omap5uevm
(bootloader) cpu: 5432
(bootloader) cpurev: ES2.0
(bootloader) secure: GP
(bootloader) serialno: ****************
(bootloader) rom version: 2402
(bootloader) pmicrev: unknown
(bootloader) pmic otp rev: 52
all: 
Finished. Total time: 0.008s

That looks great !

Reflash eMMC with sync3flash

Clone sync3flash and compile it

git clone git@github.com:bigunclemax/sync3flash.git
cd sync3flash
cmake CMakelist.txt

Run it and start your APIM

@dma1384
Copy link

dma1384 commented Jul 26, 2024

Hi! I have an APIM that was bricked after an update and now only shows a black screen. MFG date 06/26/2017 ford escape HJ5T-14G370-KCB

I have set up a test bench as per https://github.com/EtoTen/stm32_can_sim and with everything set up my bricked APIM starts the backlight only after receiving the can bus messages. When I remove the can bus wires and supply 12V the backlight instead does nothing which shows I set the bench up correctly at least. I should also note my unit has a transistor populated between the 2 pads that you have circled for V31 and GND. My unit has 2 USB ports a grey and a black one. I have my linux computer connected to the black one. I can't get the watch -d lsusb suggestion to work nor can I get the sync3flash command to say anything other than waiting for device.

My order of operations: Plug in the usb into the black connector. Start the program. "Waiting for device" turn on the test bench. Backlight comes on a second later. short the 2 sides of the transistor V31 and GND with tweezers for a second observe nothing changes and I'm still stuck at waiting for device.

Do you know what I could be doing wrong?

UPDATE! I've soldered a male and female dupont wire to the pins on the board so it stays shorted during running the sync3flash. After running watch lsusb, I noticed while holding the two pins together I see for a second texas instruments OMAP5430 show up and then disappear. This looks like great news!

I'm pretty sure the reason it keeps disappearing after a couple seconds is because the canbus thing is sending the start message in a loop? Not sure. I need comments on if the code running in a loop from https://github.com/EtoTen/stm32_can_sim is safe to use or if I was just lucky.

I turned everything off. I ensured the two wires I soldered to V31 and GND were attached together. I started the sync3flash. I applied 12V to the test bench. I got past the waiting for device section and it uploaded the payload image correctly!

I got it into a Please Insert USB stick... screen. It's got interesting background images including a mustang logo, a shelby cobra, and a ford logo. Mine says version:306.

It's alive! now I just have to insert a usb stick with the appropriate update files. Watch me brick it again lol.

TLDR: If your unit has a transistor where the screenshot doesn't this will still work. make sure the pins are shorted together for the duration of the sync3flash operation. monitoring lsusb is a great way to diagnose if you're having usb issues or not going into the boot mode correctly.

Can you update the readme to make sure the exact times when the pins should be shorted are made more clear?

good afternoon. you're info helped my a lot. im at the point to install from usb update files and cant seem to find them? were you able to get them? if so they where can i find them?

@luckyPipewrench
Copy link

luckyPipewrench commented Jul 26, 2024

I've gotten to the REFORMAT screen also. I used Syn3 updater to make the usb into format mode. However, it never starts the update and continues to want a usb inserted. I've tried multiple usb drives as well. Anything else I need to do, has anyone had this problem?

Edit: it helps to plug in the mini usb to the back... Solved

I was able to make the short using a short piece of wire while in the vehicle. No soldering required. I second Cyanlabs!

Thanks for this guide!

@TheWonderSock
Copy link

Hi! I have an APIM that was bricked after an update and now only shows a black screen. MFG date 06/26/2017 ford escape HJ5T-14G370-KCB
...
Can you update the readme to make sure the exact times when the pins should be shorted are made more clear?

good afternoon. you're info helped my a lot. im at the point to install from usb update files and cant seem to find them? were you able to get them? if so they where can i find them?

Yeah just go over to cyanlabs website and go through their update to sync v3.4 manual process. It should give you a bunch of files you need to copy to a flash drive. This was all I did with USB drives. When I set up my test bench I included the my brand new $120 Ford motorcraft USB hub with the 2 USB type A plugs
https://www.amazon.ca/gp/aw/d/B0B25RQDH5?psc=1&ref=ppx_pop_mob_b_asin_title. I had to also wire 12V directly into the back of this is hub as per the test bench repo's recommendation. When I plugged in my USB drive I plugged it into this and not the adapter that came with my 2015 truck and not through a passive USB A to mini USB either.

@dma1384
Copy link

dma1384 commented Jul 27, 2024

Hi! I have an APIM that was bricked after an update and now only shows a black screen. MFG date 06/26/2017 ford escape HJ5T-14G370-KCB
...
Can you update the readme to make sure the exact times when the pins should be shorted are made more clear?

good afternoon. you're info helped my a lot. im at the point to install from usb update files and cant seem to find them? were you able to get them? if so they where can i find them?

Yeah just go over to cyanlabs website and go through their update to sync v3.4 manual process. It should give you a bunch of files you need to copy to a flash drive. This was all I did with USB drives. When I set up my test bench I included the my brand new $120 Ford motorcraft USB hub with the 2 USB type A plugs https://www.amazon.ca/gp/aw/d/B0B25RQDH5?psc=1&ref=ppx_pop_mob_b_asin_title. I had to also wire 12V directly into the back of this is hub as per the test bench repo's recommendation. When I plugged in my USB drive I plugged it into this and not the adapter that came with my 2015 truck and not through a passive USB A to mini USB either.

thank you got it to work. in cyanlabs updater i had to select the reformat option and that put the correct files on the drive which the apim accepted. i as well did the process while connected to truck.

@victorsowa12
Copy link

Hey guys! I am trying to do this directly in my car, however, I seem to be getting stuck at the 2nd stage each time. It looks to me like the APIM is turning off the USB (I am connected to the miniUSB on the back of the APIM) or the APIM itself is turning off. My process is to turn the ignition to on (engine off), start the script, short the pins(and leave them shorted), then turning the engine fully on. I can consistently get to the second stage, but fail each time. I can see that the LEDs for the USB hub in the center console turn off, followed by the script reporting the it received an unexpected response in the second stage. How long did yours stay in the second stage? Mine seems to be in it for 15+ seconds before it appears the USB/APIM is turned off. Any advice on getting the USB/APIM to stay on for the duration of the sync3flash script running?

Here is the output I see:

waiting for device...
reading ASIC ID
CHIP: 5430
rom minor version: 02
IDEN: 0000000000000000000000000000000000000000
MPKH: 0000000000000000000000000000000000000000000000000000000000000000
CRC0: 071a9a31
CRC1: 00000000
device is GP
sending 2ndstage to target...
waiting for 2ndstage response...
unexpected 2ndstage response

It is probably important to note that I am using WSL 2 with WSL USB Manager forwarding the OMAP USB device from windows to WSL 2 as soon as it shows up. Perhaps this forwarding is causing delays/issues, although the first stage read/write is working fine. I'll try running from a native Linux environment tomorrow and see if that changes anything, but in the meantime any advice is greatly appreciated!

@luckyPipewrench
Copy link

luckyPipewrench commented Jul 29, 2024

Hold the short, then turn ignition on, then run script. You don't need to fully crank the vehicle. I booted a windows laptop from a Linux USB drive to avoid VM issues.

@victorsowa12
Copy link

Alright, I've got Linux up and running, followed @luckyPipewrench's steps and that has helped me progress a little bit further into the script. I have gotten to the stage of uploading the MLO, however, it still appears that the APIM is turning off the miniUSB port before the script completes! I get to the part where the MLO is being uploaded and this seems to take a while (>30 seconds). Then in a second terminal window I see the Bus 001 Device 046: ID 0451:d011 Texas Instruments, Inc. OMAP5430 disappear and then the script quickly ends.

I ended up using dupont wires between the APIM and the APIM connector and from that I was able to determine that 12V is supplied, even when the miniUSB port goes down. I also unplugged almost every wire, leaving on 12V, GND, I-CAN HIGH, and I-CAN LOW connected (referenced this). I even tried to unplug the CAN lines after I got the OMAP to show up on USB so as to try and prevent some sort of CAN disable message from getting through. It seems to me that there is something on the APIM itself that is preventing the miniUSB from staying on for >30 seconds. Any ideas what it may be?

@m0nkeyc0de
Copy link

Are you in your car, and if yes is the engine turned on ? It may be a signal from the car which tells the APIM to go to sleep. This may happen after a little while when you remove your key for example.

Keeping the engine on is the best way I found to ensure power stays there during all the process (sorry planet Earth)

@victorsowa12
Copy link

victorsowa12 commented Aug 2, 2024

Yeah I have been trying this out in the car and I can measure 12V going into the APIM, even after the miniUSB disconnects. I have also tried to disconnect the CAN lines to the APIM once the file transfer has begun and the miniUSB still disconnects after about 30 seconds.

I was re-reading what bigunclemax wrote above and noticed this line:

Second board - VMCU. CPLD and microcontroller placed on it. This part is responsible for the CAN interface (since Omap5432 doesn't have it) and this board also acts as an external watchdog for the main CPU.

I think "this board also acts as an external watchdog for the main CPU." is likely the culprit that is turning off my main board and subsequently terminating my miniUSB connection mid flash.

So I am thinking I need to figure out one of these:

  1. how to disable or feed the watchdog (or fake an alive response from main board to second board) (would require figuring out where the UART lines are)
  2. how to continually power the main board bypassing the secondary board (would require figuring out the power layout)
  3. how to keep the second board awake for longer
  4. how to increase the speed of the MLO/QNX file transfers (although I think this is gated on the OMAP side not the USB port on my computer)

For option 3, I have tested changing the programming (as-built codes) of the APIM with Forscan and discovered that it appears the main board is powered on for 1.5-2 minutes continually. So perhaps I can try to continually change the programming, thus keeping the second board on and then allowing the full image flash of the main board to occur. Or perhaps there is a config in the APIM programming that can change the value of this watchdog timeout.

I'll give it a go this weekend. I'll probably also recompile the syn3flash to enable the USB tracing.

Also thanks for the responses! It is much appreciated!

@victorsowa12
Copy link

Alright so I confirmed that the miniUSB is disconnecting using the USB debug tracing. I was unsuccessful in getting the APIM to stay on using Forscan so I think the next step is to get a STM32 blue pill and try out the test bench set up. Perhaps the looping ignition messages will keep the APIM on for long enough. Otherwise it looks like I will just need to buy a new one... sigh.

For reference here is the output with the USB tracing:

sending 2ndstage to target...
usb_write _data = 0x7ffe1f473160 len (4)
usb_write _data = 0x56e9a1e99050 len (4)
usb_write _data = 0x56e9a1e96020 len (12333)
waiting for 2ndstage response...
usb_read _data = 0x7ffe1f473164 len (4)
[ usb read 4 fd = 5], fname=/dev/bus/usb/001/024
[ usb read 4 ] = 4, fname=/dev/bus/usb/001/024, Retry 0
usb_write _data = 0x7ffe1f473164 len (4)
usb_read _data = 0x7ffe1f473168 len (4)
[ usb read 4 fd = 5], fname=/dev/bus/usb/001/024
[ usb read 4 ] = 4, fname=/dev/bus/usb/001/024, Retry 0
sending image to target...size (22696-B/22-KB/0-MB)
usb_write _data = 0x56e9a2ab92a0 len (22696)
usb_write _data = 0x7ffe1f473164 len (4)
ERROR: n = -1, errno = 71 (Protocol error)
usb_read _data = 0x7ffe1f473168 len (4)
[ usb read 4 fd = 5], fname=/dev/bus/usb/001/024
[ usb read 4 ] = -1, fname=/dev/bus/usb/001/024, Retry 0
ERROR: n = -1, errno = 19 (No such device)
[ usb read 4 fd = 5], fname=/dev/bus/usb/001/024
[ usb read 4 ] = -1, fname=/dev/bus/usb/001/024, Retry 1
ERROR: n = -1, errno = 19 (No such device)
[ usb read 4 fd = 5], fname=/dev/bus/usb/001/024
[ usb read 4 ] = -1, fname=/dev/bus/usb/001/024, Retry 2
ERROR: n = -1, errno = 19 (No such device)
[ usb read 4 fd = 5], fname=/dev/bus/usb/001/024
[ usb read 4 ] = -1, fname=/dev/bus/usb/001/024, Retry 3
ERROR: n = -1, errno = 19 (No such device)
[ usb read 4 fd = 5], fname=/dev/bus/usb/001/024
[ usb read 4 ] = -1, fname=/dev/bus/usb/001/024, Retry 4
ERROR: n = -1, errno = 19 (No such device)
[ usb read 4 fd = 5], fname=/dev/bus/usb/001/024
[ usb read 4 ] = -1, fname=/dev/bus/usb/001/024, Retry 5
ERROR: n = -1, errno = 19 (No such device)
sending image to target...size (9279956-B/9062-KB/8-MB)
usb_write _data = 0x718090400010 len (9279956)
ERROR: n = -1, errno = 19 (No such device)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment