Skip to content

Instantly share code, notes, and snippets.

@bigunclemax
Last active September 3, 2026 18:34
Show Gist options
  • Select an option

  • Save bigunclemax/c566ecfc2f6d92e76e68446e46bdd944 to your computer and use it in GitHub Desktop.

Select an option

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)

@rPraml

rPraml commented Jan 19, 2025

Copy link
Copy Markdown

Great work. I have a bricked Sync 1.1. (I know this thread is for Sync 3)
But maybe there is someone who knows how to flash a Sync 1?
(I only found this forensic analysis)
Thanks, Roland

@MarcT

MarcT commented Sep 5, 2025

Copy link
Copy Markdown
  1. Disassembled the APIM, the daughter board is screwed into the chassis separately and the pins you need to jump are on the back side of this board. The daughter board also gets hot, so watch your hands later.
  2. Reconnected the 2 halves.
  3. Used Rufus to create a USB Linux boot drive (ubuntu) and also placed a folder on it with the sync3flash and 2 recovery files.
  4. Booted a laptop into Linux and setup the terminal window to run the command.
  5. Went out to the car connected the main APIM connector and the screen. Connected the USB wire from the USB on the board to the laptop.
  6. Ran the sync3flash command as outlined.
  7. Took a small metal tool I have for removing connectors which conveniently had 2 metal prongs at the right space and jumpered the pins as outlined on the MY18 version image (my sync is a MY20)
  8. Turned on the vehicle, not started.
    Had to repeat 6-8 twice as the first time it detected but did not load. Second time turning the car off, starting the commend, jumping, and turning the car on worked.
    When it installs it was SUPER fast, the 2 files are small enough that it should not take a lot of time.
    The only "issue" ended up being that after 30 seconds it did not reboot itself. Instead I powered off the car and turned it back on and got the messages up on the screen to install.
    I followed this up with turning the car off and unplugging everything, returning the APIM to its housing and then connecting everything back up using a Cyanlabs installer/upgrade.
    Currently waiting for it to install. But I got a powered black screen now that originally running the "install" message.
    From searching online this install is going to take anywhere from 30 mins to 3 hours. Considering I'm reinstalling the latest with maps it might be 2 or 3..

@zakirsheik

Copy link
Copy Markdown

I am trying to run sync3flash command as outlined by shorting the V31 and GND Pins and connecting the APIM in the car and getting this response, any ideas what is missing.

USB_Transfer/SyncMyMod/QNX-IFS-REFORMAT -m USB_Transfer/SyncMyMod/MLO
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

@oyster-source

Copy link
Copy Markdown

"Hi, I have a 2019 Ford F-150 SYNC 3 APIM that's bricked (black screen, backlight works, ForScan can communicate).
Board info:

Main board: Has OMAP5432, Samsung eMMC labeled "MMH1632V/16072D 16GB"
VMCU daughter board: Labeled "M3JAI18740"

I have photos of both boards but cannot locate the boot pads (V31/GND). I understand from the article that the labels in the reference images are annotations, not actual silkscreen.
Has anyone successfully flashed an M3JAI18740 board or similar MY19 F-150 APIM? Can you describe where you found the boot pads?

@MarcT

MarcT commented Feb 13, 2026

Copy link
Copy Markdown

"Hi, I have a 2019 Ford F-150 SYNC 3 APIM that's bricked (black screen, backlight works, ForScan can communicate). Board info:

Main board: Has OMAP5432, Samsung eMMC labeled "MMH1632V/16072D 16GB" VMCU daughter board: Labeled "M3JAI18740"

I have photos of both boards but cannot locate the boot pads (V31/GND). I understand from the article that the labels in the reference images are annotations, not actual silkscreen. Has anyone successfully flashed an M3JAI18740 board or similar MY19 F-150 APIM? Can you describe where you found the boot pads?

Below the image in the main post is a "USB boot MY18.5" link to a second image. This is the same board for MY20, and likely going to be the same for MY19, or what you believe is MY19.

@oyster-source

Copy link
Copy Markdown

Thanks for pointing me in the right direction MarcT!

@sergiuko83

Copy link
Copy Markdown

Thank you for this amazing work!
I recovered my MY23 APIM from brick. The QNX-IFS-REFORMAT file from the link did not work in my case but the ones from SyncRenovation (10.1MB) worked perfectly!

I soldered a switch to the APIM so I can safely work in the car with it, the second image from the post was a match for my HW.
The steps I did:

  1. with the car and SYNC off, flip the switch to short V31 to GND
  2. connect LINUX laptop to APIM miniUSB port directly
  3. in terminal type "sudo ./sync3flash -i QNX-IFS-REFORMAT -m MLO" -> you should see the text "waiting for device..."
  4. press button or turn ign key so that the SYNC3 is started and keep the hand on the switch ready to remove short from V31 and GND
  5. you will see the text in above logs and when you see "sending 2ndstage to target..." flip the switch to remove the short
  6. you will see the images being sent:
    sending image to target...size (22696-B/22-KB/0-MB)
    sending image to target...size (10118104-B/9880-KB/9-MB)
  7. wait 30 seconds for APIM to reboot
  8. SUCCESS! Image on the screen from SyncRenovation and message "Please insert USB stick..."

@runkster428

runkster428 commented Apr 29, 2026

Copy link
Copy Markdown

Mine appears to have a transistor/MOSFET in that location.
APIM short

@sergiuko83

Copy link
Copy Markdown

@runkster428 it makes no difference, follow the track. See also another case where the transistor is mounted, mine was also mounted: https://user-images.githubusercontent.com/29226906/277469793-540d2b61-f260-4c7c-a831-aae9fc8ce71a.jpg
You need to click on text "USB boot MY18.5 (Thanks to IgorStr. for this find)" in the description to see it

@kamikaonashi

Copy link
Copy Markdown

Thank you so much guys for helping with this! I managed to ressurect my unit. It was a aliexpress special lol, a 8gb us apim modded to 64gb emmc and nav for EU (2018 apim) and the screen is from a 2021 ford mustang. Cyanlabs interrogator read it as a 2018 pre my20 model and it got destroyed. I managed to bring it back to life with this! Be careful when shorting the pins on the plain mother/daughter boards, i accidently blew a fuse and i didnt figure it out for an hour. If youre on the plain motherboard. Put a piece of paper between motherboard and daughterboard for safety.

1000051048 1000051073

@ryanb-96

Copy link
Copy Markdown

I was going to attempt to do this on my APIM that I accidentally bricked while trying to do a sync 3.4 update. The truck is a 2019 and wasn't aware the APIM had been replaced at some point with a 2023 manufactured one. After looking through this thread I don't seem to have the same boards as anyone else and I don't seem to have the mini USB to plug into anywhere. If anyone here know if it's still possible given the hardware I have I'd greatly appreciate some direction. I've attached images of my boards incase that helps discern if this is possible or not.
00d8cf36-921e-4df7-bde6-95d63dad7f01
5126fcc9-17a7-43b5-81ce-b88f8ad76300
64133a56-1255-4d57-8176-35079f422e25
460847e3-7321-42c7-8676-c50511b46222
ace6a58e-c394-46ee-a339-196ed688fef9

@MarcT

MarcT commented Jul 11, 2026

Copy link
Copy Markdown

In the first message you missed a link, you have the 18.5 version. Look for “ USB boot MY18.5 (Thanks to IgorStr. for this find)”

@ryanb-96

Copy link
Copy Markdown

In the first message you missed a link, you have the 18.5 version. Look for “ USB boot MY18.5 (Thanks to IgorStr. for this find)”

I saw that, I just don’t see where to plug in the mini usb to push the files.

@MarcT

MarcT commented Jul 11, 2026

Copy link
Copy Markdown

In the first message you missed a link, you have the 18.5 version. Look for “ USB boot MY18.5 (Thanks to IgorStr. for this find)”

I saw that, I just don’t see where to plug in the mini usb to push the files.

It’s in your first photo, it’s the black adapter on the bottom that’s not the multipin.

@ryanb-96

Copy link
Copy Markdown

In the first message you missed a link, you have the 18.5 version. Look for “ USB boot MY18.5 (Thanks to IgorStr. for this find)”

I saw that, I just don’t see where to plug in the mini usb to push the files.

It’s in your first photo, it’s the black adapter on the bottom that’s not the multipin.

I see that now, and I appreciate your help. I'm going to be trying this in the next day or so and have pretty high hopes it will work out. One question I have is after I do all this I'll have to use the cyanlabs labs installer to push a sync version to it wont I? If I have to do that whough will it have the same issue as before? I was at sync 3.0 and then tried to push 3.4 and i guess it bricked it. I wasn't aware the 2019 truck had had a 2023 apim installed in it. Or am I missing the point of this and the flash package will revert it back to sync 3? I'm trying to focus on all the repair steps in this thread and I just want to make sure I get it right.

@MarcT

MarcT commented Jul 11, 2026

Copy link
Copy Markdown

When you install the software to allow recovery, what you’re actually installing is what’s called the universal reformat. If you had correctly jailbroken your MY20 device and then immediately installed the reformat you could have then done what you attempted without entering this state.
In the future, if you ever want to be able to take newer map updates, you’ll use the universal reformat, to enter reformat mode, and then use the cyanlabs tool to reformat your device using that new map version. I’ve done it a few times since I bricked my own device initially. You use the reformat and it puts you into the recovery state that you will be entering once you install the software again to get yourself in a good state.

@ryanb-96

Copy link
Copy Markdown

@MarcT i appreciate the insight it’s super helpful. Just to confirm after doing the reformat I just push the 3.4 update from cyan labs? This is possible since I do the universal reformat first and that keeps it from getting bricked again? Also, comparing my board to the 18.5 ones it still looks a bit different so I figured I would confirm with you about the location of the pins I’m supposed to short. I’ve got all the flash files downloaded and ready to go, just getting it all sorted out in my head before doing it all tomorrow.

@ryanb-96

Copy link
Copy Markdown

Managed to repair and update my apim with this process. Huge thanks to all the people here posting their process and notes.

@munaz-bfox

Copy link
Copy Markdown

@ryanb-96 which QNX-IFS-REFORMAT file did you use ?

@ryanb-96

ryanb-96 commented Aug 3, 2026

Copy link
Copy Markdown

I got everything through the link below.

https://disk.yandex.ru/d/9AfkdgpxtOh4rA

@munaz-bfox

Copy link
Copy Markdown

Mine is 2018 ecosport and apim manufactured in July 2023, i followed these step but on the laptop still showing waiting for the device.

@munaz-bfox

Copy link
Copy Markdown

Which version we need to install ? And reformat again or auto detect ?
image

@SachkovDI

SachkovDI commented Aug 27, 2026

Copy link
Copy Markdown

Please tell me what the issue might be. I’m using version 1.1. When I try to flash it, it breaks at the line “unexpected 2nd stage response”.
The board is slightly different from the two options presented. Could that be the problem? I’m doing it on a machine.

@BitwiseGuru

Copy link
Copy Markdown

I'm using version 1.1 and the flash consistently fails at unexpected 2nd stage response.

My board is a non-NAV APIM, 1 GB RAM / 8 GB eMMC.

For comparison, I tested two boards belonging to a friend (NAV variants, 2 GB RAM, 32 GB and 64 GB) and both flashed without any issue. On the hardware side, as shown in the attached picture, the non-NAV board is a noticeably more recent PCB revision with several layout and component optimizations compared to the working ones.

While debugging the SW execution of the USB boot sequence, I noticed it stalls right after the I/O initialization. This could be explained either by a schematic change on this newer revision, or simply by dead hardware.

Has anyone faced a similar failure on the non-NAV 1 GB RAM variant and managed to recover the ECU? Any help would be appreciated.
IMG_5179

@SachkovDI

SachkovDI commented Aug 30, 2026

Copy link
Copy Markdown

I’m having the same situation during flashing. The USB device is activated. But in the end, it ends up the same as yours.

Я использую версию 1.1, и флешка постоянно выходит из строя на unexpected 2nd stage response.

Моя плата — APIM без поддержки NAV, 1 ГБ ОЗУ / 8 ГБ eMMC.

Для сравнения я протестировал две платы, принадлежащие моему другу (варианты с навигацией, 2 ГБ ОЗУ, 32 ГБ и 64 ГБ), и обе прошились без проблем. Что касается аппаратной части, то, как видно на прикрепленном изображении, плата без навигации имеет заметно более новую версию печатной платы с оптимизацией компоновки и компонентов по сравнению с рабочими платами.

При отладке программного обеспечения последовательности загрузки с USB я заметил, что она зависает сразу после инициализации ввода-вывода. Это может быть связано либо с изменениями в схеме новой версии, либо просто с неисправностью оборудования.

Кто-нибудь сталкивался с подобной неисправностью на версии с 1 ГБ оперативной памяти без системы навигации и смог ли восстановить ЭБУ? Буду благодарен за любую помощь. IMG_5179

@SachkovDI

Copy link
Copy Markdown

Uploading IMG_20260828_212354.jpg…

@MarcT

MarcT commented Aug 30, 2026

Copy link
Copy Markdown

I'm using version 1.1 and the flash consistently fails at unexpected 2nd stage response.

My board is a non-NAV APIM, 1 GB RAM / 8 GB eMMC.

For comparison, I tested two boards belonging to a friend (NAV variants, 2 GB RAM, 32 GB and 64 GB) and both flashed without any issue. On the hardware side, as shown in the attached picture, the non-NAV board is a noticeably more recent PCB revision with several layout and component optimizations compared to the working ones.

While debugging the SW execution of the USB boot sequence, I noticed it stalls right after the I/O initialization. This could be explained either by a schematic change on this newer revision, or simply by dead hardware.

Has anyone faced a similar failure on the non-NAV 1 GB RAM variant and managed to recover the ECU? Any help would be appreciated.

Not sure I would say you have a "newer" one per se. Because its missing all the silk screening, I would hazard a guess that its a knockoff/recreation. I have never seen one from Ford without the silk screened numbers. They are serial numbers for manufacturing tracking in addition to the circuit trace locations/identification.

@BitwiseGuru

BitwiseGuru commented Aug 30, 2026

Copy link
Copy Markdown

I'm using version 1.1 and the flash consistently fails at unexpected 2nd stage response.
My board is a non-NAV APIM, 1 GB RAM / 8 GB eMMC.
For comparison, I tested two boards belonging to a friend (NAV variants, 2 GB RAM, 32 GB and 64 GB) and both flashed without any issue. On the hardware side, as shown in the attached picture, the non-NAV board is a noticeably more recent PCB revision with several layout and component optimizations compared to the working ones.
While debugging the SW execution of the USB boot sequence, I noticed it stalls right after the I/O initialization. This could be explained either by a schematic change on this newer revision, or simply by dead hardware.
Has anyone faced a similar failure on the non-NAV 1 GB RAM variant and managed to recover the ECU? Any help would be appreciated.

Not sure I would say you have a "newer" one per se. Because its missing all the silk screening, I would hazard a guess that its a knockoff/recreation. I have never seen one from Ford without the silk screened numbers. They are serial numbers for manufacturing tracking in addition to the circuit trace locations/identification.

I agree with you, it’s the first time I’ve seen a similar variant. But I can confirm it came from Ford, as I’m the first owner of the car and the APIM was never replaced.

After a few hours debugging the board today, I noticed systematic reset occurs right after the I2C exchanges to configure the PMIC. So I think my case is more likely a bricked HW. I’ll give it one more try if I can find a test point for UART3 (AG24 OMAP5432 ball) to get live logs before giving up.

@SachkovDI

SachkovDI commented Sep 3, 2026

Copy link
Copy Markdown
IMG_20260831_072739 I have the same problem with that chip. he doesn't want to write. you couldn't reprogram the story?

Я использую версию 1.1, и прошивка постоянно вылетает на unexpected 2nd stage response. У меня плата APIM без поддержки NAV, 1 ГБ ОЗУ / 8 ГБ eMMC. Для сравнения я протестировал две платы, принадлежащие моему другу (варианты с поддержкой NAV, 2 ГБ ОЗУ, 32 ГБ и 64 ГБ), и обе прошились без проблем. Что касается аппаратной части, то, как видно на прикрепленном изображении, плата без системы навигации представляет собой заметно более новую версию печатной платы с оптимизацией разводки и компонентов по сравнению с рабочими платами. При отладке программного обеспечения последовательности загрузки через USB я заметил, что она зависает сразу после инициализации ввода-вывода. Это может быть связано либо с изменениями в схеме этой более новой версии, либо просто с неисправностью оборудования. Кто-нибудь сталкивался с подобной проблемой на плате с 1 ГБ ОЗУ без системы навигации и смог восстановить ЭБУ? Буду признателен за любую помощь.

Не уверен, что у вас есть «более новая» модель как таковая. Поскольку на ней нет шелкографии, я бы рискнул предположить, что это подделка/копия. Я никогда не видел у Ford моделей без шелкографии с серийными номерами. Это серийные номера для отслеживания производства в дополнение к расположению/идентификации дорожек на печатной плате.

Я с вами согласен, я впервые вижу такой вариант. Но я могу подтвердить, что он от Ford, потому что я первый владелец этой машины, и APIM мне никто не менял.

Сегодня, после нескольких часов отладки платы, я заметил, что систематический сброс происходит сразу после обмена данными по протоколу I2C для настройки PMIC. Так что, скорее всего, проблема в аппаратной части. Я попробую еще раз, если смогу найти тестовую точку для UART3 (AG24 OMAP5432), чтобы получить логи в реальном времени, прежде чем сдаться.

@BitwiseGuru

Copy link
Copy Markdown

I have the same problem with that chip. he doesn't want to write. you couldn't reprogram the story?

I tried, but unfortunately had no success flashing my board with the current version of the flasher. In my free time, I’ve been looking into the board schematic, since no schematic is publicly available (which is understandable 😄), at least to get a better idea of the HW health and hopefully reach a conclusion.

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