When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
I've written a function to do the date conversion. Compiling it in Debian using the SH4 cross-compiler and then REing back in Ghidra the function comes out to roughly around 700 to 750 bytes in SH4 Assembly. Don't know if you'd like to try slotting it in?!
Cool... I haven't dug deeply into the code looking for space, but 700 bytes sounds like a lot to try squeezing in there without major changes. :-/ One possibility is compressing the code... I haven't tried, but I think the comment in the dumpnavi code "Added optional compress to update large uncompressed files that normally wouldnt fit." means it might be possible to increase the size of SSD_Server.dll then compress it to fit in the space of the current uncompressed file (assuming it's not already compressed). I believe the 09Touch.bin files run from RAM (not XIP), so it should be OK to compress.
But honestly, I'm working on a few other projects that are a bit higher priority, so I probably won't jump into this right now.
SMH when Honda/ Acura enthusiast figure out a way to get the clock working again, kudo to all the efforts and input guy. Meanwhile Acura asking if you are interested to buy the new Integra, this tell you something about the company customer service.
Let me know if anyone attempts this, or have any questions on the process... and I'm happy to help and/or double-check your file if you're not comfortable modifying the file.
DogP
Worked for me on my 2007 TL!!
I have the White 2021 navi disc. 4.K0
Would you buy an update dvd if it also fixed the problem?
Absolutely not. This is a core function that they should be responsible for fixing themselves, even if it means sending DVDs to dealerships for a recall.
Worked for me on my 2007 TL!!
I have the White 2021 navi disc. 4.K0
Nice! That's really great to know it still works on 2021, so the same fix likely works on every version for our TL.
BTW, I saw two other Type-S-es (not sure how to make Type-S plural - should be in an FAQ on this site! :-P ) coming home from work today... I wanted to yell out the window "want me to fix your dash clock!?!" ;-)
Nice! That's really great to know it still works on 2021, so the same fix likely works on every version for our TL.
BTW, I saw two other Type-S-es (not sure how to make Type-S plural - should be in an FAQ on this site! :-P ) coming home from work today... I wanted to yell out the window "want me to fix your dash clock!?!" ;-)
DogP
“Hi, I’ve been trying to reach you about your car’s extended warranty clock.”
Has Acura fixed the Clock issue? Tried to manually change the clock time in the Troung TL last week and was able to. When manually changing it in the past it was unhighlighted and wouldnt allow it.
Anyone one else able to now change the clock time manually via Navi screen?
Has Acura fixed the Clock issue? Tried to manually change the clock time in the Troung TL last week and was able to. When manually changing it in the past it was unhighlighted and wouldnt allow it.
Anyone one else able to now change the clock time manually via Navi screen?
They have not, and if you've got a Type-S and navi, you cannot manually set the clock. You basically have to disconnect the battery at 12:45pm, then reconnect exactly at 1pm so that the time is accurate. Or wait until August when it'll start working again (supposedly).
Yeah, I doubt they'd be willing to put in the work and send everyone free DVD updates. I still get e-mails from them asking me to buy the latest DVD.
The latest DVD will NOT solve the clock issue. I have the 2021 DVD and it hasn't done a damn thing except give me a slightly better Nav system. I'll wait till August.
.
The latest DVD will NOT solve the clock issue. I have the 2021 DVD and it hasn't done a damn thing except give me a slightly better Nav system. I'll wait till August.
.
I meant if they patched the latest DVD like DogP did, not used the same image that's currently available from Acura.
They have not, and if you've got a Type-S and navi, you cannot manually set the clock. You basically have to disconnect the battery at 12:45pm, then reconnect exactly at 1pm so that the time is accurate. Or wait until August when it'll start working again (supposedly).
Last year I was having the same issue not being able to adjust my clock.
See how the "adjust time" are able to be pressed? last year those were faded out and didnt work. My time is still working as its correct for Pacific Standard Time. I can also adjust it with tthe adjust time buttons.
Mabe Acura fixed it? Someone should drain the power in thier car and see if Acura uploads an update?
My buttons weren't greyed out for me back in March when I tried adjusting the time manually, but it never actually saved the setting. Change the time, return, clock never changed. I did read that the time is now working on 04-06 TLs.
Last year I was having the same issue not being able to adjust my clock.
See how the "adjust time" are able to be pressed? last year those were faded out and didnt work. My time is still working as its correct for Pacific Standard Time. I can also adjust it with tthe adjust time buttons.
Mabe Acura fixed it? Someone should drain the power in thier car and see if Acura uploads an update?
The 04-06 has fixed itself (as the thread title suggests). The 07-08 will fix itself in August. Both are just due to how GPS time shows up in the system after the rollover... Honda/Acura didn't do anything, and won't be "uploading" any sort of update.
Cool... I haven't dug deeply into the code looking for space, but 700 bytes sounds like a lot to try squeezing in there without major changes. :-/ One possibility is compressing the code... I haven't tried, but I think the comment in the dumpnavi code "Added optional compress to update large uncompressed files that normally wouldnt fit." means it might be possible to increase the size of SSD_Server.dll then compress it to fit in the space of the current uncompressed file (assuming it's not already compressed). I believe the 09Touch.bin files run from RAM (not XIP), so it should be OK to compress.
But honestly, I'm working on a few other projects that are a bit higher priority, so I probably won't jump into this right now.
void main(void)
{
unsigned short year = 2002;
unsigned short month = 1;
unsigned short day = 1;
signed short days = 7168;
unsigned char i;
unsigned char month_of_year = 0;
for (i = 0; i < month - 1; i++)
{
days += month_days1;
if (year % 4 == 0 && i == 1) days++;
}
days += day;
while (days > 0)
{
if (days > 365)
{
days -= 365;
if (year % 4 == 0) days--;
if (days > 0) year = year + 1;
}
if (days > 0 && days <= 366)
{
day = days;
days -= month_days1[month_of_year];
if (year % 4 == 0 && month_of_year == 1) days--;
if (days > 0) month_of_year++;
if (month_of_year > 11)
{
year = year + 1;
month_of_year = 0;
}
}
}
month = month_of_year + 1;
}
I had a look at if I could slot these in somewhere, but unfortunately the (nearly) 400 bytes that looks to be available at the beginning of the file look to be created by the dumpnavi tool itself in order to provide the correct structure for the DLL. If you search for the starting bytes of the DLL back in 09Touch.bin you'll find that the space is missing. I like your idea of adding the extra bytes in the SSD_Server.dll and then compressing it down again. Obviously that creates even more risk of bricks if it screws up in testing, so might need to look into possible recovery methods? The method could also be trialled on the 09Touch2.bin side on the DiagFunction.dll (which would need to change anyway to get the date working on the settings screens), as that's probably less risky for bricking.
I'd like to take a look at how to remove the Nag Screen. But I've already hit a dead end. I can easily find the Nag Screen text, but working out where it gets loaded is a whole different story.
I have a request - does anyone have an original copy of the BNHH401A.bin (or navi.exe) from the v3.50 orange DVD (I.E. from before "AD"s nag fix was added for that version)? I got the patched version from https://acurazine.com/forums/3g-tl-a...-937391/page3/ , but the unpatched version wasn't provided. This will allow me to see what patching was applied which will hopefully put me on the right track for patching HMIManager.dll on the modern discs.
I'd like to take a look at how to remove the Nag Screen. But I've already hit a dead end. I can easily find the Nag Screen text, but working out where it gets loaded is a whole different story.
I have a request - does anyone have an original copy of the BNHH401A.bin (or navi.exe) from the v3.50 orange DVD (I.E. from before "AD"s nag fix was added for that version)? I got the patched version from https://acurazine.com/forums/3g-tl-a...-937391/page3/ , but the unpatched version wasn't provided. This will allow me to see what patching was applied which will hopefully put me on the right track for patching HMIManager.dll on the modern discs.
I know I have this in my house, but for the life of me cannot find it.
unfortunately the (nearly) 400 bytes that looks to be available at the beginning of the file look to be created by the dumpnavi tool itself in order to provide the correct structure for the DLL. If you search for the starting bytes of the DLL back in 09Touch.bin you'll find that the space is missing. I like your idea of adding the extra bytes in the SSD_Server.dll and then compressing it down again. Obviously that creates even more risk of bricks if it screws up in testing, so might need to look into possible recovery methods? The method could also be trialled on the 09Touch2.bin side on the DiagFunction.dll (which would need to change anyway to get the date working on the settings screens), as that's probably less risky for bricking.
150 bytes sounds much better! That makes sense that the empty space was put there during extraction (decompression?), though I guess that makes it a good candidate location to put the code and then compress, since those memory locations are already logically present (can drop the code in there, and verify that it looks correct in Ghidra). It does look like the SSD_Server.dll is already compressed according to the "list" command in dumpnavi.
Originally Posted by dsclee1
This will allow me to see what patching was applied which will hopefully put me on the right track for patching HMIManager.dll on the modern discs.
I don't have the original file, though I'm not sure it'll be much help. I think the interface, and therefore nag screen, is handled differently between the two systems. In ours (or at least the TL), the "nag" is referred to as "disclaimer". And my best guess to how it gets called is through mmicore.exe opening UI_MAIN_CE.skn on the F_START form. Unfortunately, the skin file looks to be some custom binary format, so I'm kinda afraid to mess with it (if the entire UI is based on the skin and I screw up the skin, I could no longer have a way to get into diagnostic mode to reflash :-/). I don't think the 04-06 used the skin stuff at all.
I'd really like to get a way to run programs (locally or remotely), so if something goes wrong, I can just reboot. I'll be disassembling my navi unit again to put the GPS receiver back inside, so while I'm in there, I plan to take a closer look at the hardware to see what options we have for preventing and/or fixing a bricked unit though.
150 bytes sounds much better! That makes sense that the empty space was put there during extraction (decompression?), though I guess that makes it a good candidate location to put the code and then compress, since those memory locations are already logically present (can drop the code in there, and verify that it looks correct in Ghidra). It does look like the SSD_Server.dll is already compressed according to the "list" command in dumpnavi.
I don't have the original file, though I'm not sure it'll be much help. I think the interface, and therefore nag screen, is handled differently between the two systems. In ours (or at least the TL), the "nag" is referred to as "disclaimer". And my best guess to how it gets called is through mmicore.exe opening UI_MAIN_CE.skn on the F_START form. Unfortunately, the skin file looks to be some custom binary format, so I'm kinda afraid to mess with it (if the entire UI is based on the skin and I screw up the skin, I could no longer have a way to get into diagnostic mode to reflash :-/). I don't think the 04-06 used the skin stuff at all.
I'd really like to get a way to run programs (locally or remotely), so if something goes wrong, I can just reboot. I'll be disassembling my navi unit again to put the GPS receiver back inside, so while I'm in there, I plan to take a closer look at the hardware to see what options we have for preventing and/or fixing a bricked unit though.
DogP
Thanks for sharing. It would be ideal if some kind of reflashing method could be discovered.
I can see how you got to the UI_MAIN_CE.skn being a likely culprit, especially with the usage text "Usage: mmicore <StartForm> <myui.skn>\nArguments:\n\t<StartForm> - Specifies the name of the form to be displayed at startup.\n\t<myui.skn> - Identifies the binary skin (.skn) file.". I think if you can get a change on that working then that would skip the nag screen altogether? I'm still going to stick with exploring the HMIManager.dll for now, as there's some interesting code that references the text "DisclaimerOff", so I'm hoping if I trace it back far enough I can find what calls it... The aim being not to remove the nag screen, but to bypass the need to press "OK".
A small bit of the function:
switch(param_1) {
case 0:
return L"UnKnown";
case 1:
return L"Start";
case 2:
return L"PIN";
case 3:
return L"Boot";
case 4:
return L"SysError";
case 5:
return L"DoorOpen";
case 6:
return L"DisclaimerOff";
case 7:
return L"ErrOff";
case 8:
return L"ScreenOff";
case 9:
return L"PINOff";
case 10:
return L"Lock";
I had gone down that path as well... just a guess, but I'm thinking that function in particular might be the output string for logging output. There's a few logs called out in the registry (TelmLog being the only one enabled, which I think is the one that's output to the PC Card when enabled in diagnostic mode). There's also HMI_EventLog (maybe that's these strings?), UserLog, EventLog, OperationLog, StateLog, and TimerLog... all of which look to be disabled. I've enabled logging in diagnostic mode, and only got telemetry related logs to the card.
But I agree, it seems something in the function that calls that should be doing something related to the things called out in there. But the program flow wasn't clear to me, since all the functions in and out are basically dead ends (not sure if this is referenced externally, from a callback, etc... and it's not clear what code actually executes from some of the other functions).
Here are a few notes that I had made on that though... maybe they'll be helpful, or maybe not:
FUN_030f399c has the same number of cases (0x00 - 0x20), though Ghidra doesn't find any incoming calls for that function (of course may be at a different location on yours). The code isn't particularly interesting either. :-/
Code:
case 6:
(**(code **)(*param_1 + 0x8c))(param_1);
return 1;
There's also a function UndefinedFunction_03095108 (again, maybe different location on yours), which calls the function that returns DisclaimerOff. This is just a chunk of code in the binary, but not detected as a real function by Ghidra for whatever reason.
One other related thing I sorta looked into... when you don't touch anything for 30 seconds, the screen turns off (on the TL at least). So I thought there may be a check for if (x<30) or similar... that same function actually has a check for <29 and <30, but looking at the functions called to fill those variables doesn't look to be related to a timer.
Definitely interested to hear if you make progress!
Once again thanks for the info. On the Civic side I can trace the switch statement with the "case 6" back to an earlier function that does this:
switch(param_1) {
case 0x40002:
return 1;
case 0x40003:
return 4;
case 0x40004:
return 0x1a;
case 0x40005:
return 20; case 0x40006:
return 6;
case 0x40007:
return 0x11;
...
and there's another interesting function which has case statements for all those options which calls several different functions.
undefined **ppuVar1;
int iVar2;
code *pcVar3;
undefined4 uVar4;
uVar4 = 0x40010;
if (0x40010 < param_1) {
switch(param_1) {
case 0x40011:
goto switchD_02dc7682_caseD_40011;
case 0x40012:
ppuVar1 = (undefined **)FUN_02e1e6a8();
if (ppuVar1 != (undefined **)0x0) {
ppuVar1 = FUN_02dcb100(ppuVar1,1,param_2);
FUN_02e1a93c((int)ppuVar1,0x40012);
return ppuVar1;
}
FUN_02e1a93c(0,0x40012);
return (undefined **)0x0;
case 0x40013:
ppuVar1 = (undefined **)FUN_02e1e6a8();
if (ppuVar1 != (undefined **)0x0) {
ppuVar1 = FUN_02dccc4c(ppuVar1,1,param_2);
FUN_02e1a93c((int)ppuVar1,0x40013);
return ppuVar1;
}
This will probably still end up being a dead end, as I completely agree that the "DisclaimerOff" string is just for a log. So the code I've found could still be related to the logging, but I'll see where I get to.
Your note about the screen turning off is interesting... case 8 is the text "ScreenOff", so if I can track that back and find something that it looks like a function that does a 30 second wait time then I'll know we're on the right track.
As a side note, as we're now talking about the nag screen and not the clock, maybe we should move this over to a new thread!
A few interesting things... I disassembled the Navi unit a bit more this weekend. The main processing part is the module with the PCMCIA slot. On that board, you can see the CPU, flash, SRAM, DRAM, and various other chips. So... worst case unbricking would be desoldering one or both of the flash chips (LH28F128BFHED) and reprogramming them. Looks like TSOP48, so not terrible, but the conformal and resin coatings will certainly make things a bit more challenging (the first time at least).
I noticed a few things... there are two unused FFC connectors on that module - CB2 (total guess, but looks like a 24-bit RGB LCD output to me), and CB3 (not sure, didn't take a good look at it). Similarly, I noticed the large board has an unused connector on the bottom (CB1001), which also has a hole in the bottom of the metal to access, though covered by a sticker. Maybe it's for factory test/program/etc, debug connection, or maybe expansion for some other model. It looks to have some serial data (TTL binary data at 38400, 8E1 maybe?), though I didn't trace where it goes to.
Most interestingly, I found a debug UART at test points TP16 and TP17 (3.3V level, 38400, 8N1). At power-up, you're greeted by this on TP17:
Code:
BootTime= 701 (ms) Jumping to image
BootTime= 933 (ms) +OEMInit
BootTime= 937 (ms) -OEMInit
BootTime= 1240 (ms) IOCTL_HAL_POSTINIT
BootTime= 1280 (ms) IOCTL_HAL_GET_HIVE_CLEAN_FLAG
BootTime= 1336 (ms) IOCTL_HAL_GET_HIVE_CLEAN_FLAG
BootTime= 1478 (ms) IOCTL_HAL_GET_RANDOM_SEED
[Launcher] Time = 1605(ms) LAUNCHER START!!!
[Launcher] Time = 1613(ms) Initileze GRITT.
[Launcher] Time = 1661(ms) Wait for Gwes Initilize.
[Launcher] Time = 3318(ms) Show Opening Bitmap.
[SYSMNG_DEBUGINFORMATION]0xf86bec13
///// ALPINE Navigation System / SPY Version 1.00
Oddly, this goes to the main board, but seemingly just to a buffer and nowhere else (unless I just didn't find the final endpoint). The main board also has a buffer driving TP16, so you need to disconnect that (lift pin 12 of IC1033), in which case you can actually access a menu!
Press enter and you'll see a prompt. Type "help" and it outputs a list of "channels". You can enter a channel with either "channel" or "mode". And you can see a list of running processes with "proclist". Inside of each channel you can type help again to see the specific commands available (if any) for that channel.
Code:
#@>help
Entry Channel.
PerformanceMoni : Description Nothing.
SSDServer : SSD Output Current Status
MPDIAG : MPDiag Mode
VPFDiag : VPF Diag
Serial : Serial Mode
Model : Model Mode
Antitheft : Antitheft Mode
Normal : Normal Mode
PasSet : Pas Set
PasClear : Pas Clear
BusMon : Bus Monitor
SysMicomTest : System Micom Test
TchChk : Touch Check
ModemChk : ModemChk Mode
ErHClr : Error History Clear
ErrHis : Print Error History
KeyIn : KeyIn
ATAPI_DVD : ATAPI_DVD
Coverage : Coverage Mode
Dbg1Mon : Vp logging mode
DemoSim : Vp simulation mode
GpsMon : Gps monitor mode
GyroS : gyro calibration mode
MPDiag : MP diag mode
ACFunc : ACFunc SpyChannel
HMI : HMIManager SpyChannel
SnapShot : Snapshot operation.
Telematics : Telematics debug channel.
PhoneBook : PhoneBook debug channel.
Active Channel Contents.
#@>proclist
NK.EXE
filesys.exe
shell.exe
device.exe
gwes.exe
aersvc.exe
MsgDeliver.EXE
SystemManager.EXE
DM_MONITOR_Launcher.exe
MonitorProcess.exe
DiagProcess.exe
MMICore.exe
AudioProcess.exe
VoiceControl.exe
AirConProcess.exe
SRControl.exe
Telematics.exe
#@>mode performancemoni
change channel to [PerformanceMoni].
process?
0xe1 nk.exe
0xe2 filesys.exe
0xe4 shell.exe
0xe5 device.exe
0xe6 gwes.exe
0xe7 aersvc.exe
0xe8 MsgDeliver.exe
0xe9 SystemManager.exe
0xea DM_MONITOR_Launcher
0xeb MonitorProcess.exe
0xec DiagProcess.exe
0xed mmicore.exe
0xee AudioProcess.exe
0xef VoiceControl.exe
0xf0 AirConProcess.exe
0xf1 SRControl.exe
0xf2 Telematics.exe
In case you're interested, I went through and got the specific commands available for each mode:
Code:
PerformanceMoni : Description Nothing.
Change : Change Group
Group? : Show Groups
Process? : Show Process
SSDServer : SSD Output Current Status
CurrentStatus : Description Nothing.
TraceOn : Description Nothing.
TraceOff : Description Nothing.
MPDIAG : MPDiag Mode
0A : MPDiag Func Execute
cmdlist : MPDiag Command List
VPFDiag : VPF Diag
Run : Run Program
ChkDbgMem : Dump DBGMEM
SetRegister : Operate Register
GetRegister : Operate Register
ForceDownload : Force Download
GetMemoryStatus : Memory Status
DiscEJECT : Disc Eject
SnapShot : Screen Snap Shot -> PC-CARD
SysFlashDump : System Flash Dump
SysFlashClear : System Flash Clear
SysFlashSave : System Flash Save to Card
SysFlashLoad : System Flash Load from Card
UsrFlashDump : User Flash Dump
UsrFlashClear : User Flash Clear
UsrFlashSave : User Flash Save to Card
UsrFlashLoad : User Flash Load from Card
SramDump : Sram Area Dump 512k
SramSave : Sram Area Save to Card
PersisClear : Persistency Clear 32M Flash Only
PersisSave : Persistency Save to Card 32M Flash Only
PersisLoad : Persistency Load form Card 32M Flash Only
HDDTemp : VddHDD Temp Set HiTemp/LowTemp/Normal
DiscTemp : VddDisc Temp Set HiTemp/LowTemp/Normal
AERDump : AER Area Dump MAX_96k
GetDiscStatus : Get Current Disc Status
TraceDiscStatus : Trace Disc Status ON/OFF
GetHDDStatus : Get Current HDD Status
TraceHDDStatus : Trace HDD Status ON/OFF
TraceGpsData : Trace GPS Data ON/OFF
DumpUtilLog : DumpUtilLog ID[HEX]
Serial : Serial Mode
Serial : Serial No Store
ReadSerial : Serial No Print
Exit : Serial Mode End
CommandList : Command List
Model : Model Mode
SetModel : Model No Store
ReadModel : Model No Print
Exit : Model Mode End
CommandList : Diag ModelCmd Command List
Antitheft : Antitheft Mode
Antitheft : Diag AntitheftCmdFunc Execute
ReadAntitheft : Diag AntitheftCmdFunc Execute
Exit : Diag AntitheftCmdFunc Execute
CommandList : Diag AntitheftCmd Command List
Normal : Normal Mode
Exit : Normal Mode End
PasSet : Pas Set
Exit : PasSet Mode End
PasClear : Pas Clear
MakePasCode : PasCodeMake(FlashSetOnly)
ClearPasCode : PasCode Zero Set(FlashOnly)
Exit : PasClear Mode End
BusMon : Bus Monitor
Write : Bus CMD Write
SimRead : Bus CMD SimRead
ChangeBus : SYSTEM / CAN Watch Bus Change
Exit : BusMon Mode End
SysMicomTest : System Micom Test
Send : TEST CMD Send
Exit : System Micom Test Mode End
TchChk : Touch Check
Exit : TchChk Mode End
ModemChk : ModemChk Mode
Exit : ModemChk Mode End
Quit : ModemChk Mode End
CommandList : Diag ModemChk Command List
ErHClr : Error History Clear
Exit : Error History Clear Mode End
ErrHis : Print Error History
TraceOn : Error History Trace Mode On
TraceOff : Error History Trace Mode Off
Exit : ErrHis Mode End
KeyIn : KeyIn
00 : Push Keyboard
01 : Push Mouse
ATAPI_DVD : ATAPI_DVD
GetSENSE : Get SENSE Code
TraceSENSE : Trace SENSE Code ON/OFF
TestUNITReady : TestUNITReady
SetSerialLog : SetSerialLog Master/Slave/All/Stop
SectorChkCDDA : Check Sector(CDDA)
SectorChkMP3 : Check Sector(MP3)
Coverage : Coverage Mode
SetCoverage : Coverage No Store
ReadCoverage : Coverage No Print
Exit : Coverage Mode End
CommandList : Diag Coverage Command List
Dbg1Mon : Vp logging mode
DemoSim : Vp simulation mode
GpsMon : Gps monitor mode
GyroS : gyro calibration mode
MPDiag : MP diag mode
0A : MPDiag Func Execute
cmdlist : MPDiag Command List
ACFunc : ACFunc SpyChannel
HMI : HMIManager SpyChannel
SnapShot : Snapshot operation.
Dump : Dump of binary image.
Save : Save to strage card.
Telematics : Telematics debug channel.
AutoTrace ON : Start DESIP packet trace mode at bootup.
AutoTrace OFF : Stop DESIP packet trace mode at bootup.
Trace ON : Start DESIP packet trace mode.
Trace OFF : Stop DESIP packet trace mode.
Trace ALL : Start DESIP packet trace mode with unitless.
Playback ON : Start DESIP packet playback mode.
Playback OFF : Stop DESIP packet playback mode.
Playback Type : Register filltering message type.[-u:unregister/?:list]
Playback ID : Register filltering message id. [-u:unregister/?:list]
PhoneBook : PhoneBook debug channel.
Import : Import Phonebook Record.
Export : Export Phonebook Record.
Clear : Clear Phonebook Record.
There's a "ForceDownload" command, which I assume will reflash the image from disc... so it should help with unbricking, assuming you don't brick this menu. And the "ReadAntitheft" command outputs your antitheft code. Some of these modes actually change what the system is doing just by entering them (e.g. TchChk shows a touchscreen test).
Also notice under the VPFDiag channel, you can actually run a program! Unfortunately, it looks like it just runs CreateProcess with the .exe file you specify... not allowing any command line arguments. So, I used eMbedded Visual C++ 4.0 (ancient version that supports WinCE 4.2 on the SH4) and wrote my own program to run stuff (allowing command line arguments, etc). I used a PCMCIA to SD adapter, put my program on there (accessible at \storage card\), then called it with the run= command from VPFDiag.
I didn't see a way to kill a process, so I wrote a program to do that... though I guess as somewhat expected, most of the processes seem somewhat critical (killing them locks things up, etc). When locked up, there's been times where I have to actually unplug the power connector to get it back (I assume the software watches the ACC power to shutdown). Sometimes it locks up the debug interface, and sometimes not.
I was hoping I could run my own mmicore.exe command (experiement with other skins, forms, etc), but from looking through the registry, it looks like it actually has a lot of other threads (I don't think it just handles the UI skins). And killing that process locks up the system (though proclist shows it either immediately respawns, or never dies). I noticed that mmicore.exe checks to see if there's another instance running before starting... so starting another mmicore.exe just exits. I modified the program to skip that check, and it causes a watchdog reset when run. I did notice that killing AudioProcess.exe simply makes it so the audio button no longer works (rest of system was fine, but pressing the Audio button was completely ignored), so maybe there's a clue that AudioProcess.exe has some hooks into the same UI display control.
This also a pretty stripped down Windows CE build (e.g. there's no cmd.exe), so I used Platform Builder 4.2 (ancient, of course) to build some of the missing utilities (just did a generic SH4 build to get some .exes, I didn't make a proper hardware configuration to reflash the entire image). Though it looks like it might need some registry keys for cmd.exe to work (console output looks to be disabled). And it seems like the Navi software has full control of the display, since no programs I run ever show up on the screen.
BTW, I looked at the car's wiring diagram, and the only connection really required to run this is 12V power on the one connector. To make things easier, I decided to hook this up on my workbench... I didn't have the proper connector, so I just soldered a few wires (GND, +12V, and +12V ACC), then used a grabber cable to my lab power supply.
Anyway, I've got a lot more notes, but that's probably enough for today.
What a fantastic bit of research @DogP ! I'm currently on vacation myself, so a fair few miles away from trying this on my car, but I'm sure I will when I return! From memory my motherboard looks a little different to yours... Not sure there's even a card interface. There is an exposed pin header on the bottom of the unit, which I assumed must be for diagnostics. I'll see if I can sniff the same pins when I'm back.
Yes, in August the dash clock will begin to track the actual time from GPS again, and won't keep losing minutes.
Basically, the time coming from the GPS is still correct, but the computer doesn't "believe" it, because it's programmed to ignore the GPS if it says it's 2002 (likely because 2002 is the default year after the battery is disconnected, and the cars were made after 2002, so they expected 2002 means GPS hasn't sync'd yet). So, once GPS says it's 2003, the computer will believe that the clock is correct, and synchronize everything to GPS again.
DogP
A couple months ago it just finally locked its time correct, but the calendar still out by many years and a few months.
Never before did it erratically and periodically lock up the car icon on the Map screen like it 'lost where we were'... it would release and suddenly show us accurately on the map again. frozen GPS icon usually doesnt last more than 15 mins tops.
Going thru the Diag. menus from AngryDad hack, I also noticed the angle of the sun was way off... manual adjust would not stay put on that, on GPS settings, and barely on calendar date change (seems to be limited to a month at a time max adjustment, if trying to at least bring the calendar up to the same month... would take forever trying to do that, and per year until 2022 timeframe achieved)
If its not sure the actual position of the sun cuz its lower in the sky in autumn than it shows now for spring/summer, maybe it also screws with GPS location somehow maybe? If it compensates the signal then doesnt know the horizon accurately by date/sun, who knows... maybe it looks in wrong place for gps?
Absolutely not. This is a core function that they should be responsible for fixing themselves, even if it means sending DVDs to dealerships for a recall.
lol me either... prev owner got the update here in Chinada (used to be canada but we have a commie worshipping DICTATOR IN POWER now)
Dont remember the disc number, doesnt matter any way, unimpressed with such things from Acura.
This 'update' says the world ends virtually 2/3 of the way up my province... just black screen if you go farther north than a cute little town Peers, Alberta. Sure it tracks you, but i guess cities like Ft Mac and towns Peers and places farther north dont matter. Not paying hundreds for likely very outdated or incomplete data, thats what an iPad or Galaxy Tab can do better instead.
@DogP : Curious to hear if you also noticed this, but I just got back from vacation where my car had been sitting for 2 weeks. Start it, and the clock is exactly one hour behind. The minutes are dead on accurate, but the hour was off. Reset the clock, still ended up being an hour behind. I was, however, able to adjust the house in the setup and have it stick. Thought that was a little odd given that it's not August where Acura says it'll all be fixed.
I noticed for me (07 TL) last month my clock was off by an hour (i think behind)
I had mine set to auto adjust for daylight savings so I just disabled the option to auto adjust for DST and it fixed itself. I noticed at that time my calendar thought it was November.
Well for me, I followed the steps provided by DogP earlier in this thread to make that modified firmware CD, and then once updated swapped back in the OEM DVD.
I noticed for me (07 TL) last month my clock was off by an hour (i think behind)
I had mine set to auto adjust for daylight savings so I just disabled the option to auto adjust for DST and it fixed itself. I noticed at that time my calendar thought it was November.
So is the calendar correct now? Anyone with an RL been able to fix their clock yet?
A second related issue just started in my 2005 RL on Sunday July 3 - when I started the car the NAV display was a checkerboard pattern. Got breakfast, restarted the car, it worked normally. Today (7/5) same thing happened - restarted the car in the driveway and the NAV worked normally, but I was using the address book to guide me to my destination and the car icon stopped moving halfway there, time to arrival was stuck at 19 mins. When I left that appt., got a crazy criss-cross pattern on the display, turned it off, restarted, and it worked fine all the way home. Checked for the problem here, discovered some horrible things - NOTHING WORKS if the NAV unit in the trunk goes wonky - cannot access radio or AC screens, voice command button on the wheel doesn't work - basically you can't change ANYTHING if the NAV DVD unit goes on the fritz - what an idiotic design! Looks like only option is to try a used unit from Ebay - anyone have any luck with doing a used NAV DVD unit swap in their RL? A new one is $3k - that ain't happening. Worried about breaking the plastic clips that hold the carpet to the trunk - they're 17 yrs old and brittle - have to remove the top carpet to get to the mounting screws and cables. This almost sounds like a loose connector or a chafed wire - if it was really fried it would just stop working, period, right?
Last edited by ex_hacker202; Jul 5, 2022 at 03:43 PM.
Well for me, I followed the steps provided by DogP earlier in this thread to make that modified firmware CD, and then once updated swapped back in the OEM DVD.
Ah, then we’re in the same boat then, as that’s what I did.
@DogP : Curious to hear if you also noticed this, but I just got back from vacation where my car had been sitting for 2 weeks. Start it, and the clock is exactly one hour behind. The minutes are dead on accurate, but the hour was off. Reset the clock, still ended up being an hour behind. I was, however, able to adjust the house in the setup and have it stick. Thought that was a little odd given that it's not August where Acura says it'll all be fixed.
Yes, as @Mizouse mentioned, you'll want to disable auto DST. That's because the hack I posted simply adds 20 years instead of 1024 weeks (~19.6 years), and it now thinks it's November and time to undo DST.
Yes, as @Mizouse mentioned, you'll want to disable auto DST. That's because the hack I posted simply adds 20 years instead of 1024 weeks (~19.6 years), and it now thinks it's November and time to undo DST.
Hmm, that doesn't seem to work for me. I turned off auto DST, and the time stayed 1 hour behind. No combination seemed to work short of manually adjusting the hour.
Yep, that's correct. Since you originally set the clock when auto DST was adding the hour for DST, auto DST now turned off DST because it thought it was November, causing it to go back an hour. So you need to turn auto DST off first, then set the clock... then you'll have to manually set the hour +/- 1 hour when DST actually occurs.
like my parents use to
Some of these modes actually change what the system is doing just by entering them (e.g. TchChk shows a touchscreen test).
