1. Home
  2. Embedded Programming
  3. Keil compiler or FX2 ?

Keil compiler or FX2 ?

Hi !

I have some mysterious problems with cypress fx2. Sometimes if I make small changes in our firmware things go wrong (mostly the enumeration process failes). After adding some stupid line of code (BYTE xdata dummy[] = "dummy";) it works as expected ! I don't know what's responsible for this problem. Compiler ? Linker ? FX2 ? Perhaps anybody has some experience with this kind of problems. My predecessor had the same problems and they occur on different hardware using the fx2. Thats why I think is not related to a wrong code line or defect hardware.

Many thanks, Thomas Hoppe

Reply to
Thomas Hoppe
Loading thread data ...

That sure feels like a bug in your software. That line, e.g., introduces a new variable in xdata, which will move a good fraction of your entire xdata to new positions. The kind of bug that is affected by this is writing through a garbage pointer. Moving things around means you change what gets hit by that bomb.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

"Thomas Hoppe" wrote in news:c7fgfi$hdo$ snipped-for-privacy@news.f.de.plusline.net:

Neither. The C run-time is responisble for copying the DATA section constants, like "dummy", to their final run-time locations (e.g. FLASH to XDATA) and zeroing BSS variables (those without an initial value). To see why adding the BYTE xdata dummy[] = "dummy"; line affects, switch to assy. mode in the debugger and watch the CSTARTUP.ASM code execute. My guess is that you have some variable that is not properly initialized but in certain cases happens to be the correct value. Adding a dummy[] causes something other than what you want to be placed in this as-yet-to-be-found variable and things go wrong.

Rule 1: reduce your dependence on the C run-time. Don't use global or file scoped variable when not absolutely required.

Rule 2: Don't assign values to global or static variables because it increases your image size.

Rule 3: If you can initialize variables at run-time, do so e.g. strcpy(dummy, "dummy").

--
- Mark ->
--
Reply to
Mark A. Odell

based on what you are just saying, (and only on what you are saying), you got a compiler bug buddy........ Ive chased them around for years........ if you can add a "do nothing" line of code, and it fixes your problem, then you can almost bet your ass on it............ actually, i would think a linker bug, more than the compiler itself......

small

?
Reply to
Clark G. Smith

You're jumping to conclusions way prematurely. At the level of details shown by the OP, there are quite a lot of possible reasons left that could be at the bottom of this. A bug in the toolchain, while never quite impossible, is by no means the most likely of them, and certainly not the only possible one. Bugs in the OP's own code are quite a bit more likely.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.