Error Detection on Virtual Channels

The size of each message sent with chan_out_word and the other message-passing calls must exactly match the size expected by the receiver. Failure to follow this rule for physical channels, or for internal channels between tasks on the same processor, usually results in the application hanging or crashing. One benefit of virtual channels not mentioned previously is that the Virtual Channel Router (VCR) checks for this type of error. When a mismatch occurs on a virtual channel, the server reports a 'software exception' like this:

*** Software exception: 00001202 00000008 00000044

Processor=0 Severity=error

Group=3L Facility=VCR (Virtual Channel Router)

Here, processor 0 wanted to send 8 octets but the receiver wanted to take 4416

*** Software exception: 00001102 00000044 00000008

Processor=1 Severity=error

Group=3L Facility=VCR (Virtual Channel Router)

Here, processor 1 wanted to receive 4416 octets but the receiver wanted to send 8.

Note that two errors may be reported, one from each end of the channel. Error 110216 is from the sending end; 120216 comes from the receiver. Attempting to send or receive a zero-length message is also reported as an error.

To find out which named processor corresponds to the processor number in a software exception message, you need to use the configurer's 'map' option. For example:

» 3L a -m upc.cfg upc.app

The map is written to the standard output stream and looks like this (the processor names are those assigned in your configuration file):

UPR node 0 is processor "dsp1"

UPR node 1 is processor "dsp3"

Armed with the configurer's map output, we can now interpret the processor numbers from the software exception messages we saw above. This particular error arose because a task on dsp3 tried to send a 17-word (68 octet) message to a task on dsp1, which was expecting to receive only two words (8 octets).