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?
a*
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
