FORD technical service bulletin : ICC touch screen display

[JasonACT]

It's what you know (see signals below).. and even better when it's who you know - but I know no-one when it comes to this QNX operating system, so slow progress...

Hardware->driver->/dev/ser5->gps->/dev/swsa/gps_nmea->sym_link->/dev/ser11->nav_iGo...

This is the OS configuration of our FG2 sat-nav ICC units, and I didn't give it a 2nd though why "gps" even existed before.

The main function of "gps" is to blindly scan through all "standard" BAUD rates and send a command to "set the chip to 115200 BAUD" where once done, it switches back to 115200 so it can listen to any reasonable messages coming though. They come about once a second. There's some other config messages sent by "gps" after that (I have not decoded them, so don't know what they are) but then it's just the current physical position data coming in - once a second - that's used by the nav software. Some binary messages are also removed, but that's specific to this chip only - u-blox.

Ok, so I might not even need a 9600 BAUD (which is the power-up initial setting) port to get this thing working. There's an acknowledgement sent when it understands and accepts the BAUD rate change, but it doesn't seem to bother reading that - it just sends the same command at all the standard BAUD rates.

Sooo... Last Friday, I thought I was ready to pull out my most up-to-date ICC from my car and install things, but decided to try it all on the bench first with my older unit. 4 days later...

The "nav_iGo" software requests a notify signal for when data is available from "gps" but it expects 256 bytes to be able to be read at the data-ready signal-time (by the notify request). the "gps" software (a Sumitomo special!!) triggers when even 1 byte is available - meaning the "nav" software can get trapped in an operating system kernel call waiting for the other 255 bytes to come from the serial port...

No big deal, when initially powered up, that eventually happens... Until the unit goes into super-low-power mode after 10 minutes of non-use and the serial port (and CPU and everything else) is turned off. Somehow they worked around this problem by detecting the power change in the driver, but my Gauges software doesn't pass that power change message along - so it gets stuck waiting for bytes from a disabled serial port. They don't come, at least until the unit it powered back up much later.

The "nav" software panics that it hasn't got its 256 bytes after 10 seconds (as it can't unblock to process the car's accessories-off signal) and the "watching guardians" kill the "gps-nav" thread. The "gps" data is never again read and you will see a message in the "nav" software that the gps device has been "switched off".

4 days later... I've put in a "Repeater" program to replace the sym-link from /dev/swsa/gps_nmea to /dev/ser11 which only signals back when 256 bytes are actually available and the damn thing now sleeps and wakes perfectly.

Next weekend..... Should be good. But these may be famous last words.