1) P04s have VERY flakey J1850-VPW timing. This means that the timing can sometimes be far out enough that the responses from the P04 are rejected from the OBDX VT, we found that adding a 4.7k+ ohm resistor from the VPW pin to ground actually helped the stability of the P04 signal as it allowed it to clean up its 'low' pulses. Its not recommended to permanently leave a resistor like that connected in car or bench since it results in applying more load to the bus then is required. At 1x speeds, the P04 is able to maintain a stable timing as there is alot more room for error.
2) The P04's can be a bit temperamental, some seem to require the watch dog to be patted more frequent then others. I believe this comes down to internal interrupts firing which could be operating system dependent.
Both of the above can result in random drop out when reading or writing, hence its almost better to run at 1x VPW, and part the watchdog more often for stability.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Trial and error is the only practical way I am aware of. You can get it to spit out a particular VPW message at particular places in the code and monitor the vpw bus and use that to try and see where it gets up to. Thats good for a repeatable crash but less useful for instability. Or you can investigate the 'breadcrumbs' feature in the pcmhammer mainsteam kernel as thats designed to drop bytes into a small buffer then send the buffer so you have some kind of visibility as to whats going on in the pcm. That wont fit in a p04 kernel upload though, so you'd need to finish adding the step of having a loader uploaded first (similar to above in this thread? viewtopic.php?f=4&t=8008#p118589 ) and add some implementation to pcmhammer, then use that to upload a larger pcmhammer kernel (which is a step we'll likely need on the way to full flash anyway). There is some possability of using BDM to debug on the PCM. From what I've seen you need to get the BDM to set some registers to turn off the watchdog first, then you should be able to break and trace with the right hardware and software. I dont know what hardware this would be, and Ive seen flashing over BDM but never debugging. Its work considering IF you have done firmware before and have/understand pro level BDM tooling similar to whats being done here viewtopic.php?f=26&t=8037
Jakefunny wrote:The Watchdog patting in my read kernel is heavily based on WinFlash which worked for Antus.
Any ideas how I can tell what the issue can be? To bad not many people are interested in the P04 PCM, more data would be nice.
When I was creating one, I basically ensure where ever there was a for/while loop, the watchdog would be patted. Along with ensuring it was done at the start and end of every single jump (function) inside the kernel.
One issue to help track down if it is tool or kernel related is use 1x mode, and see if it drops out still. If you can reliably do 1x (Which technically is slower in the routines where it writes to the VPW line in the kernel) multiple times in a row, then the issue would be more likely related to noisy VPW signal produced by the P04 at 4x.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
I dont think its a watchdog issue here though, because the experimental kernel in pcmhammer can transmit 2k blocks fine until about the 80% mark, then at one particular place with certain data it crashes, with any packet size over 8 bytes. So, its somehow data related. So, based on what you said about this DLC being a bit unstable or sensitive to timings, I reckon there is a state returned from the DLC about some kind of transmit error that we never hit on the P01/P59/P10/P12 and we need to figure out what it is, where it is, and how to handle it properly on this generation of hardware. Hard to know what it is though, when we crash blindly straight away. Older motorola vpw DLC docs would be useful if anyone has been able to find them. They should have example logic to transmit a packet, and I reckon it'll be slightly different to the docs we used for P01 which did us well for all the other models so far.
I guess its time for me to go and source different versions of the P04, since I can't replicate the data drop and the crashing of the kernel that Antus got.
I'm still working on the loader kernel when I have time, but I worry it will work for me but not others.
Ill post a copy of the bin that my pcm cant transmit with the experimental pcmhammer kernel later, and if you can load that on with another tool it'd be interesting to see if you can recreate the problem. I remember there is a long run of $55s which are 0101 0101 over and over when it crashes. And VPW does long/short pulses high to low or low to high depending on 1/0 so it might create a long run of all long or all short pulses (I havnt calculated this or looked with the scope to verify) but especially if its all long something might happen that the code cant handle. The DLC can do it and my pcm/hardware is not faulty - other tools can read and write this PCM with this data.