so far things are going well on the 'high level' side. i'm working hard to build every function to recurse into a programming state. this means we don't really care if we're in a mode 5 loop or if the ecm is unlocked, if we call a programming function, it'll deal with that. i just sent a mode 6 request and it managed to recurse into an unlocked state and send the request. this kind of logic will be invaluable for automatic recovery.
things are going well, i did a mock write of the tside today and the errors were minimal, i think i'll have basic flash write working in the next few days.
tonight's major progress is i built a sequential block mapping thing right into the bin file class, which allows us to prioritize or skip arbitrary write blocks, then run a simple finish_map() algorithm that fills in the blanks. i can later build an optimization algorithm into these methods which will allow us to optimize things like skip points (for example if it's not any faster to skip some particular region due to the yet-to-be-calculated break-even point for flash instructional overhead, it'll just write it anyway.)
Nice.
You may already have other thoughts about the flash process but I can give an idea.
Between procedural processor and user interface the flash logic can reside.
Flash logic can be set for each class of pcms, containing steps logic on responses, retries, errors,
Something like this
step 1 unlock, if ok goes to step x, if not ok goes to step y, if timer not expired message got, go to step z.
step 2 upload flash routine, if good go to step 3, if and so on.
step3 flash eside
step4 flash tside
step5 reset pcm
step6 update vin
and so on
It will give great flexibility to add new pcms to the flash list.
the main purpose of the processor is flash logic and methods, so it'll be in there. the processor itself is really clean already and way more readable. adding support for a new ecm will probably just require subclassing a similar ecm and overriding a few methods.
can anyone confirm if the y-body CCM will wake back up on its own after losing bus master status?
Be happy to test that for you if you can point me in the right direction. Anything special I have to do to find out for you?
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
Seems like it does - I just tested by bringing up coolant temp on the DIC and then pulling the usb cable while logging. After about 30 seconds of silence the temperature updated. Normally all this info (oil, coolant, fuel consumption) is pegged at whatever data it got before eehack connected.
The pcm is set to stay silent for 5 seconds, I guess this applies to other modules too, but it might be longer, like 30 seconds.
The timer expires with no bus activity, any data being send on the data bus, restart the timer.
oh 30 seconds ? that's pretty good. the fbody/bbody reclaims the bus after 3 seconds.
That's just a rough observation, could have been 5 seconds. There's nothing time critical that the CCM does that relies on the aldl data. VSS for speedo and odometer functions must be wired direct. The radio has GM's ridiculously bad speed controlled volume (that even to this day is ridiculously bad) and it works while the CCM is shutup.
would sending 0x00 every 200ms or something while idle keep it from trying to reclaim the bus?
it doesn't matter too much now, this new program treats any noise present on the bus (or crap in the serial echo) as a reason to try to reclaim the bus. it's always aiming for a silent bus before the next command. but i'm worried the ECM will wake up in the short time between when we monitor the bus, and send the next command.
i'm pretty happy right now, flashhack did a clean read of the t-side without any significant errors and the checksum is valid. changing the response message to mode 5 worked perfectly to drive 'kernel loaded' state. i quit in the middle of a read, and when i restarted the program, it detected the loaded kernel and worked fine. i think its almost ready for alpha testing (once i build all the other boring stuff so people can click buttons and make it work)
fbodies and bbodies got that hilarious thing too. i kept wondering why my stereo sounded more awful on the highway.Originally Posted by spfautsch
Need some testing with the pcm, but I think a 1 second interval will be much better.[Bwould sending 0x00 every 200ms or something while idle keep it from trying to reclaim the bus?[/B]
The ccm might pose some serious problems on mini rom recovery mode. The pcm might froze on any message that is not mode 5 or 6. A verification is needed.
Sorry, can't help but soap-box a bit. A close friend has a 2019 silverado with their latest-and-greatest infotainment / telematics system, and the SCV works the same way it did in the 90s but with a touchscreen UI. In a nutshell the system adds N db of output power based on pre-determined VSS thresholds. The user can adjust how much it adds in three or four extremely coarse increments. But road noise (and all sound for that matter) has the immutable quality of being completely linear. Whatever Delco engineer implemented that "feature" should be forced to listen to Moby Dick on repeat at 140db peak until his ears bleed.
Back on topic...
Posting Permissions
Reply With Quote
Bookmarks