Nanocom Evolution SD Card not reading

All you can do is try it out.

It's worth formatting the card before you load the .map file. This ensures the file is written in contiguous chunks to the start of the card which should help the Nanocom read the map file cleanly.

It's also been suggested that you should save the .map file direct from your email program to the sdcard rather than copying from you hard drive. I haven't tred this personally but I have it on good authority that this dramatically improves the odds of a successfully uploading a .map file.

cheers
Paul

Adrian

Your question is a little confusing as you state that you have sucessfully read a Map file to your 4GB SD card and so it is clearly "working" and accessible by the EVO. So it is hard to understand what you are actually asking.

All i can do is tell you what i know.

The improvements that have been made to the Evolution are not really to do with the FAT system but more to do with adding support for SDHC cards.

In reading or writing a Map file, the Nanocom Evoultion is really just the piggy in the middle. If the ECU or the SD card rolls over during either the read or write data transfer process, there is not really much that the Nanocom can do about it.

Colin,

I think there may be a few issues at play...

If the Nanocom is using the Microchip supplied FAT libraries there does seem to be widespread issues relating to write/read speeds from developers. The Microchip forums have a number of threads dealing with access speed issues. From a quick scan it looks like many users are recommending use of FATFs ( FatFs - Generic FAT File System Module ) instead.

The second thing I've come across is that the SDCard Consortium claims that OS supplied disk utilities don't format SD Cards in a way that gives optimal performance! The recommended formatting tool can be downloaded from https://www.sdcard.org/downloads/formatter_3/

Versions are available for Windows and Mac.

I haven't tried this out as yet so can't report on improvements or otherwise.

cheers
Paul

NB: On OSX the program will not access SDCards without elevated access permissions but doesn't provide the usual dialog to do this.

You can side step this problem by opening

/Applications/Utilities/Terminal

And at the command prompt type

Code:

---

sudo /Applications/SDFormatter.app/Contents/MacOS/SDFormatter

---

then hitting return. You'll be prompted for an administrator password. Assuming you are using an account with admin privileges, type your password and hit return. This will launch the formatter program with correct privileges.

PJ

Hi Paul

I followed your suggestions, reformatted the card (using coincidentally the same SD Card Association formatter) to FAT32, and saved the new .map file directly from the email. The subsequent downloading of the .map file using Nanocom Evo went flawlessly.

Conclusion: Evo can use a FAT32 - formatted SD Card.

Thanks for your assistance.

Hi Colin

I emailed this query to you but it bounced back seemingly due to my internet provider and something called SPF. Due to the potential for an expensive failure in remapping, and my own weakness in the IT field, I took a cautious approach which included reading your information sheet on the reading/writing to the engine ECU. This sheet specifies using SD formatted to FAT, and not to FAT32 - hence my query on this. Also, I could not find a Formatter on the web that could do the old FAT(16).

Thanks for coming in on this thread.

Cheers guys
Adrian

This might be a bit over the top but I seem to have improved reliability of uploading .map files on my Nanocom by doing the following:

SD Card Prep

1) Low level reformat of SD Card.
I used HDD-LLF HDDGURU: HDD LLF Low Level Format Tool to do this. It leaves the card unpartitioned and is pretty slow.

2) Format SD Card with SDFormatter ( https://www.sdcard.org/downloads/formatter_3/ )

3) Move .map file to SD Card
Following a tip from JustFishing in another thread I've tried to avoid copying the .map file to the SD Card. I used Td5 Map Editor ( td5 map suite ) to open the .map file then used "Save As" to write the file to the SD Card. Saving from email program probably does the same thing.

Uploading .Map file

1) Ensure battery is in good condition and fully charged.
If you can take the vehicle for a long run (1-2 hours at highway speed is ideal) the day before this will help ensure the battery is a good charge.

NOTE: Avoid trying to do the upload when the D2 is hot as there is potential for the air conditioning fan to switch in/out to assist engine cooling.

2) Turn off all accessories (air con, stereo) and shut doors so interior lights are not illuminated.

3) Insert SD Card into Nanocom, connect cable to Nanocom, connect cable to OBD-II port, and turn ignition to position 2.

4) Once the Nanocom has started up, go to the Td5 Map application, and "Read Map from ECU" to verify that communications with the ECU and ability to write to SDCard are ok. If either step fails do not proceed any further until you have identified and rectified the cause.

5) Turn Ignition off

6) Disconnect Nanocom from OBD-II port, wait 30 seconds, then reconnect.

7) Go directly to the Td5 Map application and select "Upload Map to ECU".

8) Follow the directions given on the screen to upload .map file

NOTE: If the "Protection Verify" progress bar jumps from about 10% to the "Ok to upload map?" dialog, I strongly advise you abort the upload and return to step 6. If you proceed it is guaranteed that the upload will fail at some point before it completes.

I've gotten into the habit of leaving the Nanocom sitting on the lid of the cubby box while doing the entire process, and I don't touch the Nanocom, or cable at any time. Also leave the doors in the same state as when you began the upload.

cheers
Paul

Hiya Paul

Thanks as ever to your seemingly endless efforts in helping other owners and BBS in figuring out such odd problems as this.

It is becoming apparent that there is something going on that makes the Nanocom Evolution seem iffy when it comes to reading and writing map files, such that those using it for this task on a regular basis will eventually end up with an ECU that needs manually reprogramming.

Not good for anyone, and not something i can or will ignore and since this is now one of the last few aspects that seems to cause trouble, it is high time that we looked into it more deeply.

Over the last 10 days i have had my guys extensively testing many Evolution 2 units, including one sent back with reports of flashing problems, as well as the origional Evolution's, evolotion one's and the MSV-2 in differing situations encompassing an ECU only test rig, a Full Disco II in the form of a complete wiring loom with all other ECU's present, that has been powered by a power supply, A battery alone and a battery with a high power charger on.

It is a pretty slow process and we intend to spend a lot more time collating sufficient results such that we can compare the resultant data in a meaningful and accurate way.

However, even at this stage, power is not looking like half the problem we once thought it was and i am quite convinced that you are onto something in respect of the nanocom's SD card access being its main problem in this feature.

There have however also been a few instances where the TD5 ECU has simply not replied to a read or write command and in this case the Evolution just errors but the MSV-2 often overcomes this due to it's coding employing a retry element the Evolution does not currently have.

In fact it is a bit more detailed than this as quite some time ago we discovered that when asked for a block of memory, very occasionally, for no explicable reason the TD5 ECU would reply with data that was just random rubbish. To overcome this the MSV-2 program was changed to read every block of data twice and compare the results. If they match fine but if not we re read the block a third time and re compare, using the data from the 2 matching reads.

Although it will make things a lot slower, i am thinking to appy this methodology along with retry coding to the Nanocom Evolution, and am even looking into the possibility of implimenting a scratch file in the Evolutions Firmware memory to pre copy Map data into and out of rather than rely on the SD card.

Hi Colin,

Thanks for the detailed response. I have to admit there is a large element of self-interest in getting to the bottom of the flashing difficulties as I've had to revive my ECU twice after failed uploads thus far.

I've been told by one Td5 tuning firm that the One is significantly more reliable for uploading maps. I'd have to assume that if this is actually the case then implementing memory buffering on the EVO might go a long way to making map uploads less finicky?

cheers
Paul

Hiya Paul

I think most folks will appreciate me / BBS being open and totally honest about any problems the Evolution may still have. With your and many other members help, regardless of your motives, we have collectively not only saved the Nanocom from possible extinction but turned it into a total sucess.

That is not really a bad result for anyone and is a true Team effort.

The Nanocom one of course shares the same methodology and base code in respect of its Reading and Writing commands to the TD5 ECU, so any difference must be due to the difference in the memory it also uses during the process to read / write the data to.

I plan to impliment not only additional retry coding that may counter any ECU problems but also to try and pre / post buffer files off the SD card to a more stable memory.

I am sure you would be willing to help us beta test if these changes improve things sufficiently.

Quote:

---

Originally Posted by OffTrack

Hi Colin,

I've been told by one Td5 tuning firm that the One is significantly more reliable for uploading maps. I'd have to assume that if this is actually the case then implementing memory buffering on the EVO might go a long way to making map uploads less finicky?

cheers
Paul

---

That´s what I´ve experienced with the evo!!

I dont remember having one single problem with the nanocom one in terms of reading/uploading map or tun files. In fact, I have an evo lying around at the office and still prefere the nanocom one.

Funny thing is that, with the nanocom one, I´ve managed to recover some Ecu´s wich crashed during the upload process with the Evo.

Regards

td5inside

The most significant difference between the One and the Evo is in where the data / file is read from.

As expressed, our testing so far is all encompassing, as we really want to figure this discrepancy out no matter what and so far everything i have seen so far totally supports Pauls belief that it is all down to the SD card aspect.

We are now testing the effects of file fragmentation on the SD card amongst other things.

Paul.

It seems that other than in the initial comms with the TD5 ECU that the retry function in the event of an initial non response by the TD5 ECU is actually already implimented, but i will be testing that to be sure it is working as it should be.

But before close of business tomorrow i expect to have a version of the software that automatically pre copies a file chosen to be written to an ECU from the SD card to the firmware memory before writing this to the ECU.

I hope you will be ready to test this