Something went wrong about here. It looks like it was determining what sectors it needed to re-write and it got out of sync. It got the CRC for the first sector (06 00 00), then it asked for the CRC for 05 00 00 (the second sector) but it complained it had timed out and did not. In fact it timed out too early. Then it asks for 04 00 00 and receives the previous 05 00 00. This does not match and is not accepted, then comms are lost, then the crash and by the end the pcm is still running the kernel but its not communicating properly. It didnt erase any sectors, so I think it should come back from a power cycle if that is where you are at. I think this might be fixed in the develop branch, we clearly need to get another release together as there are a couple of fixes in develop that need to get out there.
antus wrote:I dont think you necessarily have a brick there.
Something went wrong about here. It looks like it was determining what sectors it needed to re-write and it got out of sync here. It got the CRC for the first sector, then it also got the CRC for the second sector but it complained it didnt. In fact it timed out too early. Then comms are lost, and by the end the pcm is still running the kernel but its not communicating properly. It didnt erase any sectors, so I think it should come back from a power cycle if that is where you are at. I think this might be fixed in the develop branch, we clearly need to get another release together as there are a couple of fixes in develop that need to get out there.
[02:38:20:169] RX: 6C F0 10 7D 02 01 00 00 06 00 00 62 A6 D7 96
[02:38:20:169] 060000-06FFFF 62A6D796 62A6D796 Same OperatingSystem
[02:38:20:200] XPro: 20 01 00 DE
[02:38:20:200] TX: 6C 10 F0 3D 02 01 00 00 05 00 00
[02:38:20:966] RX: 8C F0 61 60
[02:38:20:966] Unable to get CRC for memory range 00050000 / 00010000
[02:38:20:997] XPro: 20 01 00 DE
[02:38:20:997] TX: 6C 10 F0 3D 02 01 00 00 04 00 00
[02:38:21:341] RX: 6C F0 10 7D 02 01 00 00 05 00 00 A5 64 D6 33
[02:38:21:341] Unable to get CRC for memory range 00040000 / 00010000
Ok, I will swap PCMs for the night, then swap back and hopefully it comes back from that.
Could you give me a quick idea of what the kernel does? Is it permanently in the flash or is it uploaded into RAM or...? Just so I have an idea of the backend of this stuff as I'm completely clueless.
It loads to ram and runs the PCM during the flash process. It needs to handle the communications chip and the flash process, as well as the hardware watchdogs. It just runs in a loop until its told to exit. This allows the flash to be erased, whereas normally the factory kernel is running from flash. If PCMHammer crashes, it leaves the kernel running, so it wont respond the same as the factory operating system would until it gets a mode 60 reboot request or a power cycle. If pcmhammer has logged an erase, then its best try and work with what you have as it might not come back after a power cycle as the boot sector might be broken. If you have not had an erase, you are probably ok. The later PCMs have some recovery code in the boot sector, and in our app the boot sector is erased last, and so long as that is in place you can recover. But the P04 does not have boot sector recovery.
This is showing something else has woken up in the car.
The tester present message is not being sent enough, and resulting in other parts waking up in the car.
At 1x, this technically is not the end of the world. But PCMHammer is not 'searching' for the actually message it needs and instead takes the first message it sees as its response even though its from another module.
There needs to be processing added into the function which searches for a network frame and outputs a message indicating 'car chatter detected' which could also change the dynamic of the application or could automatically make it send another "disable chatter" command.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
For some context, this may have been inadvertently caused by me. I was doing some logging trying to sniff parameters. I may have not keyed off after doing so and gone straight to a write.
It does look a bit like that, source id 61, target id F0 - tool. Device 61 would not nornally be trying to talk to a tool. But there are search functions that wait for a specific response already, we should be using one of those here.
Looks like a mode 20 was requested. But looking closer at logs PCMhammer waits only for 4 responses at mode 28. And there could be upto 15-20modules in a car.
Later responses also interfere with seed/key logic.
In my own software, I do the following:
1) Begin tester present routine
2) Perform normal setup steps(mode 28, ect)
3) Between every single single step, add 1 second delay (Tester present still being sent here)
4) Begin flash routine, send tester present manually after every single block sent or received.
The delay between each step is more then enough to ensure the entire vehicle has responded and processed the response.
The current filters of the app are setup to basically accept anything that is sent to F0 or 6C from memory. In theory this is great, but, the app is not setup to handle messages from other apps correctly.
In its current state, it would need to search for an invalid (7F) response that comes from another module that would result in it erroring out, while still searching for the desired modules response.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
It should be enough. It was developed against Australian Commodores, and the logic that is in there seems to work fine on P01 / P59 for other vehicles. No doubt logic holes are starting to appear as we add more platforms. We just need help/time from those with these cars to look at what is breaking, and why, and improve the logic. It is part of the logic tidyup that the app would benefit from.
