Can_Setfilter() usage
Hey folks
I've been trying to implement the CAN Filters. To check it i tried the following filtersetting, thinking it might set the interface to accept only even identifiers and reject odd identifiers:
Can_SetFilter(ucCanChannelNo,0,2,0);
First parameter, ucCanChannelNo is a number from 0 to 3, depending on the Xc used.
Second parameter is the actual value that a message needs in the bits specified by the third parameter. The value for even frames is 0 in bit 1.
Third parameter is the mask, and the value 2 should set the mask to the lowest bit of the identifier according to:
#define MSK_CAN_RX_ACCEPTANCE_MASK_STD_RTR 0x00000001U // [0] #define SRT_CAN_RX_ACCEPTANCE_MASK_STD_RTR 0 #define MSK_CAN_RX_ACCEPTANCE_MASK_STD_ID 0x00000ffeU // [11:1] #define SRT_CAN_RX_ACCEPTANCE_MASK_STD_ID 1 #define MSK_CAN_RX_ACCEPTANCE_MASK_STD_DLC 0x0000f000U // [15:12] #define SRT_CAN_RX_ACCEPTANCE_MASK_STD_DLC 12 #define MSK_CAN_RX_ACCEPTANCE_MASK_STD_DATA_BYTE_1 0x00ff0000U // [23:16] #define SRT_CAN_RX_ACCEPTANCE_MASK_STD_DATA_BYTE_1 16 #define MSK_CAN_RX_ACCEPTANCE_MASK_STD_DATA_BYTE_2 0xff000000U // [31:24] #define SRT_CAN_RX_ACCEPTANCE_MASK_STD_DATA_BYTE_2 24
I only want to check for ID, no check on RTR, DLC or Databyte 1 and 2.
The last parameter means I'll use standard frames.
When i read back the filtersetting using:
Can_GetFilter(ucCanChannelNo,&ulTestCode,&ulTestMask,0);
then it will show the correct values, so they are actually set. However, all frames are transmitted, none are rejected. I also tried using extended frames in case my CANalyzer wouldnt use standard frames, no change. The filter never is used.
Am I interpreting some of the settings in a wrong way?
M T
Hilscher Gesellschaft für Systemautomation mbH
Hi HP,
Feedback took a while, as our software developers were out of office for the long weekend (public holiday on the 1st of May).
Did you use the latest XPEC codes (V1.005) which is included in the latest HAL sample, as a bug has been resolved concerning the acceptance mask/code filters. Mask and code were twisted inside the XPECs code.
Maybe this is already the issue you are mentioning.
Below is the build time stamp from the V1.005 XPEC code from xpec_can0.c
const unsigned long BuildTime_xpec_can0[7] = {
10, 21, 9, 16, 1, 107, 1171617670
};
Regards
MT
Hey MT
I completely forgot about that public holiday, because we didnt get it here :P
Thanks for the feedback. My XPEC codes are indeed outdated:
const unsigned long BuildTime_xpec_can0[7] = {
42, 22, 14, 15, 0, 107, 1168870962
};
I'm going to try with the new ones and report back with the result.
Ok, I updated my codes to the newest version, the problem still exists. I tried to set that filter to not accept anything, using mask 0xFFFFFFFF and code 0x00. Even then every message frame is accepted. I tried sending CAN-IDs ranging from 0 to 1F and from 7f0 to 7ff.
Any ideas?
Edit: I only updated the rpu_canx, tpu_canx and xpec_canx .c and .h files , the other files are still from can_hal version 2.1000 (plus some modifications because I use rcX).
M T
Hilscher Gesellschaft für Systemautomation mbH
Mh strange. It was supposed to work here. I will see if i can get a test suite and have a look at what might be going wrong.
Did you also exchange the can_xpec_regdef.h as the offsets for the registers might have changed (haven't looked at the layout yet).
PS: Could you try what happens if you exchange code and mask to see if they are not swapped anymore? Maybe it is still inside the microcode. I will crosscheck this here with the XC developer.
Regards
MT
Hey MT
I tried to exchange the values, still the same, all frames are accepted. I also checked the can_xpec_regdef.h, it's uptodate.
M T
Hilscher Gesellschaft für Systemautomation mbH
Hi HP,
I got another question, so the developer may check the internal code path.
Do you have any high priority indications enabled? Do you have some custom settings which affect the reception process, like Extended filters and such?
Regards
MT
Hey MT
Nope on both topics. I neither use high priority frames nor extended identifiers. I tried playing around with extended identifiers though, thinking that might be the problem, but those didnt work either.
Might it be that I have the same problem as in the other topic with the listening mode? In the original experiment I tried to set the filters during runtime of the Xc. I made a different test now, setting the filters after loading the Xc codes, before enabling it, but that didnt work either...
M T
Hilscher Gesellschaft für Systemautomation mbH
Sorry for the late reply. I did have some problems, getting my hardware running and getting a CANAlyzer.
We ran a test on the NXDB500-SYS with the CAN HAL 2.102 and the filter worked ok. We were calling Can_SetFilter right after starting it, as the filter should be configurable during runtime.
code snippet:
... Can_Start(CAN_CHANNEL_NUMBER); Can_SetFilter(CAN_CHANNEL_NUMBER, 0, 2,0); ...
The netX was answering only even identifiers, so the filter was active. The serial console printed the following (which shows, the filter was active and rejecting some frames)
port 00000002 stats: ulTxErrCnt : 00000000 ulRxErrCnt : 00000000 ulTxFrameSucceed : 0000026D ulTxErrorSummary : 00000000 ulArbitrationLost : 00000063 ulConDroppedDueFifoFull : 00000000 ulRxFrameSucceed : 000004C0 ulRxErrorSummary : 00000003 ulIndHiDroppedDueFifoFull: 00000000 ulIndLoDroppedDueFifoFull: 00000000 ulRxStdFramesFiltered : 00000253 ulRxExtFramesFiltered : 00000000 ulRxStdFramesPassed : 0000026D ulRxExtFramesPassed : 00000000 ulRxStdFramesHiDetected : 00000000 ulRxExtFramesHiDetected : 00000000 ulStatus : 00000000
Could you check the following offset inside the XC Memory, to verify your settings are written to the correct offset:
XC | Acceptance code | Acceptance Mask
0 | 0x17308C | 0x173090
1 | 0x17708C | 0x177090
2 | 0x17B08C | 0x17B090
3 | 0x17F08C | 0x17F090
Regards
MT
Hey MT
I checked those addresses in the memory, and they are always zero. However, I checked the addresses you mentioned, whereas you say those are offsets inside of the Xc Memories. I'm not sure where those memories are located, so I could add those values to the bases, but since the offset for the standard acceptance code is 108c and you're address is 0x17308C I do think those are absolutes. Could you please clarify this.
If i checked correctly, and those stay zero, then maybe it is because I'm using rcX, but I'm not writing those registers using rcX functions? I don't use the Can_Start function provided with your example, but an own initialization procedure running on rcX. However, the rest of the CAN interfaces works correctly.
Sorry if I'm just babbling, I just want you to have as much info as possible, because clearly the error seems to be somewhere on my side, but i dont see it :?
M T
Hilscher Gesellschaft für Systemautomation mbH
You are correct. Those values are absolute physical addresses. The XC RAM starts at 172000 for XC0, 0x176000 for XC1 and so on. So you need to add the relative offset given in the can_xc_regdef.h file to get the correct address.
So you can just use a "DWORD at 0x00173c80" Hiscript command for example. Make sure you pick the right address for the XC you are using.
I assume you are using Drv_XcWrite and such functions for the registers. Maybe there is something wrong with it. I currently don't know if these functions expect the offset from the beginning of the XC or if they take the offset from start of XC Ram. Maybe this is already the error. if your values don't get to the proper address the XC filters will stay disabled.
Strange thing that the rest is working. As i assume you are writing the IRQ configuration, etc. using the same routines as in the CAN_Setfilter. Did you used the Byte or DWORD offset in these functions. Could you compare the functions like enabling IRQs which is also a write to the XC Memory with the ones for setfilter. Maybe its just an off offset or something like that.
All Registers are in the XC Memory starting at 0:0x172000, 1:176000, 2:17A000, 3:17E000. The relative addresses in the header file always refer to these base addresses. Maybe you can see where the write inside your SetFilter functions leads by stepping into the function. It should mainly something like a "str r1, [r2]" which writes to the XC memory (Drv_XcWriteXc function).
Hope this clears up the fog a little ;)
Regards
MT
That's the problem then, I didnt change anything to rcX functionality in my Can_Setfilter method, I thought it wouldnt matter, after all the register should be written with a direct access too, not only using rcX methods :?
CAN_RESULT Can_SetFilter(unsigned int uChannel, unsigned long ulCode, unsigned long ulMask, int fExtended)
{
#ifndef __CAN_DISABLE_CHECKS__
if(uChannel >= DRV_CAN_MAX_CHANNELS)
return CAN_INVALID_CHANNEL;
#endif
if(fExtended)
{
unsigned long* pulCanXpec = s_atCanChannels[uChannel].pulMemCAN;
/* Filter for extended CAN frames */
pulCanXpec[REL_Adr_CAN_RX_ACCEPTANCE_CODE_EXT / sizeof(unsigned long)] = ulCode;
pulCanXpec[REL_Adr_CAN_RX_ACCEPTANCE_MASK_EXT / sizeof(unsigned long)] = ulMask;
} else
{
unsigned long* pulCanXpec = s_atCanChannels[uChannel].pulMemCAN;
/* Filter for extended CAN frames */
pulCanXpec[REL_Adr_CAN_RX_ACCEPTANCE_CODE_STD / sizeof(unsigned long)] = ulCode;
pulCanXpec[REL_Adr_CAN_RX_ACCEPTANCE_MASK_STD / sizeof(unsigned long)] = ulMask;
}
return CAN_OKAY;
}
So i just use Drv_XcWrite respectively Drv_XcRead to write/read to/from the appropriate registers (base address you mentioned plus relative offsets)?
If so, it would be nice to have a register description, if possible. I know I can get the info from the regdef.h, but "documented in C++" doesnt appeal to me that much :P
M T
Hilscher Gesellschaft für Systemautomation mbH
It should not matter if the value are written using rcX Methods or by direct register access. The XPEC registers are in a dual ported memory which is defined by the XPEC code.
The register layout is only described inside the xpec_can_regdef.h file and there is no documentation on this part. This is why there is a CAN HAL on the page to keep the user away from "bit fiddling" etc.
I wonder why your masks/code value don't reach the real xPEC registers, while other values like IRQ enable etc. are written correctly.
From what I understand you verified the values at the given addresses and they don't matched your code/mask values? The code you posted now, is the original CAN HAL code. Did you modify this with Drv_Xc_Write(hXpec, REL_Adr_CAN_RX_ACCEPTANCE_CODE_STD, ulCode) or did you leave it as in the sample? If you kept it this way, you might check where pulCanXpec is pointing too.
Regards
MT
Hey MT
It must have been something with the intialization of the pointer pulCanXpec which i did not right. This is the only function that actually used that, in all other places I used the rcX functions. I changed the setting of the registers to the following code:
if(fExtended)
{
Drv_XcWriteXc(pCanXcSettings->hXpecCan, REL_Adr_CAN_RX_ACCEPTANCE_CODE_EXT, ulCode);
Drv_XcWriteXc(pCanXcSettings->hXpecCan, REL_Adr_CAN_RX_ACCEPTANCE_MASK_EXT, ulMask);
}
else
{
Drv_XcWriteXc(pCanXcSettings->hXpecCan, REL_Adr_CAN_RX_ACCEPTANCE_CODE_STD, ulCode);
Drv_XcWriteXc(pCanXcSettings->hXpecCan, REL_Adr_CAN_RX_ACCEPTANCE_MASK_STD, ulMask);
}
Now it works like a charm :D
M T
Hilscher Gesellschaft für Systemautomation mbH
Good to hear,
Too bad I did not get that idea earlier to check the physical register values. This might have saved some time. But i am happy that it all works now.
MT
HP
Any feedback on this issue?