• State Not Answered
  • Locked Locked
  • Replies 14 replies
  • Subscribers 21 subscribers
  • Views 2625 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

autobanking jump to XBP address instead of caller function during function return (large model)

Agus Purwanto

Hi Keil,

i'm currently working on project involving large memory model, reentrant function with auto-banking. i've met this unresolved bug involving keil stack frame causing my program flow generate an error.

the error generated when a callee function return to it's caller, instead of returning to it's caller address my program jump to current XBP value (lets say current XBP value at X:0xD00), then my program jump to that address (C:0xD00), that address already occupied by other piece of code, and execute that code causing my program running indeterminately. i've debugged the code and the returning address should be passed on to DPTR by ADDXBP function before calling SWITCH_BANK, the DPTR contain 0xD00 by the time SWITCH_BANK is called.

here's several questions regarding C51 that would help the debugging process:
1. i want to know where do keil save it's caller program counter for large reentrant model? my program might overwrite that area (in my case all function always set as reentrant).
2. what happened to stack frame when reentrant function called? program counter and local reentrant variable/argument is on different stack or same stack? stack frame structure if available would help a lot.
3. beside during function return when will XBP accessed? i believe my error caused by wrong access of XBP.

i use c51 compiler and lx51 linker, uVision3

Sincerely,
Agus Purwanto

Parents
  • 0 in reply to ²erik malund

    The low-end ARM chips have a very significant price overlap with 8051 chips. Especially when the 8051 solution requires extra external hardware.

    Another aspect is the support/maintainance costs which are also a significant part of the full lifetime cost of a product. 32-bit integers, a generic stack, full support for reentrant code, function and data pointers, indexing etc while removing the need for banking can be quite significant advantages when talking about code complexity and sw maintainance costs.

    The huge market share ARM chips are collecting isn't because they are expensive and only meaningful to select for high-end, or low-volume, products.

Reply
  • 0 in reply to ²erik malund

    The low-end ARM chips have a very significant price overlap with 8051 chips. Especially when the 8051 solution requires extra external hardware.

    Another aspect is the support/maintainance costs which are also a significant part of the full lifetime cost of a product. 32-bit integers, a generic stack, full support for reentrant code, function and data pointers, indexing etc while removing the need for banking can be quite significant advantages when talking about code complexity and sw maintainance costs.

    The huge market share ARM chips are collecting isn't because they are expensive and only meaningful to select for high-end, or low-volume, products.

Children
No data