Anthony, > 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*
Indeed, no .rst for library objects. But maybe you could link the object explicitly to override the library and this will generate the .rst file. That is assuming you have built the library first from source. Maarten ------------------------------------------------------------------------------ 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
