FourG

Do you have a UART/I2C protocol analyzer handy? It could help immensely..

No, I need to either borrow one from work or pick up my own Aardvark. Probably need to see about a cheap 2nd-hand o-scope or logic analyzer/data acquisition system too. Might be able to hack one with a ADC, uController and a USB to RS232 if I really wanted to get ambitious.

Any UART protocol anayzers that you recommend?

Yeah, if you look at the block diagram in the F900BT/F90BT service manual posted on the Hacks/Mods forum, it looks like the AV board has an ASIC (uCOM) that the Navi controls via a UART to select amongst the various audio sources (Tuner, SD/USB, AV1, AV2, Bluetooth and voice, a.k.a. navigation commands), send commands to the IP Bus and other components (like the tuner?) and such. Once my test subject arrives this week and gets a lovely bench setup, I'm hoping to get some probing on some of the Tx/Rx and I2C lines to see what commands are getting shuffled about between the blocks in the diagrams. Once I've got some protocols documented I hope we can reverse-engineer our own drivers and cook our own image.

Once that's done there is always the potential for alternative OSes too, I know QNX already has a BSP for the Titan reference board they based the Navi unit off of.

Has anyone investigated remapping the default action of the multifunction knob left/right action to change presets instead of seeking? I'm pretty technically savvy but don't want to reinvent the wheel if it's already been investigated.. Could also be hard coded in the program logic...

 

Thanks,

Ray [MSFT]

Hey Ray, Leetcoder has figured out how to add event listeners to the knob buttons when booted into Testmode/Leetlauncher environment (see his Leetlauncher 3 post). He hasn't posted any information on the topic in the Wiki or the forum on how this is accomplished (yet). No one has yet posted a hacked APL exe for remapping the left/right buttons in the stock software.

I personally would be very interested in how the button handling logic is done in the WinCE environment (new to WinCE, but not to general embedded OS concepts) for correctly configuring my development environment to create new apps. Maybe a Wiki section to collect code samples might be in order? Maybe a section for WinCE exes, one for iGo scripting, etc...

Can you explain me why this uboot file should not be used from SD ?

Just a caution that if you don't know what you're doing with uBoot and how to restore a bricked unit, you might not want to flash his copy to your AVIC. May also overwrite some of your unit's unique ID codes with his unit's, or his could be meant for a region (US/Canada versus Europe) that would render some of your unit's features unavailable.

What is IDA ?

Interactive Dis-Assembler, full name is IDA Pro (use Google to find more info). It will take the binaries from the uBoot and system flash (like av.exe, navi.exe, etc) and help convert them back into human-readable source code. This process isn't automatic, and does take a lot of human involvement.

Where can I find the latest version of AltlasMgr and instruction on how to use it ?

Good question, hopefully Carver doesn't mind PM'ing that info to you. It probably comes with a reference design kit for the Titan CPU that's in the AVIC-Fs. Wouldn't mind knowing myself...

So what does this mean? The new US model that's supposedly coming is probably AVIC-X910BT?

Probably. Also interesting to note that the Navi and AV boards are not shared with the F90/F900BT, so there may also be some improvements to the design instead of just a difference in firmware.

We can probably use techniques similar to how MioPocket does it, which is to use MortScript to automate copying missing DLLs and updating registry entries on bootup. Since Leetlauncher 3 already uses MortScript, it should be pretty easy to extend the framework Leet's created to do some of that. Might be best to streamline some of what MioPocket does for their startup process though, since they were aiming at being compatible across most of the PNAs (Mio, HP iPaq, etc). They do have a way to go "SD-less" so you can use the SDIO Wireless cards like the Spectec, but it does copy some data to the flash drive to do so. Hopefully once my "volunteer" F90 gets here and wired up on my desk, I'll have some fun results to share.

Does anyone know the CPU type used in F90BT? Is it an ARM or X86 ?

Also which version of CE runs on it?

It's a SiRF (formally Centrality) Titan Dual-core ARM processor running Windows CE 5.0.

It would be possible with MioPocket or LeetLauncher 3, if you don't mind losing the Radio/iPod/XM/Sirius functions while you're booted off the SD card into those environments. MioPocket already has the Office apps hacked in IIRC, with LeetLauncher 3 you would need to copy them over to the SD card somewhere to use. I haven't personally tried MioPocket with my AVIC-F90BT yet, but it runs pretty well on my iPaq 310.

Sweet! Any chance you could snap some pix of the AV board as well, specifically around the uCOM ASIC?

Is it possible to make the knob (klickwheel) to interact with the iPod control?

Up = Menu, down = Play/pause, right/left = next/prev. track.

Do you mean using the iPod's clickwheel as a pseudo-remote control? I don't think that's an option at the moment.

So in the file APL\NDeviceLib.dll there are several very interesting references in the .rdata section (open the file with 7zip and use a hex editor like Notepad++ w/ Hex Editor plugin, "F4" in 7zip is your friend here):

SendNaviSourceSwitchReq@NPuComHandlerProxyBase

InstanceBase@NPRmtCtrlHandlerProxy

IsChangeFlg@NPuComMemoryBase

OffWait@NPuComMemoryBase

OnPostEvent@NPRmtCtrlHandlerProxyBase

OnPostEvent@NPuComHandlerProxy

Looks to me like this DLL has the library routines to talk to the uCOM, request audio source switching and handle Remote Control commands... I don't have IDA Pro at the moment (and next to no free time to use it even if I did) but would be very interested to see what the .text section reveals. Anyone w/ IDAPro mind taking a crack at this file and post what you find?

Should also note that on the iPaq under ui_hp_sagan\common\ui\variable_def.ui, there was a variable called vDriveCarefully_show.

Nuked that one too on my iPaq and tried several tests:

1. Message didn't display on first startup (hard reset, boot, select nav options all the way to the map screen)

2. Suspended, plugged it in, turn on. Message displayed.

3. Suspended, unplugged, turn on. Message displayed.

Repeated steps 2 & 3 a few times and still got the message every time. Need to re-install Cygwin today so I can grep the whole tree for vDriveCarefully_show to see if there's a script that re-sets the variable somewhere on a suspend/exit.

Anyway, the Pioneer UI files don't have the vDriveCarefully_show variable. Also recall the experiments Dr. I-Forgot-Your-Name-Sorry and a few others have tried (deleting iGo from the flash entirely, pressing MAP and still getting the message) seem to indicate we still need to alter navi.exe somehow to nuke the message on the AVICs.

Jeff,

If you get the Service Manual for the F90/900BT, look at page 168 for a diagram of the board with the keys on it. That's your AV2 input at the bottom of the page with a reference pin 1 on the left. Now look at pages 150-151 for the pinout of the connector. Pin 1 is Video, pin 2 is Video GND, pin 3 is Right and pin 4 is Left.

Hope that helps get you started. Drop a PM if you need more info.

Does anyone have experience with using any type of wired remote (outside of the wheel) to control the headunit?

See this post to the Hacks forum. Looks like the Sony RM-X4S works.

holy... i dont know if your asking or help or what, but your lightyears a head of me.

He's pointing us at the chip that stores the very first instructions that the CPU executes when it gets power. Description of the chip is here. An encouraging line from that document is:

A standard EPROM programmer can also be used to program and erase the device.

Basically, carver's put us one step closer to replacing the eBoot software in the FlashROM with other loaders that might let us boot alternative OSes (like Linux, QNX, etc). I've been eyeing the instructions at http://community.qnx.com/sf/wiki/do/vie ... leasenotes the last few days, thinking similar instructions could let us boot QNX or Linux.

One remaining problem is we still need to figure out how the DLLs and APIs in the current OS send instructions to the other devices in the system (uCOM IC, GPS receiver, touchscreen, button inputs). uCOM does a lot of the work for the Navi unit when it comes to the AV board (probably audio source switching commands, e-volume, etc). Without that information, you can put a different OS (or WinCE image) on the board but won't be able to make it do much.

The nice thing about having the .bin of the Flash ROM is that if you accidentally brick your unit trying to update eBoot (or maybe WinCE) you might be able to use an external Flash programmer to put the working code back. Very cool.

the wired remote plug in the back of the unit is for the steering wheel control adapter to plug into, not an IR extender

I would contend that if someone were enterprising enough, they could build a device that converts IR commands into the relevant voltages that the input expects for the different steering wheel button presses. IR Fast Forward command == Voltage 1 that the steering wheel adapter puts out, IR Rew command == Voltage 2 that the steering wheel adapter puts out, etc. Since that remote input is used by Pioneer and Sony, I wouldn't be surprised if someone (PAC or otherwise) may have already built such a device.

Just saying, nothing is that absolute these days.

Can the tuner section firmware not just be re-programmed to interpret "next track"/"prev track" remote commands as next/prev preset instead? That would solve the problem for me as there is always the on screen buttons for tuning if required.

Ideally, yes. As far as the Navi unit is concerned, they're all just button press events that some interrupt handler is forwarding on to the correct program to handle. The .exe most likely to be the one to hack is APL/AV.exe. If Pioneer was really savvy, they'd have a menu in the settings for mapping buttons to commands for each screen (i.e. "Up" maps to "Preset Up" in FM/AM/XM/HD/Sirius, "Next Track" in iPod/SD/USB/CD/DVD). I'm itchin' for some free time to really play with the firmware on the emulator and a bench unit... Maybe in a few months.

From what I've read on the other forum, you can change presets on AVIC by shorting the other ring on the remote jack while applying the Seek Up/Down signal. It's just that no existing remote actually does that right now...

Yeah, you got me thinking about it and I did a bit of Googling on the Intertubes... Came up with this discussion of the protocol on MP3Car.com. Anyone have their SWI-PS out and handy to see if the ring goes low when you hit a button meant for "Preset Up/Down"? I know 1PACMAN claims Pioneer changed their behavior on the AVIC Fs and that it's not the same protocol it was on older HUs. Just curious (since I'm at work at the moment and can't open up the dash right now).

Here's the process that happens on the AVIC F units:

Connections:

Steering Wheel Button --> Converter (PAC SWI-PS, etc) --> Pioneer Remote Input -> uCOM on AV board -> Navi board

Timeline

• [*:1n69sy8v]You press a button on the steering wheel. Thanks to a voltage divider connected to that button, the voltage on the wire going into the Converter input changes (usually goes lower).
  [*:1n69sy8v]The Converter interprets the voltage level on its input as a certain button push (hopefully the one you mapped during the setup process).
  [*:1n69sy8v]The Converter knows how to "speak" the input that the Pioneer Remote expects and sends a message like "Mode Swith pressed and released" or "Volume + pressed and held" along the wire that goes into the Remote Input.
  [*:1n69sy8v]Inside the Pioneer, the message gets received on the Remote Input by the uCOM chip on the AV board and converted to a message for the Navi unit to indicate a button event occurred ("Volume + pressed and held", "Mode button pressed and released", etc).

Now at this point, we know that any Converter that changes your button press into the Remote Input language used by Pioneer/Sony will probably correctly change a "Preset Up/Down" button press into the "Preset Up pressed and released" message going into the Pioneer Remote Input jack. It's either the uCOM, the Navi or software on the Navi that's dropping this message on the floor.

Options

• [*:1n69sy8v]uCOM doesn't convert "Preset" messages from the Converter and send them to the Navi: We're screwed, since we don't have the ability to modify the uCOM (that I'm aware of, anyone know if this is a CPLD/FPGA?).
  [*:1n69sy8v]uCOM converts "Preset" messages to a signal/message to the Navi, but the software doesn't support it: Now there's hope, since there's conceivably a way to update the Navi software to recognize the event and send the command to the tuner unit or IP bus device to go to the next or previous preset.

It's a known issue with the version of iGo (8.0) that Pioneer sourced for the AVIC Fs. Mine thinks I'm in Idaho, even though I live in Portland, OR.

The solution is to set the timezone manually if auto-correct doesn't work for your locale. R1 (8.0) got a patch in August or December of '08 to fix it, but the 2.0 firmware didn't appear to get the fix. A Google search on "iGo 8 timezone" will get you the back story on everything as far as the iGo stuff is concerned.

Isn't there a way to emulate the necessary applications as running, yet using no memory allocation? This would prevent the unit from rebooting.

Anything's possible. Just takes someone with time (not me, at least for a few months), resources and determination.

What exactly does the unit look for, just the application name in the services/processes list, or something else? Is it looking for other running processes?

Tough to say, I'm sure Leetcoder or someone else more savvy with what the .exes are doing could tell you for sure (if I had an Arm4 de-compiler at my disposal, I could make a more informed guess). There seems to be a specific API that EZRider's using in the UI files (example from "ui_pioneer\common\ui\start.ui" below):

;send message to mainmenu
	EXEC "other.pioneer.postmessage" "MainMenu" "WM_APP_AV_IGOMAP" 0	

Notice it calls out the API routine ("other.pioneer.postmessage"), the .exe/process to send the message to ("MainMenu") and several arguments ("WM_APP_AV_IGOMAP" which is likely a typedef/enum/#define in the API header, and 0 which could be anything at this point). Since it mentions "postmessage" it may be using some sort of message passing interface (mailbox, shared memory space, etc) for the inter-process communication.

I'm no programmer, but I'm sure emulating the necessary applications to do what you want with the unit can be done.

See my earlier statement regarding time + money == results. If Pioneer had more time or thrown more money at the problem, I don't think we'd be as upset with the result now, would we.

As far as I can tell, if one of Pioneer's shell executables (mainmenu, probably) does not receive a signal from iGO/EZRider after a certain time, it assumes that something is hosed and reboots the system.

Could be... The F90/F900-BT schematics for the AV board (in the service manual) do have a watchdog timer signal coming back from the Navi unit to the uCOM. The whole point of a watchdog timer is if it doesn't get reset by a signal in X s/ms/whatever it's assumed that the software has hung and the reset pin to the whole system gets pulled. Guess we also need to figure out which GPIO that signal's connected to so we can write our own interrupt routine to periodically reset the timer if we're running some other Nav software (or alternatively send the message/RPC to Mainmenu, etc to fool it into thinking EZRider's up and running).

Just keep in mind there are some potential issues you might encounter when you don't run Pioneer's iGo 8:

• 
  [*:1isj3er0]non-EZRIDER.exe apps may not handle Bluetooth handsfree calls (incoming or outgoing) correctly (seems like Tel.exe expects EZRIDER to handle the display of the phone controls)
  [*:1isj3er0]Missing Nav tie-ins to Mainmenu.exe and AV.exe (search your data.zip for "other.pioneer" type calls in the UI files, there are 5 or 6 IIRC). The alternate Nav app would need some way of executing the same commands out to the Pioneer apps in "Storage Disk/APL/". You might end up with a "System starting" overlay if the Nav software doesn't tell Mainmenu it's done initializing.
  [*:1isj3er0]AV.exe may not be able to overlay the audio menu on-top of the non-EZRIDER app (no song info, source switching w/out going back to Menu first)

Not meant to discourage using this technique, hoping to keep track of the issues encountered and how to work around them.

Can we get back on topic. one of the problems i also have when I apply a new data.zip file is that all of my FM radio presets are lost, but my XM presets are kept. why the difference? there must be some file that hold these values right?

Not necessarily. The XM accessory box may have its own non-volatile storage that it keeps its presets in, and the Navi might send a command over the IP Bus to "store this frequency to preset slot #4", etc. The AM/FM radio in the F-series looks to be a little module that hangs off the AV board rather than the IP Bus, so they may have skimped on the cost by saying "we'll store the pre-set frequencies in a DB in the Navi memory", which of course gets wiped when you hit the Reset button or remove power from the head unit.

Yeah, when it MioPocket runs on an AVIC it can't do a lot of the audio tasks (switching sources, communicate w/ iPod/HD/XM, etc) since the Mio and other PNDs MioPocket runs on don't have this hardware. We'll need the Pioneer DLLs sitting in APL/ to do most of that, I suspect. That or figure out a way to get other Nav apps to work with the AVIC software (make the equivalent of the "other.pioneer.*" calls over to AV and Main Menu when things change, etc). Some folks have been taking Ida Pro to the binaries, not sure what progress they've made there (DrPaul?).

As I've mentioned earlier in this thread, I think it would all come down to figuring out how to make calls out to the uCOM via UART #2 to tell it to do the various tasks on behalf of the Navi. That, and we make sure to keep the Watchdog timer signal going to the uCOM so it doesn't reboot the Navi if it thinks it's dead.