UDS Ecu reset function always get error 8260

[Jzhouj]

Hello every,

I am new in this toolkit. I tried to use Ecu reset function to implement hardware reset, but always get error.

I have successfully test the tester presenter function and Ecu response correct 0x7E. How can I solve it? Thanks.

[ZY_Ong]

Hi Jzhouj,

Kindly please refer to Error -8260 with Automotive Diagnostic Command Set.

The easiest way is to use the Transmit feature of NI-XNET Bus Monitor, which allows you to change baud rate, ID and payload setting quickly. If you are able to find out the correct frame that ECU will response to (perhaps thru a third party tool), I can advise how to configure it with NI ACDS Toolkit.

[jzhou2000]

Hi ZY_Ong,

Thanks for the reply. I am using NI XNET USB-8502. I tried different ACDS Toolkit like tester presenter and request key and they all works will, I use same CAN configuration. So I am not sure why only the ECU rest not working.

Jingyang

[ZY_Ong]

Hi jzhou2000,

Perhaps your ECU does not support the Hard Reset of UDS Reset Service.

You can try using different modes of UDS ECUReset.vi

[jzhou2000]

Thanks for the reply. We used Python script before and confirmed that the hardware reset service is working for the ECU. Also for other UDS services.

[kayfh]

Hi,

the ECUReset service is a bit special because the (positive) response could be send before (recommended) or after the ECU has performed the reset. If it's sent afterwards, of course a larger delay between request and response could happen depending on the ECU.

Is the ECU performing the reset after you've executed the ADCS VI? If yes, increasing the timeout for the response (property "Timeout Diag Command") to how long the reset typically takes + some safety margin, could prevent the error.

[Hooovahh]

That's good to know.  In the past I've actually just used the ECU Reset command as asynchronous.  It will send the request to reset, then have an arbitrary small amount of wait (1 second), and then add a request to read a DID with a small timeout like 500ms.  This is in a while loop trying again and again until a response is seen and then the reset is considered complete.  I've seen times that there isn't a response from the ECU Reset before, or after the reset finishes so this seems to be a bit more robust.  That is unless the ECU doesn't reset at all and then the DID read will have a response but nothing will have happened.

[jzhou2000]

Hello Hooovahh,

Thanks for the reply, I want to ask which DID you read, I am trying to use UDS ReadDataByIdentifier.vi but always returns error 8049.

[Hooovahh]

Error -8049 is generated as a response from the ECU.  If you get error -8049 then the ECU is awake and responding properly.  So if this was used as a strategy of seeing if an ECU is done with its reset then getting error -8049 would mean it is ready.

As for why you are getting error -8049, that is because the error is generated as a negative response from the ECU stating that the ID you tried to read was outside of the range of IDs the ECU will respond with data for.  DIDs are sorta like memory addresses.  It isn't exactly like this of course but stay with me.  When you get that negative response it is like the ECU saying there isn't any memory where you just tried to read.  Each ECU will have a different set of DID IDs that it will respond to.  And in some cases it will respond to a DID, but only in certain circumstances.  For instance there might be some low level information associated with a setting of how the ECU works, and it doesn't want to share that information, until you unlock it, or go into some extended, or programming session type first.

So if you are asking what IDs your ECU responds to, and in what circumstances, you'd need to consult the manufacturer of the ECU and software.  If that's not possible you can just start guessing.  There are 0xFFFF possibilities.  I'd start at 0x0000, 0x1000, 0x2000, etc.  Then start counting up from there.  Of course even if you get a response, unless it is in ASCII you won't know what it means.  Lets say you requested DID 0x3000 and it gives a positive response with the data 0x01.  What does this mean?  Is this a mode?  Is this some memory address?  Is this the state of some internal state machine?  In some cases it will return an array of bytes that is ASCII and you might get something like a VIN, or software version, or manufacture date.  But my point is without intimate knowledge of the ECU, its functions, what DIDs it returns, and what they represent, you likely won't get much useful information.

[jzhou2000]

Thanks for the reply, I think I  can get the response from the ECU when read 0xF081.

I have another question. I have a .hex file, is there way I can obtain the hex file information such as sectors, start and end address and the total size? I now can only read the text. Thank you!