I've been trying to troubleshoot a mysterious problem for a few days now, and I hope someone here can give me some ideas. We are using UV3 and C51 (ver 7.50) to develop an application for Cypress FX2 LP which is a 8051 variant with 16KB RAM (which may be shared for code and data). For applications of up to about 11KB in code size, everything works fine. When the program exceeds 11KB, strange problems pop up. Calling some (valid!) functions trigger a system reset. Adding a line to a function that no one ever calls, and the system goes into infinite reboot loop. Adding a dummy file with some uncalled functions, same thing happens. Adding a redundant function call that does nothing and everything goes back no normal, until the next time some other line changes. To make a long story short - total chaos! I can't understand the logic of any of this, and it happens only beyond a certain program size. The program compiles and links with no errors (except "uncalled segment" warning if 'dummy' uncalled functions are inserted). The problem is very distrurbing and very chaotic - the program may run fine up to a certain point, then reboots with no apparent cause at all. Comment out an unused function and all goes well. Another thing I noticed - if I tell the linker to move the program in memory, the fault point shifts randomly to someplace else. We've ruled out a H/W problem or a defective CPU. Has anyone ever encountered something so odd, and can you give me any ideas on how to troubleshoot? Thanks in advance, Ran Shalgi Siano Mobile Silicon
16KB RAM (which may be shared for code and data). "May be" is worrying? Are you actually doing that? Do you actually use von-Neumann mapped memory? Adding a line to a function that no one ever calls, and the system goes into infinite reboot loop Bad idea. There should almost never be functions that no one ever calls in a C51 project. There's good reason for linker warning L16 to exist. That said, I suspect the reason for these strange errors is that you have a call through a rogue function pointer somewhere (or equivalently, a write to code through a rogue data pointer). By nothing but a stroke of bad luck, this might happen not to cause serious harm in those builds that appear to work correctly. I.e. you're not really affecting the root cause of the problem by moving code around --- you're just changing the symptoms from benign to desastrous. You'll need a full instruction trace to find out what's going on.
Hans-Bernhard Broeker - you were absolutely right! Problem solved. Here's the explanation: Cypress initialization code copies the USB descriptors to RAM address 0x80. Why 0x80 is an unexplained mystery. HOWEVER, in project settings (copied from a Cypress example!) address 0x80 is part of a valid code memory area and the linker is free to place code there. Whatever code is stored there gets overwritten during runtime by the USB initialization code. When the program is small enough, the linker may elect not to place any code at 0x80. As the program grows larger, random parts of code may be stored there. Changing bits and pieces of code changes linker placement and therefore moves the problem around - it is a different function each time that gets trashed. The solution: change linker settings to start code placement at 0x200 and onwards. I would like to thank everyone for their help, ideas and suggestions! Ran Shalgi
It's been a while since I looked at these chips (my USB now is also a master) but something just dawned on me. Her is an extract from the datasheet:
Individual FIFO/GPIF Interrupt Sources Priority INT4VEC Value Source Notes 1 80 EP2PF Endpoint 2 Programmable Flag 2 84 EP4PF Endpoint 4 Programmable Flag 3 88 EP6PF Endpoint 6 Programmable Flag 4 8C EP8PF Endpoint 8 Programmable Flag 5 90 EP2EF Endpoint 2 Empty Flag 6 94 EP4EF Endpoint 4 Empty Flag 7 98 EP6EF Endpoint 6 Empty Flag 8 9C EP8EF Endpoint 8 Empty Flag 9 A0 EP2FF Endpoint 2 Full Flag 10 A4 EP4FF Endpoint 4 Full Flag 11 A8 EP6FF Endpoint 6 Full Flag 12 AC EP8FF Endpoint 8 Full Flag 13 B0 GPIFDONE GPIF Operation Complete 14 B4 GPIFWF GPIF Waveform