Maarten Brock wrote:
It should be a stack overflow.  The stack supports up to 256 bytes. (?) 
The SP is at 0x78, so less than half full.

Yes, the stackpointer can go upto address 255. With these values I 
doubt it is stack overflow.

Here is the program output now:

sending 2d bytes.
payload addr X:0xe091.
SP 72.
sending 7200 bytes.
payload addr X:0xe091.
SP 78.

So now the pointer keeps its value and only len is corrupted. Both 
rf_send() and rf_send_b() think payload is at SP-4 which is wrong 
for rf_send_b() because it has an extra bank pushed on the stack. 
The MSB of len (0x72) is not the old _bp value but probably the LSB 
of the return address after lcall __sdcc_banked_call. You can check 
this in the .rst file which is the .lst after linking.

I don't know why it does this, because it should know that banked 
functions require an extra byte on the stack.

I don't have a .rst for this file.  It appears this file is not created for objects linked from a library.

Any other suggestion on how to proceed with debugging this?