You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello,
The functions "CORPdoGetMap()" and "CORPdoWrite()" show potentially uncorrect behaviour when RPDO dummy mapping is used.
In the CiA 301 document there is stated for the Receive PDO Mapping Parameter (1600h - 17FFh) that if
data types (1h..7h) are mapped, then these entries serve as dummy entries and the corresponding data is not evaluated by the device.
The EO CANOpen stack supports this feature, see functions "CORPdoGetMap()" and "CORPdoWrite()".
But in the named functions I recognized the following problems:
"CORPdoGetMap()":
Let's assume there are mapped 8 objects:
Subindex 1: 0x00020008 - Dummy entry with length 1 Byte
Subindex 2: 0x00020008 - Dummy entry with length 1 Byte
Subindex 3: 0x00020008 - Dummy entry with length 1 Byte
Subindex 4: 0x00020008 - Dummy entry with length 1 Byte
Subindex 5: 0x00020008 - Dummy entry with length 1 Byte
Subindex 6: 0x00020008 - Dummy entry with length 1 Byte
Subindex 7: 0x00020008 - Dummy entry with length 1 Byte
Subindex 8: 0x60400008 - Length 1 Byte , reference to index 0x6040
==> Then the access to "pdo[num].Map[]" and to "pdo[num].Size[]" will be performed with index 14 ("on + dummy") for
the subindex 8, where index 7 is the highest valid subindex of the array "pdo".
This would equal a array out of bounds write action.
"CORPdoWrite()":
Let's assume that between two "normal" entries a dummy entry exists, then for this dummy entry the variable "dlc"
won't be incremented and afterwards the access regarding the CAN-frame will be performed on the wrong (too low) indices.
I hope my assumtions are correct.
Best regards,
Florian
The text was updated successfully, but these errors were encountered:
Hello,
The functions "CORPdoGetMap()" and "CORPdoWrite()" show potentially uncorrect behaviour when RPDO dummy mapping is used.
In the CiA 301 document there is stated for the Receive PDO Mapping Parameter (1600h - 17FFh) that if
data types (1h..7h) are mapped, then these entries serve as dummy entries and the corresponding data is not evaluated by the device.
The EO CANOpen stack supports this feature, see functions "CORPdoGetMap()" and "CORPdoWrite()".
But in the named functions I recognized the following problems:
Let's assume there are mapped 8 objects:
Subindex 1: 0x00020008 - Dummy entry with length 1 Byte
Subindex 2: 0x00020008 - Dummy entry with length 1 Byte
Subindex 3: 0x00020008 - Dummy entry with length 1 Byte
Subindex 4: 0x00020008 - Dummy entry with length 1 Byte
Subindex 5: 0x00020008 - Dummy entry with length 1 Byte
Subindex 6: 0x00020008 - Dummy entry with length 1 Byte
Subindex 7: 0x00020008 - Dummy entry with length 1 Byte
Subindex 8: 0x60400008 - Length 1 Byte , reference to index 0x6040
==> Then the access to "pdo[num].Map[]" and to "pdo[num].Size[]" will be performed with index 14 ("on + dummy") for
the subindex 8, where index 7 is the highest valid subindex of the array "pdo".
This would equal a array out of bounds write action.
Let's assume that between two "normal" entries a dummy entry exists, then for this dummy entry the variable "dlc"
won't be incremented and afterwards the access regarding the CAN-frame will be performed on the wrong (too low) indices.
I hope my assumtions are correct.
Best regards,
Florian
The text was updated successfully, but these errors were encountered: