Actisafety A600 OBD2 HU Display

[darkspr1te]

Mentioned Elsewhere is my moan about this device and the firmware biting me again (see my thread on om-126 obd reader being bricked with F/W )

Anyhoo, I have already made major Progress with the device and even have fixed the original one as well as having working code on the device.

These are my adventures to boldly go where no operator should , deep inside.

First is the Chip list

CPU: "Original" from supplier CSk32F103CB, currently STM32F103C8 sourced from black pill with original stm32 (as in it passes the test code and is not flagged gdm or csk) 8Mhz xtal+ RTC xtal
SPI Flash: 128Mbit QUAD SPI (see STM app note on SPI -> ram implementation , link to be added when i find it again)
    SPI 1 ( PA4,5,6,7)
CAN: NXP TAJ 4010 https://www.nxp.com/docs/en/data-sheet/TJA1040.pdf
    PB9 - TX
    PB8 - RX
    PA15 - STB/Enable
K-Line via transistor

LCD x2 : ILI9488 ->
 D-IN  - PB15
 D-CLK - PB13
 D-CS  LCD1- PB12 (left Screen)
 D-CS LCD2 - PB3 (right Screen)
 D-RST - PA8
 D- DC/RS - PB14
 D- LCD PWR - PB2
 D-BL - PB7

Speaker PB6 (pwm pin)
Button Left PB4 - Input Pull Low reset, pulled high by button
Button Right PB5
Button Middle PA0

Light Sensor ADC  PB1

GPS:
ATGM332d - gps has fast start and button cell backup
Connected to CPU Via
 TX - PA9 - UART 1
 RX - PA10 - UART 1

Unpopulated board castled adapter
PA2 TX - UART 2
PA3 RX  - UART 2
Board Power:
2 x AAD 7533H
1 x AAD 7550H


There's still more pins to figure out like the ADC for input voltage,


Attached it main code and the bootloader, the CPU was protected at RDP 2 , no flash and no debug but fell pray to the DFU over flow bug where you keep asking the DEV_INFO param and it keeps reading the flash instead :-)

Oh the firmware is on http://www.actisafety.com/ , if the file does not down load from within the app then you can just edit the ini file and add .cn to the .com and it will work.
to download manual goto the japan site and the allow download of the bin file and also st-dfu demo to upload it to the device. Handy as they used ST code with known bugs in a clone device with hardened security against the IRQ vector overflow and the single read sploit it still falls victim to bugged firmware/software :-P

more to come,

darkspr1te
p.s i didnt attached the full .dfu firmware file off 13mb , it's just logo's and fonts but link above you can manually get it. firmware file has no encryption but device will no longer boot if patched file is used, i've yet to figure that crc out from usb bootloader

[darkspr1te]

Bootloader and flash backup from A500 +

CPU:CKS32F103C8

[kamyu]

I am also suffering from firmward update of ActiSafety A500.

I got the device from 2021. I just want to upgrade its firmware for fun, however, after flashing the firmware, it only remains in the DFU mode and does not start anymore.

I disassembly it and found out it uses CSK32F103CB.

Currently, I would like to use backup bootloaderA500 to flash it again.

Could you please teach me how to use your txt file to generate a DFU file for firmware flashing?

Thank you.

[darkspr1te]

You will need external hardware to flash the bootloader, it's a Binary file that can be flashed via st-flash or similar SWD app (openocd example) , examples of swd based adapters are devices like st-link v2/3 , picoswd, picogbd , arduino with swd firmware etc.
the file a500_bootloader-.txt just need to be renamed to a500_bootloader.bin and then flashed.


darkspr1te

[logger100]

I was trying to revert to an older firmware in Actisafety A401. The latest (2023) firmware could not connect with my car (i suppose a bug in it - I tried 3 brand new devices and none of them worked). I thought it is as simple as dumping firmware from older (2022) device using DfuSe and then writing it to a target device. So I dumped it, the dfu file was 16MB (16 777 525 bytes). On the A401 screen it reads "Flash Erase 16777216 Bytes". After the update it restarted in DFU mode (excerpt one thing: there is "Boot from App" instead of "Boot from key" at the top) and does not boot up. It is still possible to start it in DFU mode ("Boot from key") with "OK" button pressed. Seems to me like on the startup the bootloader can not start the firmware and gets stuck in DFU mode with "Boot from App" announcement.

This happened, before I found there are updater apps on Actisafety website.
Now I see DFU files for A401, used by updaters, are below 4MB. Flashing with these files does not help.

Is it bricked or there is some way to repair it without external hardware?

[darkspr1te]

Can you share the file you dumped,
I think it's because you dumped dfu bootloader+firmware and then wrote that to the firmware side.
 

[logger100]

Excuse me I'm replying late. My e-mail notifications were not turned on.

In the meantime I've got ST-LINK V2, just in case.

File is too big for an attachment,
you can download the dump here: https://filebin.net/sppxfplwomi61zmn

[darkspr1te]

Sadly the file you posted only contains the dfuse header and the same repeating data, what app did you use to dump the firmware ? did you patch libusb to allow for larger buffer (required to fully dump the firmware)


darkspr1te

[logger100]

Sadly the file you posted only contains the dfuse header and the same repeating data, what app did you use to dump the firmware ? did you patch libusb to allow for larger buffer (required to fully dump the firmware)


darkspr1te

It was over two weeks ago but I think I can recall what I did with help of browser's history.
I downloaded "V60-Latest-Software-20220901.zip" here:

https://www.vjoychina.com/download/

It contains DfuSeDemo.exe and DLLs in portable manner. I used this one to dump the firmware.
Now, just after two weeks, this file is not on the list, seems like the website was modified but I have a link to it from the history of my browser:

https://www.vjoychina.com/wp-content/uploads/2022/09/V60-Latest-Software-20220901.zip

I also downloaded "V63-A450-Updated-Software-20220901.zip" (didn't use it, because it contains the same DfuSe files) and Hawk-Hud-Software-and-Driver.zip (it contains DfuSe_Demo_V3.0.6_Setup.exe installer, which installs the same DfuSe files, also not linked anymore, the link is https://www.vjoychina.com/wp-content/uploads/2021/10/Hawk-Hud-Software-and-Driver.zip).

I did not make any patching.

I noticed some weird thing. I tried to open different dumps with Wordpad to preview its contents but every dumped file was different. It was different size (a couple of bytes) [edit: dumped files are the same 16 777 525 bytes size but their structure is different, as reported by CDcheck app] and at the beginning of each file I could see a random URL of a website I previously visited on Firefox. I thought  there was some interruption of Firefox during dump creation but now I can't see those URLs while opening these dumps, so I assume this happens during opening of a dump in Wordpad.

[darkspr1te]

When trying to dump DFU devices you will get the first group of bytes fine but then the second group will lock up and be random due to the dfu checking for the read lock bit, the only way to dump this correctly is using linux and a patched libusb which reads beyond the buffer in the DFU chips and is able to read the bootloader in one read request.
the mint linux i used has dfu-util so i just used that plus my patched libusb .

[logger100]

Do I need a proper dump from a working A401 to repair my bricked A401 and use linux for that? Is linux mint live CD enough?
Or maybe DFU update file from manufacturer  would be enough, or this DFU file + bootloader dump?

I do not really need a dump with 2022 firmware , because on July I contacted Actisafety support. They sent me 4MB DFU file with 2022 english  firmware, which works for sure with my car but they also suggested, that the problem with A401 with 2023 firmware not working with my car is not a matter of firmware, but car make setting. I focused on manual setting of OBD2 protocol, but I forgot that in the A401 with 2022 firmware I also (prior to that) changed car make to "Skoda", which I did not do while testing the  A401s with 2023 firmware (I only changed OBD2 protocol setting, I haven't supposed car make settings can influence connection ability). They said car make setting solves car make specific problems.
Now I have one  A401 working and connecting with my car properly, it's 2022 firmware. It has OBD2 protocol setting changed manually from AUTO to some 7e0 or so and car make setting set to "Skoda". I have to change car make setting to other makes to see, whether  it will cause the display not connecting with the car. I suppose 2023 firmware will work and no updates are necessary, only  car make setting needs to be changed but I am careful and do not make firmware update to check it.


The second A401 I have is the bricked one. Recently I bought another A401, but when it arrived it turned out. it's some old stock, old firmware, different and old hardware, poor display - no USB port - version, so I need to buy another one or repair the bricked one to have a second one working.

[darkspr1te]

Yeah, there are some fake units out there using those picture and they dont actually do anything even on a basic OBD2 standard.
I have got the unit to work on my OBD2 emulator, every value it supports but not my car (2006 rav4 JDM) ,


Dump wise , yes you need to dump a working real A401 to fix the non working one maybe, first try the factory DFU file, if it boots then great, if not then a ubuntu install is the way,


To make some thing clear about how this DFU hack work is this,
in LIBUSB linux it has a usb frame buffer limit of 0x100 (aka 256 dec) so when the dfu app reads the first request of flash "then" it checks for flash rights but that first frame of DFUSE data is already in the buffer and another DFUSE request get you that data, after that it's locked up, so the trick is to increase the request value buffer size to past the bootloader so your one and only request is supplied with the bootloader data(0x6000) , this dump is then reversed to find the crypt key (yes some of the dfu files are plain text, some are not)
One thing to be clear about DFU files based on the STM standard is they include eeprom section , without going into a mass tutorial found elsewhere in my posts the dfu work like so, 0x0 to 0x(max flash) in the DFU header will write to flash, then all the data that follows will write to the i2c/spi eeprom,
anyway once you have the crypt key you then depack the dfu file, patch the reset vector to goto a small 8 byte patch to dump the full flash to uart,


now when you wrote your 'dumped' dfu file you may have over-written eeprom values with junk(you dfu dump has header, i read this much, you write back that much, junk or not)  so writing the original factory dfu may not write to that area and not fix the issue (eeproms store stuff like model number/version/settings etc)




i do have some backlogged dfu upgrades so will pull that storage and check but the updates only goto this url
http://www.actisafety.com/dfu/release/last.json


i would love to be able to browse this url and see what else is there (pre-release , bootloaders etc) but i dont have time to debug everything




darkspr1te

[logger100]

Miraculously I managed to repair my A401. I used 221111 firmware from the support (I attach it here) + their dedicated update tool:
http://actisafety.com/market/firmware/Setup_en.zip
First I run the update tool to automatically upgrade with the latest firmware version.
For some reason, the latest firmware does not work - makes my A401s bricked.
So I closed the update tool and I entered "C:\Program Files\Actisafety\data" folder, where the latest firmware file (A401-en-20231205.dfu) was downloaded and stored during update.
I copied it's entire name (A401-en-20231205.dfu) and deleted it. I took A401-ENG-QC-221111.dfu file and renamed it to A401-en-20231205.dfu, then moved to the "C:\Program Files\Actisafety\data" folder. Then I restarted update tool and I made an upgrade again. The update tool used local  A401-en-20231205.dfu file (which in fact was A401-ENG-QC-221111.dfu file) instead of downloading it again. After the upgrade the A401 restarts in test mode, where several tests must be performed to make it work (light sensor test - light it with a flashlight, buttons test - press buttons, OBD2 connection test - connect to a compatible car).

And in the end - it was not the "Comd search" setting that makes my car work with it, nor it was car make setting.
I discovered it's "request rate" setting. By default it's set to 50 ms. To connect A401 with my car, it must be at least 55 ms.