Shop OBEX P1 Docs P2 Docs Learn Events
Faster EEPROM Booting? — Parallax Forums

Faster EEPROM Booting?

jazzedjazzed Posts: 11,803
edited 2011-06-22 19:58 in Propeller 1
Hi.

I've been looking at the Propeller Datasheet. It seems the state of P31 has an effect on boot time by 1/3rd second which is fairly substantial in boot time terms for stand-alone operation.

I've attached a weak pull down to P31, and have had no problems working with the device stand-alone or using a PC for programming.

Questions:
1. Are there any possible unwanted effects in pulling P31 low?
2. Are there good reasons to consider pulling P31 high?

Thanks.
--Steve

Comments

  • JonnyMacJonnyMac Posts: 8,940
    edited 2011-06-20 07:58
    Doesn't the Propeller look for serial data before going to the EEPROM? Would the weak pull-down create a false start bit? Does a pull-up have the same positive effect?
  • jazzedjazzed Posts: 11,803
    edited 2011-06-20 08:09
    I'm just following what the Propeller Datasheet v1.3 says in figure 12 and 13 of page 30.
    If i don't use a pull-down, the boot time appears slower.
  • Cluso99Cluso99 Posts: 18,069
    edited 2011-06-20 08:15
    Chip published the booter code, so you can check exactly what the prop is doing.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-06-20 08:22
    I suspect the bootloader figures that if RxD is not receiving a mark state after reset, there's no serial device connected, so it won't wait for data from one before loading from EEPROM. How easy it is to take advantage of this depends on the hardware being used for the PC connection. For example, an FTDI chip is unpowered without a PC connected, so you could put a pulldown on its serial output pin. But this won't work with a powered, but disconnected MAX232 chip, which defaults to a mark state with no input. Personally, I'd still go with pullups on both A30 and A31. There might be cases in a user's program where it's desirable to distinguish between an idle/disconnected line and an actual BREAK signal.

    -Phil
  • jazzedjazzed Posts: 11,803
    edited 2011-06-20 08:50
    Thanks for your thoughtful reply Phil.

    In this particular situation, the Propeller is part of a "product" (rather than a prototype board) which uses the FTDI chip.
    The product is intended to be used stand alone, but it can be connected to the PC for programming.

    Why would P30 also need a pull up?

    I'll do some experiments.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-06-20 09:07
    jazzed wrote:
    Why would P30 also need a pull up?

    I always include a pullup on P30 to prevent errant BREAKs from being sent to the PC when the Prop is in reset and not driving the pin. Also, without a 74LVC buffer between the FTDI chip and the Prop, the pullups will power the FTDI chip parasitically when no PC is connected and prevent the repeated reset syndrome. (It's much better to include the buffer, though.)

    -Phil
  • jazzedjazzed Posts: 11,803
    edited 2011-06-20 09:31
    will power the FTDI chip parasitically when no PC is connected ...
    My own experience has been with parasitic power has been that the PC tries to power the Propeller, etc.... via the FTDI which seems to damage the FTDI chip with a significant load > 300ma. I've played with powering the FTDI chip separately and while it works fine, one has to remember to turn the device on for it to be useful though :< ... so I acquiesce to the suggested power configuration.

    One thing that really bothers me right now is that when the FTDI chip is not powered, the TX/RX leds blink like crazy and there appear to be other affects on the power supply. Maybe having parasitic power throught the RX/TX pins actually helps in this case?
  • Dave HeinDave Hein Posts: 6,347
    edited 2011-06-20 10:18
    The first three instructions of the boot loader are
                            test    mask_rx,ina     wc      'if rx high, check for host
            if_nc           jmp     #boot                   'else, boot from eeprom
                            call    #rx_bit                 'measure rx calibration pulses ($F9)
    
    If P31 is low it will jump to the EEPROM loader immediately. Otherwise, it spends some time calibrating on P31 before it gives up and jumps to the EEPROM loader.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-06-20 10:19
    This configuration prevents parasitic power going both directions and will solve any issues between the Prop and FTDI chip:

    attachment.php?attachmentid=57861

    -Phil
  • jazzedjazzed Posts: 11,803
    edited 2011-06-20 11:09
    I'll be adding pull-up pads. I don't have room for the 125 circuit.

    Thanks.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-06-20 11:40
    You don't need a 74LVC125, unless you're using hardware handshaking. The 74LVC2G07 comes in a 6-TSSOP (SOT-363).

    -Phil
  • jazzedjazzed Posts: 11,803
    edited 2011-06-20 11:54
    You don't need a 74LVC125, unless you're using hardware handshaking. The 74LVC2G07 comes in a 6-TSSOP (SOT-363).

    -Phil
    Sure. I don't have room for either though and I'm not entirely convinced of the value.

    Just the RX pull up solves any issues I'm seeing except for maybe trying to power the entire device when connected to a PC.
    The TX pull up seems to be causing the more trouble than it's worth.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-06-20 12:07
    Hey, if you don't have room, you don't have room. The value, though, is that it would prevent parasitic power sourcing, which is hardly ever a Good Thing to include in a design. Parallax got by with it for years, though, but has recently converted to the buffering scheme. A more intractable issue arises with designs that rely on the Prop Plug, since it doesn't provide a VCCIO pin to power the buffer from the USB side.

    In your case, the RX pullup alone may be sufficient to power the FTDI chip parasitically and prevent the repeated reset syndrome. I'd use something stiffer, in that case, than 10K though. To prevent powering the Prop from the FTDI chip, you could add a diode and a pullup so the Prop doesn't see any sourced voltage. But, by the time you do that, you might as well just add the buffer.

    -Phil
  • jazzedjazzed Posts: 11,803
    edited 2011-06-22 16:35
    Phil,

    Just a follow-up. I've decided to provide FT232 VCCIO from my 3.3V regulator.
    This appears to eliminate the annoying problems associated with pull-ups otherwise.
    I've tested my device with pull-ups and pull-downs and everything appears to be normal.
    The LEDs don't go crazy after removing the USB cable for example.

    Do you see potential problems with this idea?

    Thanks.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-06-22 17:17
    Hmm. That's an interesting approach and one that I've never considered.

    So I looked in the FT232R databook at the description for VCCIO. It suggests running either from VCC, 3V3OUT, or from an external 1.8V - 2.8V supply. It also cautions that, when using an external supply, it "should originate from the same source as the supply to VCC. This means that in bus powered designs [like yours] a regulator which is supplied by the 5V on the USB bus should be used."

    Unfortunately, this seems to imply that powering VCC and VCCIO has to be both or none.

    -Phil
  • jazzedjazzed Posts: 11,803
    edited 2011-06-22 19:58
    I guess it's a case of "choose your parasitic poison." I've used this approach before, and it worked nicely.

    The design is only bus powered for programming which "can be" fairly common depending on the user. In bus powered mode the voltage is "derived" from the same source. In normal operation, the FT232 is not powered which scares me just a tiny little bit.
Sign In or Register to comment.