Search the Community

Showing results for tags 'system failure'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • GadgetBox Universal IoT Hardware
    • GadgetBox General Discussion
  • Papilio Platform
    • Papilio General Discussion
    • Papilio Pro
    • Papilio One
    • Papilio DUO
    • Papilio Wings
    • DesignLab IDE
    • DesignLab Libraries
    • RetroCade Synth
    • Papilio Arcade
    • Papilio Loader Application
    • Papilio Logic Sniffer
    • Retired
  • Electronics
    • Modules
  • Soft Processors
    • ZPUino
    • J1 Forth
    • AVR8 Soft Processor
  • Community
    • Gadget Factory
    • Documentation
    • FPGA Discussions
    • Community Projects
    • Pipistrello
  • Open Bench
    • Open Bench Logic Sniffer at Dangerous Prototypes
    • OpenBench Logic Sniffer at Gadget Factory
  • Gadget Factory Internal Category


  • Papilio Platform
    • Papilio One
    • Papilio Plus
    • Papilio Wings
    • LogicStart MegaWing
    • ZPUino
    • Papilio Pro
  • Papilio Arcade
  • RetroCade Synth
  • Logic Sniffer
  • FPGAs
  • DesignLab
    • Example Projects
    • Libraries


  • Papilio FPGA
    • Papilio UCF (User Constraint) Files
    • Papilio Bit Files
  • Papilio Arcade
  • RetroCade Synth
  • General
  • Beta (Test) Releases
  • Books

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 1 result

  1. I have been using a papilio pro with a OV7670 camera feeding a frame buffer made of block memory which is then used as the image source for a VGA generator driving the VGA wing. A simple change in the code from; outRGBWrite <= byte1(6) & byte1(4) & byte1(7) & byte1(5) & "00"; --Works! to outRGBWrite <= byte1(6) & byte1(4) & byte1(7) & "000"; --Fails! where; outRGBWrite : out STD_LOGIC_VECTOR(5 DOWNTO 0); and SIGNAL byte0: STD_LOGIC_VECTOR(7 DOWNTO 0); Clearly there was little logical sense in this change making such a difference. I eventually discovered that the top level has; reset: in STD_LOGIC; the value of reset is '1' at startup and then should make the transition to '0', however in the failed case it stays at '1' leaving the system in the reset state. Some of my code set initial values when reset was 1 then doing stuff with those values when reset went to 0. If it never went to 0 the system never started. FACT: I have been working with VHDL for approx 3 weeks so forgive me for not knowing where the reset signal comes from? QUESTION: My problem is solved by ignoring the reset signal and initialising the variables in their declaration rather than letting reset initalise them but the question remains, how is the reset signal being corrupted by the simple change to the lines above that are totally not connected to reset in any way.