I'm not sure what I'll do next, but it would be good to somehow verify it's actually running the kernel.
Sadly though the kernel only lived for ~ 9.5 seconds if I'm reading the message timing correctly. So the issue of not having the watchdog figured out could be an issue getting much more progress made.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
Not exactly, You just upload some data at some ram location, To run the code you need to send it with 36 80 [36 00 upload only, 36 80= upload and execute]. The mode 34 expired When you start seeing data.
Ah yes! Another mistake, it's getting quite late...but I'm glad I've got this far. I should have probably figured this all out much faster, but it's all quite new to me.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
I watch the logger, the PCM will chatter until you take control, then it will go silent, the second it fails it will start chattering again!
I start with a kernel that does nothing but loop around the COP, when it effectively locks up the PCM (endless loop) and remains silent for a time period longer then the timeout, I know I have the COP's right.
So far, it has always required a battery disconnect to recover, I do not know about this on the E92.
I do sometimes have my loop timeout as well, not typically though when I first start, I find less code, less to cause side effects. However I don't mind the battery disconnect, it's just a flip of a switch to me.
Hope this helps!
-Enjoy
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Ok, so adding a Mode 36 execute (00 00 07 E0 36 80 40 00 80 00) causes it to not get any response...but I think it might be in the infinite loop in my kernel.
It's weird that the ECU doesn't give you a positive response prior to jumping to the code, but I guess that could be the way they intended it.
Ok, I had my test kernel send out a response and then I wanted it to be in an infinite loop to try and mimic the previous kernel that only had an infinite loop.
This way I could verify that the kernel is running an see if it will stay running. It was partially successful in these goals because I received the response from the kernel, but the chatter started back up so I'm assuming it was no longer running after that.
You have to send a tool present broadcast message every 2 or 3 seconds to stop everything on the bus from chattering again. Without that things assume the tool has gone and reset.
I don’t recall if the e92 has a watchdog active when uploading a kernel. It’s been a long time since looking at them. Although I might be confusing with e98… I did a lot of work on one of those years ago!!
But you have an infinite loop running so it won’t send anything until you basically key cycle and the ecu reboots.
Next part would be identifying the CANbus routines from the reference manual to start writing routines to read and write CANbus.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
antus wrote:You have to send a tool present broadcast message every 2 or 3 seconds to stop everything on the bus from chattering again. Without that things assume the tool has gone and reset.
There isn’t anything on the bus. It’s just a benchtop ECU. So that makes me think that the kernel is stopping and probably because of a reset. It’s weird that in my previous test the kernel seemingly kept running until a key cycle. I’ll be doing some more testing to confirm all these results.
Tazzi wrote:I don’t recall if the e92 has a watchdog active when uploading a kernel. It’s been a long time since looking at them. Although I might be confusing with e98… I did a lot of work on one of those years ago!!
But you have an infinite loop running so it won’t send anything until you basically key cycle and the ecu reboots.
Next part would be identifying the CANbus routines from the reference manual to start writing routines to read and write CANbus.
Yeah, reading messages into the kernel would be a pretty big milestone, but it would be very time consuming to do with the manual assembly instructions that I’m using now. I would at least like to find a better method for that. If anyone has notes or suggestions on a compiler let me know.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
