XDATA corruption from user_flash_read /_write

Internet MCU W7100A
1

XDATA around 0x42A6 is being corrupted during user_flash_read(), user_flash_write(), setSIPR(), setGAR(), setSUBR(), or setSHAR().

Presumably during do_isp(), which user_flash_* calls.

This was overwriting a 2-byte array “byte foo[2]={0xff,0xff};” with 0x00, 0x00.
I masked the problem by moving variables to DATA from XDATA, but need to understand the root cause.

Any thoughts?

2

I’ll check this issue from the person in charge.

Please understand that there will be a delay in response due to the Christmas, and New Year holidays.
Thank you for your patience and we will get back to your questions ASAP.
Sincerely,
3

I wish you would change the Memory Model as “Large: variables in XDATA” in target tab of option.

image
image737×435 12.2 KB

And when you changed the mode, I want to know if the same issue occurs.
Could you please you send me your project if it is possible to send project?

4

Hello,

Thank you.

We are already using Large: variables in XDATA" for our target

memory model. While trying to diagnose this symptom I tried the
other two options to no avail.

I am attaching the project files from before I started trying to fix
the issue. This contains everything needed to rebuild the code that
demonstrates the issue. The “current” code has moved all the small
XDATA variables into DATA to avoid them being overwritten, but
that’s not actually a fix. :-\

The variable that is getting overwritten (the variable we know is
getting overwritten — the overwrite probably affects many more
bytes) is “currentIDO”
In case the attachment doesn’t come through you can download it from
here:

41041.zip (547 KB)

5

In my private opinion,I want you don’t use the standard printf function.
I suspect that the stack is broken because of the printf function.
So, I recommend that you don’t use the printf function and try again.
Reference link for printf(C51): C51: WHY NUMBER OF BYTES PASSED TO PRINTF IS LIMITED