I trying to read a DTC from a CAPL script. I am using "(0x19) ReadDtcInformation - Report DTC snapshot record by DTC number" protocol service. My DTC number is 0x062003. I am able to set DTC number correctly. But, I am not able to set DTC status bits.
1. diagRequest FR_Diagnostic.FaultMemory_ReadEnvironmentData PWM_Status; // 0x19 0x94
2. diagSetParameter(PWM_Status,"DTC",0x062003); // 0x06 0x20 0x03
3. diagSetParameter(PWM_Status,"DtcSnapshotRecordNumber",0xFF);
4. DiagSendRequest(PWM_Status);
Line #3 is not quite setting DtcSnapshotRecordNumber to 0xFF. I see this field as 0x00 in trace.
Question:
1. Am I using correct API in line #3? How do I set DtcSnapshotRecordNumber to read for all the status bits? (there are 8 status bits to monitor, thus it should be set to 0xFF).
Normaly you call service 0x19 (Diagnostic) then call Subfunction and then you provide a bitmask which contains information for what you are searching.
So everything you need is defined in ISO 14229 Road vehicles.
Most services regarding DTCs and OBD stuff are the same across all OEMs. Each OEM normaly has a Diagnostic Specification Supplement which describes OEM specific Diagnostic services and so on.
In CAPL there is normaly an easy way to read out DTCs. You don´t need to do it manually as it is provided by the CDD-File. You can see it in the Object Browser of CAPL Brower on the right side.
So for your case for egg. retrieve number of DTCs which match your Mask:
Subfunction Report DTCByStatusMask 0x02
0x1902
The mask which is your search filter will be build like this:
bit # hex state description
0 0x01 testFailed DTC failed at the time of the request
1 0x02 testFailedThisOperationCycle DTC failed on the current operation cycle
2 0x04 pendingDTC DTC failed on the current or previous operation cycle
3 0x08 confirmedDTC DTC is confirmed at the time of the request
4 0x10 testNotCompletedSinceLastClear DTC test not completed since the
last code clear
5 0x20 testFailedSinceLastClear DTC test failed at least once since last code clear
6 0x40 testNotCompletedThisOperationCycle DTC test not completed this operation cycle
7 0x80 warningIndicatorRequested Server is requesting warningIndicator to be active
So if you just want to read out DTC which are confirmed (stored) than you send:
0x190208
If you get a positive response than the DTCs will be retrieved in Hex Format. You´ll need a HEX->SAE converter which will convert retrieved DTCs to regular know format. Anyway you can Test it through Diagnostic Console.
Answering myself:
Yes, I was using the correct API.
It wasn't getting set properly because the datatype used in the database (.cdd) files was wrong.
I could have converted .cdd file to template and edit the template and work with updated .cdd file, but I chose to work it out using a fresh template copy.
Related
Currently I am reading the MDB_interface_specification( (https://namanow.org/wp-content/uploads/Multi-Drop-Bus-and-Internal-Communication-Protocol.pdf) Version 4. 3(July 2019). In Kapitel 2.3 page 34 they are talking about the Peripheral Address and I don't undrstand how the Address scheme has been built . One prototy of the address scheme look like this: 00101xxxB ( this can be 28H for example ). They upper five bits are used for addressing and the lower 3 bit are the command. If i considered this statement wih my example then the address ist 5 and the Command is 0. I am a little bit confuse can someone please explain me that?
OK. First, read this:
Then, we have value 0x00 as command to Energy Management System (huh, i never saw this kind of MBD device in the wild). MDB datasheet doesn't contain any references to this device yet, but seems it's just POLL command, device must respond to POLL with last status changes (if any) or just ACK with x100 - it's not mistake, it's 0x00 with 9th bit set. Don't read this datasheet unless you want to lose your mind. I am already read this awesome shit and put it (mostly) to hardware implementation see github repo with complete solution
Cheers.
I'm using a PIC18 to write to SD cards via SPI. For many cards, this is working file BUT for some cards I pass the init process but when trying to write to the card, CMD24 returns 0x05 (which I believe is a CRC error)
// send CMD24 - preparing for a 512 byte block
SD_command(CMD24, 0x0001, CMD24_CRC);
// read response
res1 = SD_readRes1(); //This returns 0x05 for some cards!
I have used CMD59 - CRC_ON_OFF with parameter 0x00 to turn of CRC, and the command seems to complete. Is there something I am missing?
I read a comment of someone on a forum, who spent one week looking for an error in this code. In his case, he found that with some sd cards, he has to put a valid crc in the sd command, whatever the state of crc check option (cmd59).
Maybe it is simpler to put a valid crc in all cases.
I'm using an NTAG I2C plus 2k memory tag and am able to successfully perform a FAST_READ for a particular page address range, but just beyond the range I'm getting an error.
iOS
Start address 0x04 and end address 0x46 reads successfully
await cmd([0x3a, 0x04, 0x46]);
while, start address 0x04 and end address 0x47 fails with
await cmd([0x3a, 0x04, 0x47]);
Error
input bytes: 3A0C0C
input bytes: 3A0447
[CoreNFC] 00000002 816c6760 -[NFCTagReaderSession transceive:tagUpdate:error:]:771 Error Domain=NFCError Code=100 "Tag connection lost" UserInfo={NSLocalizedDescription=Tag connection lost}
Android
Start address 0x04 and end address 0x49 reads successfully
await cmd([0x3a, 0x04, 0x49]);
while, start address 0x04 and end address 0x4b fails with
await cmd([0x3a, 0x04, 0x4b]);
Error
D/NfcService: Transceive start
D/NfcService: Transceive End, Result: 0 mTransceiveSuccess: 1 mTransceiveFail: 0
D/NfcService: Transceive start
D/NfcService: Transceive End, Result: 2 mTransceiveSuccess: 1 mTransceiveFail: 1
D/ReactNativeNfcManager: transceive fail: android.nfc.TagLostException: Tag was lost.
I/ReactNativeJS: Error: transceive fail
Thanks in advance.
From the Tag's datasheet
Remark: The FAST_READ command is able to read out the entire memory of one sector with one command. Nevertheless, the receive buffer of the NFC device must be able to handle the requested amount of data as no chaining is possible
When I do a FAST_READ on a similar Tag type on Android in native code I do a getMaxTransceiveLength to find out how big the buffer is and divide that by 4 and round down to find the max number of pages a FAST_READ can do at once and break up in to multiple FAST_READ's if necessary.
Generally the max Transceive length is 253 bytes on Android or 63 pages.
The react-native-nfc-manager API for Android also has getMaxTransceiveLength in it's API so you can do the same calculation of the maximum pages a FAST_READ can do on your hardware.
I've not done FAST_READ's on iOS but expect there is a similar limit (it does have an error code for transceive packet too large but I've not seen a way to ask it the max transceive length before you send a command)
While probably getMaxTransceiveLength is meant for size of sending command this amount of bytes should be able to be returned before the transceive timeout is hit, as the send and receive data rate is identical.
The transceive timeout can set but not got using react-native-nfc-manager API
Again no options on changing any timeout values in iOS but there is an error to indicate that the communication to the Tag has timed out.
So you could try increasing the timeout value on Android instead of breaking up in to a number of FAST_READ's but working out how long the timeout should be could be difficult and might have a negative impact if you set it too big.
For Android it's probably easier to assume the max send size is safe to receive as well. For iOS assume a max receive size from your experiments or handle the error and re-read with a back off algorithm.
How do I resolve obtaining the wrong value in the W-register after a MOVF operation?
I am debugging a code which builds & programs successfully, but does not have the desired result when powered up as part of the circuit and I have noticed that the working register does not contain the right value after a MOVF operation, whilst debugging.
If the value that is being copied to the W-reg is manually written in during debugging, then the code functions as it should.
The following images, I believe, illustrate the my issue quite well.
1. Port definition.
2. LEDportA value of 0x02 is to be moved to the W-reg.
3. After the operation, W-reg contains 0x00, instead of 0x02.
4. Final image shows that LEDportA is the same as LATA, as it is cleared after the "clrf LEDportA instruction.
I am totally bewildered as to what could be causing it and any insights or advice that anyone can provide will be very much appreciated.
Please note that the PIC MCU in use is the PIC16F1829.
Since you don't provide enough information like PIC model you are using and the rest of the code, as far as I see, your problem is because of wrong bank selection. Your TempC register is located 0x70 in bank 0, and the LATA register is located at 0x10C bank 2 in memory. Thus when you attempt to read the LATA, actually you read the corresponding 0C addres location in bank0. You have to switch the correct bank before you attempt to read or write from any register in RAM. Check the code snippet that has right way to access to the registers. You can switch to a bank either using the BANKSEL directive which is more convenient for programmers or loading a bank value to the BSR (Bank Select Register).
UpdateDisplay:
BANKSEL LEDportA ; Switch to LEDportA bank before any access
MOVF LEDportA, w
andlw 0x0f
BANKSEL TempC ; Switch to TempC bank before any access
movwf TempC
bsf TempC, 4
rrf TempC, F
btfss STATUS, C
bcf TempC, 3
btfsc TempC, 0
....
I'm using PIC32MZ2048EFG100, MPLAB X IDE(v5.00), Harmony(V2.06) and ICD 3 debugger.
In my project, I've configured the address 0x9D100000 (up to 432KBytes) for NVM operations to store some data.
To verify the NVM operation, I'm just doing NVM operation for the first block only. i.e address 0x9D100000.
I've erased(16KBytes) the 0th block(address 0x9D100000) and I read device memory and the result is correct. i.e all 0xFF values.
Now I'll write(2Kbytes) into this memory(address 0x9D100000) using 2Kbytes buffer which is set to value 0x55.
After writing, if I read device memory, only some of the addresses will be set with the value 0x55 and the rest of the memory will be set with the 0x00 value.
Why this memory is getting corrupted?
Please help me to know the details to resolve the issue.
Thank you