Problems with RPDO dummy mapping - potential array out of bounds write

[Florian-2718]

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

[mrk-its]

I had to fix this code on my branch this way: mrk-its@3818dee

[michael-hillmann]

You are absolutely right! Thanks for this issue, we will write tests for some RPDO-Dummy use-cases and use the mentioned fix afterwards.