Troubleshooting: Difference between revisions

From Uzebox Wiki
Jump to navigation Jump to search
No edit summary
Line 29: Line 29:


==Weird graphics glitches or random crashes when using different optimization level==
==Weird graphics glitches or random crashes when using different optimization level==
This usually happen when calling C routines from assembler. Insure r1 is *always* cleared before calling the routine. Otherwise, results are unpredictable.
Insure you *always* clear r1 before calling C routines and exiting assembler functions otherwise, results can be unpredictable.

Revision as of 20:47, 16 September 2009

No image and High pitch noise

  • There's nothing in the screen or bunch of random lines/dots appears
  • The sound is a horrible high pitched noise out the speaker


Insure *only* these fuses are written (written fuse=0, unwritten fuse=1):

IF you are using a crystal:

-SPIEN (pre-written in the factory)
-EESAVE
-CKSEL3
-SUT1
-These fuses correspond to a setting of 0xD7 for lfuse and 0xD7 for hfuse

IF you are using an oscillator module:

-SPIEN (pre-written in the factory)
-EESAVE
-CKSEL0
-CKSEL1
-CKSEL2
-CKSEL3
-SUT0
-SUT1
-These fuses correspond to a setting of 0xC0 for lfuse and 0xD7 for hfuse

EESAVE preserves the eeprom between flash writes (will be useful later on). CKSEL=0111 SUT=01 starts with a full swing oscillator 16K delay+0ms.

Mega644s ships with CKDIV8 AND JTAGEN activated and must be uncheked. CKDIV8 internally divides the master clock by 8, so your Uzebox runs at 3.57Mhz. No chance it will generate video with that! Also JTAGEN activates the debug port, which is on the VIDEO DAC port and will screw up some color component if left active.

Weird graphics glitches or random crashes when using different optimization level

Insure you *always* clear r1 before calling C routines and exiting assembler functions otherwise, results can be unpredictable.