How to collect and save the XCP data ?
Closed this issue · 15 comments
Thanks for this useful and amazing work!
Hello, I'm a rookie in the vehicle industry. Recently, I started to collect and record xcp data. At the same time, I noticed that besides pyxcp, you also have an open source project called pyA2L. I would like to know if it is possible to read .a2l files via pyxcp and pyA2L while saving the received ECU data. If it is possible, can you give me some guidance on what should I do? Thank you very much!
XCP based measurement and calibration is a highly complex subject. To start with, I highly recommend
The XCP Reference Book by Vector Informatik.
I'm also working on a project
asamint (ASAM integration package)
which aims to simplify common workflows using packages like pyxcp, pya2ldb, asammdf, ...
(still much work to do…)
Let me know if you have any specific questions.
OK, thank you for the reply!
I will start with the two links you recommended. If I have any specific questions later, I will ask you again. Thanks again.
Hi, christoph !
In the process of using pyxcp, there is an ecu .a2l file that defines CAN_ID_MASTER as 0x4000051A, and CAN_ID_SLAVE as 0x4000051B. This caused pyxcp to report an error at runtime:pyxcp.transport.can.IdentifierOutOfRangeError: 11-bit identifier 'xxxxxxx' is out of range. So I have the following two questions：
- I see that the code uses this statement “(identifier & CAN_EXTENDED_ID) == CAN_EXTENDED_ID” to determine whether it is an extended frame. Obviously this statement does not work for can_id like 0x4000051A, is this expected ？
- Even if the program successfully determines that the id is an extended frame, it will still report an error because of the statement "if self._id > MAX_29_BIT_IDENTIFIER".Is it because the can_id in the a2l file itself is illegal?
This a2l file looks like this:
Any reply from you will help me a lot, thank you !
Well, CAN_EXTENDED_ID is defined as 0x80000000 which is used per convention to signal extended identifier in several cases (including Autosar). Without a special value it would be undecidable if IDs <= 0x7FF are standard or extended.
(Wasn't 0x40000000 RTR, which nobody should use?)
Yes, from this point of view the behavior is intentional, but I could add a check for values that are clearly extended.
Just to be curious: Which software generated your A2L?
OK, maybe there's some additional configuration stuff neccessary to interpret the highest bits.
For the current Autosar release the following holds:
The two most significant bits specify the frame type:
- 00 CAN message with Standard CAN ID
- 01 CAN FD frame with Standard CAN ID
- 10 CAN message with Extended CAN ID
- 11 CAN FD frame with Extended CAN ID
Can you confirm that you are using CAN-FD in this project?
The latest patch d0e2e65 now masks out the three most significant bits, i.e. your identifier should be recognized as 'standard'.
Wow✨, your replies really help me a lot ! Thank you very much, and i'll keep trying. By the way, The A2L file I used was generated by the software provided by HiRain Technologies.
Hi,christoph.
With your help, I successfully connected the ECU and obtained the measurement data through 'shortUpload', and configured DAQ to realize the Synchronized measurement of some variables. But when I increased the number of variables in DAQ, I encountered two new problems:
- Use the following command:
xcp_master. freeDaq()
xcp_master.allocDaq(1)
xcp_master.allocOdt(0, 60)
for idx in ... :
xcp_master.allocOdtEntry(0, idx, len(odt))
When executing 'allocOdtEntry' for the 39th time, it will prompt 'ERR_MEMORY_OVERFLOW', it may be that the ECU cannot record so many variables, or I have a problem with the settings, how should I check for this error?
- After increasing the number of variables, I found that some variables were not parsed correctly. In the XCP document, I noticed that the DTO package contains the FILL field. Some ODTs have this field, but others do not. How should I judge?
Thank you again!
By the way, i use pyxcp on CAN FD, and run it on nvidia jetson xavier platform.
ERR_MEMORY_OVERFLOW in the context of DAQ allocation almost certainly means dynamic configuration memory is exhausted.
Honestly, I don't understand the purpose of the construct len(odt) -- maybe you are trying to allocate way to much ODT entries unintendedly?
The FILL byte ensures that following values greater one byte are evenly aligned.
Consider the following:
#include <stdint.h>
void foo_function(uint8_t * pb)
{
uint16_t * pw = (uint16_t*)pb; // Now a 16bit pointer var has an odd address!
}
int main()
{
uint8_t my_var = 0x42; // May located @ an odd address, e.g. 0x2345,
// which is OK for byte-sized variables.
foo_function(&my_var);
return 0;
}Looks innocent, but it isn't -- misaligned access may require some more clock-cycles on many architectures,
but on others this may trigger a bus-trap or similar exceptional state (with more or less catastrophic
consequences...)
Classic case of undefined behaviour according to ISO-C.
Wow! Good news, christoph. With the help of you and pyxcp, I have successfully obtained and parsed the value of my target variable from the ecu via DAQ. And i think this issue can be closed.
Thank you very much!🌟
Hi guys,
I have created an XCP example which receives and decodes data in daq list. I would be happy to share it.
Is it possible to become a contributor?
I also found a bug in the python can driver, which i corrected.
New contributors are always welcome, just send a pull request.
Regarding DAQ: The christmas release will contain a DAQ related C++ extension module...
i just tried to create a branch and then a PR:
$ git push --set-upstream origin XCP_python_can_DaqListsBugfix
remote: Permission to christoph2/pyxcp.git denied to SaxElectronics.
fatal: unable to access 'https://github.com/christoph2/pyxcp/': The requested URL returned error: 403
i get access denied, I think you have to include me in contributors to be able to create the PR.
You can't directly push to pyXCP, create your PR from your fork. Here is a Github guide.
here i created the pull request. Some precommit hooks are failing. Not sure why and how to resolve these...
Bugfix is tested with real ECU.