You are here

CY7C68013A Program Execution errors when code size > 314 byte | Cypress Semiconductor

CY7C68013A Program Execution errors when code size > 314 byte

Summary: 2 Replies, Latest post by fousdelouf on 28 Nov 2014 10:18 AM PST
Verified Answers: 1
Last post
Log in to post new comments.
fousdelouf's picture
2 posts

Hi, I got serious troubles when trying to run my program on the CY7C68013A.

If I comment the nop at  main.c:167 everything works as expected and the program runs fine (code size 314 byte).

If the nop is in (does not matter where), code size is 315 byte and the program execution starts somewhere in the middle, and loops forever over the same code pattern.

Unfortunately I do not have debug possibilities others than my software implemented uart (i think there are no debug possibilities in this package variant), which requires at least some expectable execution though.

The program is compiled with KEIL's C51 Development Suite, supporting this device.

Mapping and Listing seems fine in my eyes. I can not see any mistakes or errors made by me or the compiler/linker.

Can you please help me? Please see attached files.

PRAG's picture
Cypress Employee
173 posts



The code size seen in the .m51 files is 564 bytes for the working file and 565 bytes for the non-working file.

Have you checked your linker settings to make sure that the code and data sections are defined correctly to accomodate the generated sizes?

Does the issue only occur if you use a nop? Or does it occur if you use any other command/additional code as well?



fousdelouf's picture
2 posts

Yes, that was indeed the culprit. I had to define in the "BL51 Locate" tab the code range to 0x80-0x0FFF and xdata range to 0x1000.

And Yes, the type of instruction doesn't matter.

I thought that activating "use memory layout from Target Dialog" would run fine, since i already have defined the matching controller.

I am still trying to understand finding where the error occured in the M51 file. I know that some of the code was linked to the wrong location and with wrong instructions.

According to the linker map:

            * * * * * * *   D A T A   M E M O R Y   * * * * * * *
            REG     0000H     0008H     ABSOLUTE     "REG BANK 0"
            IDATA   0008H     0001H     UNIT         ?STACK

            * * * * * * *  X D A T A   M E M O R Y  * * * * * * *
            XDATA   0000H     0003H     INPAGE       ?PD?SWIM_ENTRY?MAIN
            XDATA   0003H     0001H     INPAGE       ?PD?MAIN

How can both data memory and xdata memory be at 0x0000 ? Why doesn't the linker at least warn about that memory overlap? And how could it be that the smaller programs ran perfectly fine?

Log in to post new comments.