SDO communication after "SDO block upload end" is dropped

[martinwag]

When doing a SDO block upload and immediately after that starting another SDO request, this request is dropped.
This happens e.g. in the CANopen conformance test tool when checking SDO test 19 followed by 21. This is equivalent to the following linux commands

#do SDO upload block
cansend can0 67f#a0.00.10.00.14.00.00.00
sleep 0.1
cansend can0 67f#a3.00.00.00.00.00.00.00
sleep 0.1
cansend can0 67f#a2.01.14.00.00.00.00.00
sleep 0.1
#SDO block upload end
cansend can0 67f#a1.00.00.00.00.00.00.00
#immediately start next SDO communication
cansend can0 67f#C2.17.10.00.02.00.00.00

I've narrowed this down to the CO_SDO_receive() function. This receives the new request before the "SDO block upload end" message is processed, and therefore just drops it.
When looking at the spec, I can't find anything that would speak against having this sequence. I also think this is a realistic scenario for the client to just start the next request after one has finished.

From looking at the code, I have no idea how to fix this easily, at least for upstream...

I've also had a look at the other SDO transfer methods. They are not affected as the end message is always from server to client.

reference: CiA301, 7.2.4.3.12 Protocol SDO block upload

[martinwag]

This dirty hack makes it work when using FreeRTOS Threads for receiving and processing.

static void CO_SDO_receive(void *object, const CO_CANrxMsg_t *msg){
    CO_SDO_t *SDO;

    SDO = (CO_SDO_t*)object;   /* this is the correct pointer type of the first argument */

    extern void vTaskDelay( const uint32_t xTicksToDelay );
    while (SDO->CANrxNew) {
      vTaskDelay(1);
    }
...

[CANopenNode]

Block transfer is quite complicated and large part of code and it needs fast response. SDO->pFunctSignal(); should be used with RTOS.
However, problem you describe still exists and one solution is, as you describe.

I think, I should make SDO block transfer as optional feature in CANopenNode. It should be possible to not include it's code. I think, it is not very widely used and it may add unnecessary memory consumption.

Another thing to consider is block transfer in future editions of the standard. I checked the latest 301 proposal, which includes also CAN FD messages (64 bytes long). SDO transfer is quite different there and block transfer is not used.

For now, I think, careful integration with RTOS is best practice. I added a note into the stack.

[martinwag]

I think, I found another issue with the used message handling (#48).
For my case, I'm actually using block transfer mode.

[CANopenNode]

The only problem is SDO block upload immediately followed by another SDO request. This is the situation, where two client requests (SDO block upload end and next SDO initiate) are transfered without server confirmation between (except block download segment, which is correctly handled by the stack).

One clean solution would be with double SDO->CANrxData buffer inside CO_SDO_receive (or short FIFO). Something similar is used for synchronous RPDOs inside CO_PDO_receive.

[lukegluke]

Hi. Faced the same issue in master branch.
This issue was post long ago, maybe @martinwag you had fix it more accurate than with delay?

By the way, @CANopenNode block transfers work quite well, thank you for your work!

[martinwag]

@lukegluke, no I didn't fix this as block upload is only used once (as last command) in my application. Proper way is using a queue for data exchange.

[CANopenNode]

I'm not quite sure, how is with this issue now. Currently we have:

• new Object Dictionary approach, rewritten and tested SDO server in CANopenNode version 4.0
• rewritten and tested SDO client in CANopenNode version 2.0 and above
• no additional information for old Object Dictionary and old SDO server.
  I'm closing this issue for now. If there will be problems with old SDO server, new issue should be opened.