Shop OBEX P1 Docs P2 Docs Learn Events
Cannot get program running after upload - Page 2 — Parallax Forums

Cannot get program running after upload

2»

Comments

  • Please, please stop modifying parts of a setup that you are not sure if it's working. I've told this my customers so many times...

    If you are working on something new which has never worked before or that you are not familiar with, make sure to start with a system that consits exclusively of parts that you can be sure they are working.

    • Buy a new eval board
    • Buy a new ProgPlug
    • Download a simple demo program
    • Then test it
      If you are successful with that you can add other things step by step. If it stops working at some point, go back one step and it should be fine, again.

    Trying out fixes by guessing with a system that can suffer from multiple problems is a lottery with only very small chances. Even if you fix one thing by good luck you may not notice because the other thing might still be broken.

    If a ProgPlug works with the P1 that's no guaratee that it still does with the P2. I have some here with the same symptoms.

  • ke4pjwke4pjw Posts: 1,328

    I would be curious what the results of the following program's debug would be. Please upload to RAM with debug enabled and post back the results.

    '' =============================================================================
    ''  BootPinConfig.spin2
    ''
    ''  Reads the Parallax P2 Edge (#P2-EC) boot-configuration DIP switches and
    ''  prints the decoded configuration to the DEBUG terminal.
    ''
    ''  The P2 Edge has a 4-position DIP switch. Each position simply adds a weak
    ''  (~100 k) pull resistor to one of the SPI-boot pins, or enables the LEDs:
    ''
    ''     Switch   Effect
    ''     ------   ------------------------------------------------------------
    ''     LED      Connects the on-board LEDs (P56 / P57) to their buffers.
    ''     FLASH    Pull-UP   on P61  -> boot ROM tries the on-board SPI flash.
    ''     up (^)   Pull-UP   on P60  -> boot ROM tries an SD card.
    ''     down (v) Pull-DOWN on P59  -> boot ROM SKIPS the serial-boot window.
    ''
    ''  Because the switches are only pull resistors on the flash SPI pins, a
    ''  running program can sense them by floating P59/P60/P61 and reading the
    ''  level the pull resistor settles them to. The flash chip's CLK/CS/DI lines
    ''  are high-impedance inputs while idle, so they don't fight the read.
    ''
    ''  Caveat: an OFF switch leaves its pin with no pull, so the reading depends
    ''  on the pin floating to a stable level. For a guaranteed result you would
    ''  measure RC decay instead; see notes at the bottom of this file. The LED
    ''  switch is not sensed here (it gates the LED buffers, not a readable pin) --
    ''  observe the LEDs to confirm it.
    '' =============================================================================
    
    CON
      _clkfreq = 200_000_000             ' P2 Edge 20 MHz crystal -> 200 MHz via PLL
    
      FLASH_PIN = 61                     ' pull-up   = SPI flash boot
      SD_PIN    = 60                     ' pull-up   = SD card boot
      SER_PIN   = 59                     ' pull-down = skip serial boot
    
    PUB main() | flash, sd, ser
    
      ' Float the three boot-mode pins (input, no internal pull) so we sense only
      ' the switch pull resistors, then allow a couple ms for them to settle.
      pinf(SER_PIN addpins 2)            ' P59, P60, P61 -> input / floating
      waitms(2)
    
      flash := pinr(FLASH_PIN)
      sd    := pinr(SD_PIN)
      ser   := pinr(SER_PIN)
    
      debug(" ")
      debug("=== P2 Edge boot DIP switch configuration ===")
      debug(" ")
      debug("Raw boot pins:  P61=", udec_(flash), "  P60=", udec_(sd), "  P59=", udec_(ser))
      debug(" ")
    
      if flash
        debug("FLASH  (P61 pull-up)   : ON   -> SPI flash boot enabled")
      else
        debug("FLASH  (P61 pull-up)   : off  -> SPI flash boot disabled")
    
      if sd
        debug("up ^   (P60 pull-up)   : ON   -> SD card boot enabled")
      else
        debug("up ^   (P60 pull-up)   : off  -> SD card boot disabled")
    
      if ser
        debug("down v (P59 pull-down)  : off  -> serial-boot window ALLOWED")
      else
        debug("down v (P59 pull-down)  : ON   -> serial-boot window SKIPPED")
    
      debug(" ")
      debug("LED switch: not sensed in software -- check the P56/P57 LEDs.")
      debug(" ")
      debug("Resulting boot order:")
      print_boot_order(flash, sd, ser)
    
      repeat                             ' park
    
    PRI print_boot_order(flash, sd, ser)
    
      ' The P2 boot ROM walks flash -> SD -> serial, taking the first one its
      ' pull resistors enable. A pull-down on P59 removes the serial fallback.
      if flash
        debug("  1) SPI flash (P61)")
      if sd
        debug("  2) SD card  (P60)")
      if ser
        debug("  3) Serial / monitor window")
      else
        debug("  (serial window skipped by P59 pull-down)")
    
      if not (flash or sd or ser)
        debug("  No boot source selected -- check the switches.")
    
  • @ke4pjw said:
    I would be curious what the results of the following program's debug would be. Please upload to RAM with debug enabled and post back the results.

    Something even more odd is happening there

    Most of the time it outputs this:

    Cog0  INIT $0000_0000 $0000_0000 load
    Cog0  INIT $0000_0FA8 $0000_1920 jump
    Cog0   
    Cog0  === P2 Edge boot DIP switch con-boot window ALLOWED
    Cog0   
    Cog0  LED switch: not sensed in software -- check the P56/P57 LEDs.
    Cog0   
    Cog0  Resulting boot order:
    Cog0    1) SPI flash (P61)
    Cog0    3) Serial /  boot order:
    Cog0    1) SPI flash (P61)
    Cog0    3) Serial / monitor window
    

    But sometimes it is just this:

    Cog0  INIT $0000_0000 $0000_0000 load
    

    And very rarely it does this:

    g0    1) SPI flash (P61)
    Cog0    3) Serial / monitor window
    

    And those 2 lines just keep coming in forever

    Interestingly, if I insert a small delay before each debug() call, the output is this, which is exactly as expected:

    Cog0  INIT $0000_0000 $0000_0000 load
    Cog0  INIT $0000_0FA8 $0000_1958 jump
    Cog0   
    Cog0  === P2 Edge boot DIP switch configuration ===
    Cog0   
    Cog0  Raw boot pins:  P61=1  P60=0  P59=1
    Cog0   
    Cog0  FLASH  (P61 pull-up)   : ON   -> SPI flash boot enabled
    Cog0  up ^   (P60 pull-up)   : off  -> SD card boot disabled
    Cog0  down v (P59 pull-down)  : off  -> serial-boot window ALLOWED
    Cog0   
    Cog0  LED switch: not sensed in software -- check the P56/P57 LEDs.
    Cog0   
    Cog0  Resulting boot order:
    Cog0    1) SPI flash (P61)
    Cog0    3) Serial / monitor window
    

    One thing I forgot about is that the board has 19.2 MHz crystal (I added _xtlfreq = 19200000 to the code)

  • ke4pjwke4pjw Posts: 1,328
    edited 2026-05-30 21:36

    @"Andrey Demenev" said:
    One thing I forgot about is that the board has 19.2 MHz crystal (I added _xtlfreq = 19200000 to the code)

    You have one of the P2 Edge "irregulars" I assume. Well, that _xtalfreq = 19_200_000 should be the way to correct the issue.

    Are you SURE it is an irregular? Can you post a high resolution image of the oscillator module?

  • ke4pjwke4pjw Posts: 1,328

    Also, yeah, that sounds like the programmer is operating on an Edge case. With the repeating debug info from the top of the program sounds like it may be loading the reset circuit, maybe? Have you scoped it?

  • @ke4pjw said:

    @"Andrey Demenev" said:
    One thing I forgot about is that the board has 19.2 MHz crystal (I added _xtlfreq = 19200000 to the code)

    You have one of the P2 Edge "irregulars" I assume. Well, that _xtalfreq = 19_200_000 should be the way to correct the issue.

    Nope, that does not help. The issue I am having is related to reset, and it is also there when using RCFAST

    Are you SURE it is an irregular? Can you post a high resolution image of the oscillator module?

    100% sure. without _xtlfreq = 19200000 the debug output is garbled meaning that baud rate is off

  • @ke4pjw said:
    Also, yeah, that sounds like the programmer is operating on an Edge case. With the repeating debug info from the top of the program sounds like it may be loading the reset circuit, maybe? Have you scoped it?

    I did not.

    Thanks for the hint, I will try next week, I do not have access to an oscilloscope now

  • evanhevanh Posts: 17,265
    edited 2026-05-30 23:05

    @"Andrey Demenev" said:
    Interestingly, if I insert a small delay before each debug() call, the output is this, which is exactly as expected:

    One thing I forgot about is that the board has 19.2 MHz crystal (I added _xtlfreq = 19200000 to the code)

    Okay, then try this without the added delays. You'll need to adjust the terminal baud to match:

    CON
        _xtlfreq = 19_200_000
        _clkfreq = 4_000_000
        DEBUG_BAUD = 19200
    

    And if that works then try removing either _clkfreq or DEBUG_BAUD (reverting the terminal here) to see which one matters.

Sign In or Register to comment.