ALDLDroid Android App

[Dazza92VP]

Legend hanging out for real time on this then I'm getting my android os head unit

[antus]

Awesome, thanks for that!

[3400tZ]

OK, good news guys! I got a package from Australia today, that was earlier than expected! Packaging was awesome, everything looks good.

So I connected everything and plugged it in:


Fired up ALDLdroid on my tablet from my dev branch where the NVRAM work in progress stuff is and got this:


Detected hardware right away! Almost too easy, so I went ahead and started playing with reading the calibration from the app and things like that. I never was able to get to that point so I fixed a bunch of bugs in that code and I'm able to properly read calibration now. Now, I have a few questions for you guys:

1. For Moates real-time tuning hardware, I currently have two menus: Dowload bin from emulator and Uploading bin to emulator. For NVRAM, I'm assuming I should have Download bin from NVRAM and Uploading bin to NVRAM but does Download calibration (only) from NVRAM and Uploading calibration (only) to NVRAM also make sense ?
2. Somewhat related to #1, to download the whole bin, is it safe to assume I should just read / write from 0 to calibration end ? Is the calibration always at the end ? I believe antus might have already answered that for me, I will dig into my PMs if needed. It's a shame it's been like a year and a half I first started implemented this thing and forgot most of the stuff :/ Good thing my code is pretty well documented at least, that does help!
3. I haven't tried with TunerPro (and I definitely could ) but does 34 seconds to download the calibration sounds right for 12P ? Seems slow to me and haven't investigated it at all... It seems to take about 400-600ms to read 128 bytes.

And here is my TODO list if anybody is curious:
1. Need to fully test write calibration to ECU, wasn't brave enough to try even once just yet
2. Figure out the upload/download bin/calibration thing and implement it
3. Real-time tuning is bind to the NVRAM stuff already but need to test it's actually working (it's probably not in its current state)
4. Find an issue that when disconnecting on the dashboard, when going to the tuning section, it should reconnect and detect NVRAM, it currently reconnect but doesn't detect the hardware for some reason.

Once this is all addressed, I believe I will be able to push a new version to Play for you guys to test... I don't want to promise anything but sometime next week sound possible ?!

[ejukated]

sounds like great progress! write cal definitely make sense for tuning changes as it will be quicker and less chance of corrupting the NVRAM if anything goes wrong.

Would also suggest making it configurable which ALDL mode is used for upload/download as well as start and end address for bin and cal. Then it becomes universal for other code bases outside of the OSE stuff.

[Jayme]

Personally id like to see upload whole bin completely disabled, for a few reasons. We cant upload entire binn in tunerpro anyways. Most nvram codebases cannot upload entire bin anyway as the code part of the nvram is running the os and hence not able to be written to (safely). Only later versions of 12p and 11p can write entire bin because they are written a certain way to allow upgrading the bin without having to reburn the nvram. Even then all you can do is upload a later version of the same codebase. Not worth including to save confusion. If you want to update your os then use the flashtool in windows. if you want to change codebase, you have to pull the chip and reburn.

So i would like to see 3 options. Download cal, download bin, upload cal.

[festy]

OK, good news guys! I got a package from Australia today, that was earlier than expected! Packaging was awesome, everything looks good.

Glad it got there in one piece, I wouldn't trust Aus Post to deliver a house brick without damaging it

3. I haven't tried with TunerPro (and I definitely could ) but does 34 seconds to download the calibration sounds right for 12P ? Seems slow to me and haven't investigated it at all... It seems to take about 400-600ms to read 128 bytes.

That's in the right ballpark at least. Just be glad you're not working with KWP71 protocol ECUs, my best time for a cal download is 9 minutes

And here is my TODO list if anybody is curious:
1. Need to fully test write calibration to ECU, wasn't brave enough to try even once just yet
2. Figure out the upload/download bin/calibration thing and implement it
3. Real-time tuning is bind to the NVRAM stuff already but need to test it's actually working (it's probably not in its current state)
4. Find an issue that when disconnecting on the dashboard, when going to the tuning section, it should reconnect and detect NVRAM, it currently reconnect but doesn't detect the hardware for some reason.

I'm happy to test anything you need and not worried about trashing NVRAMs in the process. I can also log the raw comms traffic for you to help pinpoint collisions/disconnects etc if that helps.

[antus]

Looks good! Im happy to hook you up with oseplugin source and you can see the detection code and address range mapping for cal area in various bins and also some of the protections in there to stop people doing dumb things. Eg if the data to write is all null, reject it. If the cal upload version != detected os version, reject. And as jayme says, touching the code thats running the ecu is best to avoid as you can soft brick it. We recommend that anyone playing with this stuff has an eprom programmer on hand but many dont.

[3400tZ]

OK guys, more progress to report! It seems like "download calibration from ECU" and "download bin from ECU" are both working now. I worked on "Upload calibration to ECU" and was always getting no response from the ECU until I realized a "WR_EN" jumper was near the NVRAM chip and wasn't on there. I guessed WR_EN was for write-enabled (Josh, please tell me this was the right assumption ). Once I installed that jumper, I'm getting a 4 bytes response from the ECU and I'm not sure if that's OK. I ran out of time tonight to verify if the data I was writing was actually being written properly. That being said, looking at a log antus sent me from his plugin, I was expecting the whole command I sent (including the data) to be echo'ed back although it doesn't make much sense to me.

I believe another 2-3 evenings playing with this thing and it will be ready to go. Only the brave people (or the one that can salvage an NVRAM chip that was incorrectly written to ) will have a chance to give it a go soon I hope

[festy]

yep, WR_EN is write enable.

[antus]

Yep this is because the code area is writeable so the hardware supports write protection with that jumper. Its an insurance policy if your not planning on tuning. As you noticed, you get no response from the OS if the write fails, so the response you see is the ok, and timeout is failure.