Back in Part 10 of this CAN blog I talked about running custom code on the XNet hardware. With this functionality you can load up work to be on the hardware and have it manipulate the payloads of CAN frames, before they go out in a programmatic way. The main use of this that I've seen is it inject a Message Counter, and a CRC into the payload. This way you don't waste CPU cycles trying to calculate all the data that goes into a payload of a frame, and have it go out before the frame time is up. This also cleans up the code quite a bit since you don't have to constantly be recalculating payloads on the LabVIEW side. It is a pretty handy feature, and one that I was hoping NI would have documented or updated over the years. But since they haven't I will try to expand a bit on writing custom code for the XNet hardware, as well as talk about some new features I have built into the latest custom code.
XNet Custom Code Correspondence
Over the years I've been contacted by lots of people online looking to write their own custom code for the XNet hardware. Most see the potential but just don't have the tools needed to add the features they want to it. Most of the time I talk to people I will share what I have, how the tools work, and what I know about them. Which isn't all that much. So if you too want more features in your XNet Custom Code, contact me and lets see if I can help guide you into having the functionality you want, or what can be done. Posting all the tools here online, will likely increase support calls to NI about this feature that they don't officially support. And I would understand NI's frustration if that happened. So for now sorry I can't post all the tools used to make custom code online. It is some pretty simple C code that compiles down to an ENB file using Nios II Embedded Design Suite from Altera.
Autosar Profile 1A E2E
Profile 1
Recently someone contacted me asking about the Autosar Profile 1A E2E security features. I was unfamiliar with it but they linked me to the PDF describing the protocol. The changes needed to the custom code seemed fairly basic. The capabilities of the custom code already supported changing the polynomial and other CRC parameters. But there were a couple featured that would needed to be added. First was to add the ability to incorporate the CAN frame ID into the calculations. This would be the 11 bit (or 2 byte) CAN ID. The second feature missing was the ability to have the Message Counter reset back to 0 before hitting the maximum counter value based on the width of the signal.
There are a few other features that make Profile 1A unique but that the existing Custom Code supported. This was using the Initial and Final XOR values are 0x00 while still using the 0x1D polynomial. Additionally the CRC will be in the first byte of the payload, and the counter will count up to 14, not 15 for the 4 bit width. This counter is placed in the lower nibble of the second byte.
With this information in hand I was able to modify the custom code, and expose the inputs needed to set the counter maximum, and the CAN ID behavior.
Profile 2
Profile 2 uses a different set of polynomial being 0x2F, and the Initial and Final XOR set to 0xFF. This is also known as CRC8_8H2F. But a new feature had to be added to support the Safety Code. This appears to be a single byte added to the CRC calculation after the payload bytes. I'm unsure of the typical value for this but in the example this is set to 0x31. The CRC and Counter locations are the same between Profile 1 and 2. The Counter used in Profile 2 goes from 0-15 using all 4 bits which is the default.
Nissan CSUM Nibble Summing
I stumbled on video on
Youtube that talks about Nissan Leaf communications. One feature that is used that the custom code didn't have was the ability to sum all the nibbles in the way that was needed. So I added another set of functions that can be turned on and off just like the Message Counter and CRC. This apparently is called CSUM and just adds up all the nibbles in the message, then adds an additional arbitrary number. In this case the value 2. Then this is put back into the payload.
Updated Examples and Code
Here is the link to the Version 5 Custom Code example saved in LabVIEW 2020. Download it, extract it, and open the Example inside. There are 4 tabs demonstrating different features of the custom code, but the functionality is very similar between them, and it is similar to the previous iteration of the example.
The Custom Counter and CRC allows you to set various settings of a Message Counter and CRC. This tab will demonstrate how to configure the Message Counter, along with the new Max Value input, and the CRC with its new ID CRC input.
Nibble Sum is its own separate tab which does not enable the Message Counter or CRC. It is possible to enable these features at the same time, but unexpected results might occur if settings aren't correct while being used at the same time.
The J1850 settings only allow placing the Message Counter location, and CRC Location. All other settings should be hard coded on the block diagram.
Autosar 1A E2E Profile 1 has no settings to change since everything about it is defined in the protocol. All settings for it are on the block diagram.
Autosar 1A E2E Profile 2 Only has the Safety Code as an input. All other settings are on the block diagram.
Once the tab you want is selected, change the various controls and run the VI. From that point the XNet hardware will continually send out the frame you specified. The CAN Frame control on the bottom can be changed, and by clicking the Write it will send out the new single point value for that Frame. But as demonstrated the XNet hardware will now continue to take over and broadcast the payload with the various settings selected.
If you look at the source code you may have noticed that I removed the block diagram passwords on the Initialize CRC and Counter, and the Configure CRC and Counter VIs. These VIs use a couple of unexposed methods, but should do nothing dangerous. Still these are undocumented property nodes and can cause issues. There might not be any checking for a valid ENB file, and loading one could cause instability. I'd recommend just using these VIs how they are.
Conclusion
That's basically it. I wanted to make a new blog post saying the XNet custom code now supports a few more modes, and that I hope the community can find this useful. And if you want this to be a real supported feature I suggest going and voting for it over on the
Idea Exchange, and asking NI.
