Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

18990929495160

Comments

  • I had a reset problem with a Propplug in another application: a board with propeller and wiznet TCI/IP-Chip didn't work after restart, but was ok after checking all components under a microscope. In the end it turned out: the propplug feeded a little current to the board, the wiznet chip 's voltage didn't fall below .8 Volt and so the power on reset didn't work! I remember this reading that the problem was gone with the propplug.
    no reason to reason if you feel feelings: in love with the propeller
  • Is the ground for the PropPlug an A9 output pin that is driven low?
    Prop Info and Apps: http://www.rayslogic.com/
  • cgracey wrote: »
    Seairth wrote: »
    cgracey wrote: »
    It's just a recompile with the soft reset at D[25] for CLKSET.

    I don't see CLKSET it the google doc. What is D's encoding for that instruction?

    It's in the spreadsheet.

    I'm thinking CLKSET needs to be renamed to HUBCFG, since it's used to seed the PRNG, set the digital pin filters, and set the clock mode. It has not been fully documented, yet.

    I only see the instruction, not the D encoding. As for the rename, I think that's an excellent idea.
  • Rayman wrote: »
    Is the ground for the PropPlug an A9 output pin that is driven low?

    No, it's a real GND pin.
  • RaymanRayman Posts: 9,578
    edited 2017-10-17 - 19:16:03
    The comment I deleted earlier is that it might be some weird ground loop or EMI issue...
    I would try putting ferrites on the USB cables and see if that does anything...

    But, I guess that wouldn't explain why it consistently wouldn't work with just a software change...
    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 13,788
    Seairth wrote: »
    This recent conversation caused me to read over the BOOT PROCESS section of the documents. I have a few questions:
    1. With the fuses "removed", will the boot ROM still go through the SHA-256/HMAC steps?
    2. If the boot sequence boots from EEPROM first, how do you boot from serial once the EEPROM is programmed?
    3. Is it correct that in order to program the EEPROM, the programming tool would first bootstrap the necessary code to then take subsequent commands to perform the actual programming?

    Here is my understanding of the Boot choices...
    * boot memory is SPI Flash, not EEPROM
    * there was talk around 3 pin SPI connects, not sure where that settled in ROM code.
    * there is a one-pin serial mode, for very smallest loader pin cost, you can use a ~30c MCU to load ~16k Bytes - maybe enough for SD or USB ?
    * Pins can have pullup/pulldowns added, to skip BOOT tests (ie you likely want to skip the serial timeout, in field use)
    * ROM code is 'simplest-read', so has no erase or polling/page size abilities, so yes, PGM of new code needs first a stub-loaded usually via UART
    FWIR ROM does emit quad mode reset commands, so a soft-reset/watchdog reset can reboot from a user-has-quad-active device.
  • TubularTubular Posts: 3,649
    edited 2017-10-17 - 23:26:47
    I can't find my BeMicro A9, otherwise I'd play along.

    I think the prop plug circuit could be improved a bit, there's some good info from Tracy Allen in this thread,
    http://forums.parallax.com/discussion/155048/prop-plug-npn-transistor-value


    I'll make up some modified prop plugs along the lines Tracy suggests and get one to you Brian
  • Tubular wrote: »
    I can't find my BeMicro A9, otherwise I'd play along.

    I think the prop plug circuit could be improved a bit, there's some good info from Tracey Allen in this thread,
    http://forums.parallax.com/discussion/155048/prop-plug-npn-transistor-value


    I'll make up some modified prop plugs along the lines Tracey suggests and get one to you Brian

    That was interesting what Tracy said about the 10nf cap being directly driven from a pin and the current rush destabilizing the FTDI chip's internal 3.3V regulator. One thing we could do, rather than inserting a resistor in there, would be to find a pin-compatible N-FET, so that no significant loading occurs on the pin.
  • cgracey wrote: »
    Ozpropdev, could you please try the BeMicro_A9_Prop2_v24.jic again, but with a 0.1uF cap between ground and RESn? This problem is really bugging me. We need to know why this is happening.
    Sure.
    I'll try that when i'm back at the shop a bit later.



    Melbourne, Australia
  • jmgjmg Posts: 13,788
    cgracey wrote: »
    That was interesting what Tracy said about the 10nf cap being directly driven from a pin and the current rush destabilizing the FTDI chip's internal 3.3V regulator.
    I think that was more a guess ? The P-FET should limit the current to something the regulator can manage, but the design is still less than ideal.
    With no series R, there is no easy time-constant definition - the hard Vbe clamping takes most of the energy of the Cap, (and it will impulse-test even a stable regulator) and the eventual turnoff, is the time 33k takes to discharge from the Vbe at clamp current, to the Vbe at load current/hfe.

    Let's say that's ~200mV dV @ Vbe - during that active region time, you are also exposed to any power supply ripple on the FTDI device as the NPN device is connected straight to Vcc via the cap.
    That's very noise-sensitive, and trailing edge runt resets could result - just what is not needed.
    cgracey wrote: »
    One thing we could do, rather than inserting a resistor in there, would be to find a pin-compatible N-FET, so that no significant loading occurs on the pin.

    Tracey suggests a Digital Transistor, which allows removal of the 33k, so that seems the lowest BOM solution.
    Looks like prebiased SOT23 are ~ 2c/3k, and those come from OnSemi, who you probably like to include in your BOMs now ;)

    Cheapest mosfets are ~ 2.5c, but MOSFET still need that 33k, and cheapest Logic Level MOSFET, (which you should really use), are ~ 3.5c, cheapest stocked are just under 4c
  • jmg wrote: »
    Seairth wrote: »
    This recent conversation caused me to read over the BOOT PROCESS section of the documents. I have a few questions:
    1. With the fuses "removed", will the boot ROM still go through the SHA-256/HMAC steps?
    2. If the boot sequence boots from EEPROM first, how do you boot from serial once the EEPROM is programmed?
    3. Is it correct that in order to program the EEPROM, the programming tool would first bootstrap the necessary code to then take subsequent commands to perform the actual programming?

    Here is my understanding of the Boot choices...
    * boot memory is SPI Flash, not EEPROM
    * there was talk around 3 pin SPI connects, not sure where that settled in ROM code.
    * there is a one-pin serial mode, for very smallest loader pin cost, you can use a ~30c MCU to load ~16k Bytes - maybe enough for SD or USB ?
    * Pins can have pullup/pulldowns added, to skip BOOT tests (ie you likely want to skip the serial timeout, in field use)
    * ROM code is 'simplest-read', so has no erase or polling/page size abilities, so yes, PGM of new code needs first a stub-loaded usually via UART
    FWIR ROM does emit quad mode reset commands, so a soft-reset/watchdog reset can reboot from a user-has-quad-active device.

    Yes. This is all correct. And it uses a 3-pin SPI interface, not a 4- or 7-.
  • Cluso99Cluso99 Posts: 15,240
    edited 2017-10-18 - 02:27:28
    I have been playing with P1V modifications and the DE0-Nano. I am not sure if some problems I have are related, so I thought I would mention it just in case.

    After downloading the P1V, I remove power (from USB download) and plug in the USB to my PROPPLUG equivalent which has a 3V3 regulator on board which is then linked via a very short pair of 3V3 has the 5V and GND connected via very short wires to the pin power connectors on the DE0.

    With some code changes, PropTool will correctly identify with F7, as often as I like. But when I go to download code with CTL-F10, I consistently get "lost communications with .....". F7 still works.

    I have put this down to a subtle change in my COG RAM "always @(posedge cog-clk)" implementation, perhaps causing a cog ram timing error. I have done other changes that also have resulted in the same error messages.

    As I said, I don't know if there is any relationship here or not.

    My PROPPLUG (which is on the smorgasbord if you want to check schematics or layout) and it's directly plugged into the DE0.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmgjmg Posts: 13,788
    Cluso99 wrote: »
    ...
    With some code changes, PropTool will correctly identify with F7, as often as I like. But when I go to download code with CTL-F10, I consistently get "lost communications with .....". F7 still works.

    If identify always works, that does sound like something around download handling is marginal - insufficient setup times, or not enough slack somewhere..
    Cluso99 wrote: »
    My PROPPLUG (which is on the smorgasbord if you want to check schematics or layout) and it's directly plugged into the DE0.

    Do you ave other USB-UART bridges you can easily try ?
  • The code that loadp2 uses to load a binary file is shown below. Maybe the difference between PNut and loadp2 has to do with the timeouts I use. I wait 50 msecs after resetting before I start loading the MainLoader. I then wait 100 msecs after MainLoader is loading before I load the binary file.
        hwreset();
        msleep(50);
        tx((uint8_t *)"> Prop_Hex 0 0 0 0", 18);
        txval(0xfd640000 | ((clock_mode & 511) << 9));
        tx((uint8_t *)MainLoader, strlen(MainLoader));
        txval(3*clock_freq/LOADER_BAUD/2-6);
        txval(clock_freq/LOADER_BAUD-6);
        txval(size);
        txval(address);
        tx((uint8_t *)"~", 1);
        msleep(100);
        while ((num=fread(buffer, 1, 1024, infile)))
        {
            tx((uint8_t *)buffer, num);
        }
        msleep(50);
    
  • jmg wrote: »
    Cluso99 wrote: »
    ...
    With some code changes, PropTool will correctly identify with F7, as often as I like. But when I go to download code with CTL-F10, I consistently get "lost communications with .....". F7 still works.

    If identify always works, that does sound like something around download handling is marginal - insufficient setup times, or not enough slack somewhere..
    Cluso99 wrote: »
    My PROPPLUG (which is on the smorgasbord if you want to check schematics or layout) and it's directly plugged into the DE0.

    Do you ave other USB-UART bridges you can easily try ?
    Tried a CP2102 ...
    It identifies the Prop OK but fails to download with the comms error.
    BUT, there is no transistor reset circuit here, so its not a true test. I will have to build a reset circuit to test properly.

    From my observation on my P1V, the problem is timing related to COG RAM, and I have solutions for this.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmgjmg Posts: 13,788
    Cluso99 wrote: »
    It identifies the Prop OK but fails to download with the comms error....

    In both P1 & P2 cases, it could be useful to connect a counter or storage scope to count how many characters/edges are sent before the download fails ?

    I think in both P1 & P2 cases, the Identify step does need to run 'ROM' code to echo the version info, but nothing actually tried to write to FPGA memory.
  • cgracey wrote: »
    Ozpropdev, could you please try the BeMicro_A9_Prop2_v24.jic again, but with a 0.1uF cap between ground and RESn? This problem is really bugging me. We need to know why this is happening.
    Tried that combination Chip and it made no improvement.
    Pnut identifies Prop2 Ok but wont load code as before.


    Melbourne, Australia
  • ozpropdev wrote: »
    cgracey wrote: »
    Ozpropdev, could you please try the BeMicro_A9_Prop2_v24.jic again, but with a 0.1uF cap between ground and RESn? This problem is really bugging me. We need to know why this is happening.
    Tried that combination Chip and it made no improvement.
    Pnut identifies Prop2 Ok but wont load code as before.


    Thanks, Ozpropdev.

    Does PNut always identify it okay?

    I am going to look at the reset and serial action on a scope today. If it identifies, it should also load.
  • Yes it identifies Ok every time.
    its only load that drops out.

    Maybe you can bring out some of the internal reset states to some pins to compare with the outside world.
    Melbourne, Australia
  • evanhevanh Posts: 7,533
    edited 2017-10-18 - 14:05:40
    Leading on from Tubular's prompting of Tracy's work I've captured the reset and power around the FTDI chip. You can see the pink power rail is clean in both captures (200 MHz analogue frontend).

    Green: TXD at pin 2 of mux (U18) (What's with the relabelling half way along a net?!)
    Blue: RXD at pin 4 of ftdi (U2)
    Pink: 3V3OUT at pin 13 of ftdi (U2)
    Orange: FTDI_RST at pin 10 of mux (U18)


    PS: Couple of corrections from my previous comments:
    - DTR was correct. I got RTS from Dave's sources.
    - I can't make sense of my older scope captures in the other topic. I'm not getting anything like them now. Maybe I was using PX or something.
    - In particular, the reset is a short pulse, I've never captured DTR directly.
    640 x 480 - 10K
    640 x 480 - 11K
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • Thanks for taking those measurements, Evanh.

    The next question is when does the TX/RX action start after reset, and then after downloading the small loader?
  • evanhevanh Posts: 7,533
    edited 2017-10-18 - 15:31:47
    cgracey wrote: »
    The next question is when does the TX/RX action start after reset, and then after downloading the small loader?
    pnut and loadp2 differ notably there. There is no rxd activity for loadp2, with success, while for pnut there is more txd activity and three two rxd bursts coming back from the prop2 before it goes out to lunch.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • evanhevanh Posts: 7,533
    edited 2017-10-18 - 15:30:32
    Here's the full sequence for both, using same probes as above. I've zoomed in to the start of the two txd bursts for loadp2, and, for pnut, the two last single(or double) byte blips before the extraneous reset.
    640 x 480 - 12K
    640 x 480 - 12K
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • TonyB_TonyB_ Posts: 1,222
    edited 2017-10-18 - 23:56:22
    evanh wrote: »
    I have an old Win98 laptop but PNut doesn't work on that at all.

    PNut v18 works on my Win98SE + KernelEx (kernel extension) system.
    For editing, if nothing else. I don't know about loading as I don't have any Prop hardware.

    KernelEx info:
    http://kernelex.sourceforge.net/wiki/Main_Page
    Last version by original author is 4.5.2

    Latest update to 4.5.2 by another author available at
    http://www.msfn.org/board/topic/173233-kernelex-45-core-updates-45201617/?page=30

    Formerly known as TonyB
  • jmgjmg Posts: 13,788
    evanh wrote: »
    Leading on from Tubular's prompting of Tracy's work I've captured the reset and power around the FTDI chip. You can see the pink power rail is clean in both captures (200 MHz analogue frontend).
    - In particular, the reset is a short pulse, I've never captured DTR directly.

    Nice shots.
    You can see the effect I mentioned on the reset release edge, where there are 'bonus spikes' on that reset rise, and they are because the 10nF is connected to the Vcc during that time, and the transistor is in the linear, highest gain region.
    Those spikes will be highly system dependent, and because the rise is non monotonic, it becomes a lottery as to what the FPGA 'sees'.
    A P1 has more hysteresis than FPGA, so it is more tolerant.

    Still a 'best avoided' situation. An external schmitt with enough hysteresis could clean that up.

    Looking at Pre-biased transistors I see 47k seems to be the highest common Rb - can you easily add a 47k in series with the 10nF reset cap, and check again ?
    This should do two things :
    * Widen the pulse
    * reduce the spikes on rise edge

    The slow-rise effect is best avoided entirely, but that may be non-trivial.
    Hardware:
    ? Replace 10n with a resistor, and simply pulse DTR to define 'clean' reset width - this may be easiest FPGA testing answer ?
    ? Change to MMUN2213LT1G 47k/47k NPN pre-bias, (may be PCB compatible)
    ? Change to MOSFET does not help, as they still lack hysteresis.
    ? Change to M74VHC1G135DFT2G (single gate, NAND Schmitt, Open Drain) - needs PCB respin, & still needs RC
    ? Change to 74LVC1G3157 SPDT tiny gate, and feed TXD to RST when DTR is low. Perhaps too Sw dependent.
    ? Change to APX803L (reset generator), feed with C-R-R from DTR/Vcc, can self time, or just DTR follow

    One software based approach would be to extend the natural decay pulse width to maybe 4~5ms, and then issue a shorter DTR pulse.
    This means a ~1ms clean digital pulse occurs on 'best SW' but other SW still does work, via the slower rise.

    Of course on USB+Operating systems, that's rather easier to say than do...
    I've found DTR to TXD timing rather 'looser' on USB, and a rapid DTR toggle in SW, does not always make it to the pin.
    {Clear-Output : Dummy-Read-input: Set-Output} seems to work and the USB turnaround sets a pulse mostly 1ms* from what I remember from the tests I did.

    *FT2232H etc HS-USB parts have a 125us USB frame, so their pulse times can be shorter.
    evanh wrote: »
    Here's the full sequence for both, using same probes as above. I've zoomed in to the start of the two txd bursts for loadp2, and, for pnut, the two last single(or double) byte blips before the extraneous reset.

    Not sure I followed the zoom, but pnut seems to get a reply, so maybe polls ID again, whilst loadp2 seems to skip that (having done it earlier?)
    Is there some recovery time from having polled, or does that poll confuse autobaud ?

    Lead in time is slightly longer on loadp2 than pnut - what is the actual P2 image reset-exit time ? I thought that was << 1ms to allow better watchdog recovery ?

  • JMG,
    Both captures are the compete sequence. Nothing is missing. It's 400 ms across the unzoomed display. The programmed steps to the sequence differ between PNut and LoadP2. PNut presumably makes some queries where as LoadP2 just sends the program data.

    In the PNut sequence, there is about 270 ms from the normal reset#2 to the problematic reset#3. So, a blanking filter would need to be large.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • One thing of note is LoadP2 tx data is clearly 2 Mb/s where as PNut's, and the Prop2 replies to Pnut, looks more like 1 Mb/s.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • jmgjmg Posts: 13,788
    evanh wrote: »
    In the PNut sequence, there is about 270 ms from the normal reset#2 to the problematic reset#3. So, a blanking filter would need to be large.

    If pnut does an ID query, why does it even need to generate a 3rd reset ?
    There is less lead-in delay after 3rd reset, but still should be enough ?
    evanh wrote: »
    One thing of note is LoadP2 tx data is clearly 2 Mb/s where as PNut's, and the Prop2 replies to Pnut, looks more like 1 Mb/s.
    You'd expect 2 MB to have more issues around autobaud than 1M, but is it easy to change baud to check ?

  • I've made several attempts to capture the signals on the scope for the beMicro-A9 board.
    Problem is as soon as I connect the scope the code load issue disappears.
    Melbourne, Australia
  • jmgjmg Posts: 13,788
    edited 2017-10-19 - 01:51:18
    ozpropdev wrote: »
    I've made several attempts to capture the signals on the scope for the beMicro-A9 board.
    Problem is as soon as I connect the scope the code load issue disappears.
    Maybe the scope is just reducing the noise on that rising/trialing edge just enough...

    You could try a 100k~1M in series with the probe to RESET line, to isolate the few pF, or you could trigger from the DTR pin rise instead ?

    Lowering the RST pullup may help, as it then needs more uA of base current to give the same mV if ripple.

    Also try swapping the 10nF cap for 47k, to avoid the Vcc-noise amplifier effect on the trailing edge.
    The cap is only there, so systems with stuck DTR can exit reset, not really an issue for FPGA downloads.
Sign In or Register to comment.