Shop OBEX P1 Docs P2 Docs Learn Events
loadp2 and 25MHz crystal — Parallax Forums

loadp2 and 25MHz crystal

ManAtWorkManAtWork Posts: 2,049
edited 2020-07-15 09:26 in Propeller 2
I just found out that loadp2 does not work very reliably when I have a 25MHz crystal connected to the P2 instead of a 20MHz one. It works when I startup freshly after power up but doesn't when "reboot", I mean hitting "compile & run on P2" in FlexGui while my program is still running. I get an error
trying \\.\COM3...
P2 version G found on serial port \\.\COM3
Setting load mode to CHIP
Setting clock_mode to 12427f8
Loading fast loader for chip...
ERROR: timeout waiting for initial checksum: got -1

Does loadp2 rely on the crystal frequency? I thought it would do an auto-baud detection and should at least tolerate some variation. Ideally it should not use the crystal at all and switch to RC-fast as there may be boards that don't have a crystal at all.

I also don't think that the problem is in my code because the error occurs before my code is even loaded. The bootloader should do a reset and recover from any state the P2 is in.

I know that 25MHz is a bit out of spec. The docs say
The XI and XO pins can also be used for clocking, with XI being an input and XO being a crystal-feedback output for 10MHz-
20MHz crystals.
However, I don't think that's a problem. Others are heavily overclocking the P2 well byond the official specs and the P2 still works. I don't overclock the core or the PLL but only bend the XI/XO oscillator limits a bit. Being able to use 25MHz would be nice because I have a full reel of SMD crystals from another project where it is used for an ethernet MAC where 25MHz is standard.

I also have verified that the oscillator is running. The scope shows a clean sine 25.000MHz signal with ~1Vpp. The amplitude is the same with the 20MHz crystal and if my program is loaded and started sucessfully it prints a message in the terminal so the PLL settings also should be correct.

Comments

  • jmgjmg Posts: 15,140
    Strange, if it works after power up, but not otherwise, that suggests a timing issue ?
    The loadp2 doc's mention 80MHz sysclk and the clock mode comment above, would /10 x40, so you would get 100MHz sysclk from a 25MHz xtal. That's not pushing anything.
    Do you have a 25MHz oscillator, or can you wire a Xtal to an external 2GU04 or similar, to create an oscillator ?
  • The crystal is connected directly to the P2 pins without any other components. The crystal is specd for 12pF load and the P2 is configured for 600 Ohm / 15pF drive. The 3pF "overload" shouldn't cause problems but only means that the frequency tolerance widens a bit. The crystal is +/- 10ppm and I don't want to build a clock...

    If the startup time was a problem then it should rather fail after power up and not when re-booting.
  • Setting clock_mode to 12427f8
    
    It looks like the clock mode is set to PLL and Xtal oscillator enabled but the source is set to RC fast. So if I interpret that correctly XIN should be ignored and the loader should be independent of the crystal connected.
  • evanhevanh Posts: 15,126
    You definitely have to tell it what the crystal frequency is. There's no way it can guess. Obviously, Loadp2 defaults to the 20 MHz the Eval Board comes
    with.

    I'm not at my computer atm, so don't have loadp2 to play with. Will get back later.


  • use the -f <freq> option for loadp2.
    09:41:33 TAQOZ$ loadp2
    loadp2 - a loader for the propeller 2 - version 0.027 2019-10-23
    usage: loadp2
             [ -p port ]               serial port
             [ -b baud ]               user baud rate (default is 115200)
             [ -l baud ]               loader baud rate (default is 2000000)
             [ -f clkfreq ]            clock frequency (default is 80000000)
             [ -m clkmode ]            clock mode in hex (default is ffffffff)
             [ -s address ]            starting address in hex (default is 0)
             [ -t ]                    enter terminal mode after running the program
             [ -T ]                    enter PST-compatible terminal mode
             [ -v ]                    enable verbose mode
             [ -k ]                    wait for user input before exit
             [ -q ]                    quiet mode: also checks for magic escape sequence
             [ -n ]                    no reset; skip any hardware reset
             [ -? ]                    display a usage message and exit
             [ -CHIP ]                 set load mode for CHIP
             [ -FPGA ]                 set load mode for FPGA
             [ -SINGLE ]               set load mode for single stage
             [ -PATCH ]                patch in clock frequency and serial parms
             [ -NOZERO ]               do not clear memory before download
             file                      file to load
    

    btw, I'm using ozpropdev's Python loader instead now.
  • evanhevanh Posts: 15,126
    Thanks Peter. Jogged my memory. The -SINGLE option uses RCFAST without any second stage loader.

  • evanhevanh Posts: 15,126
    edited 2020-07-16 08:47
    Doing some Loadp2 fiddling without reading the sources I'm struggling to set -f parameter to anything other than 80 MHz and still have the download work. What I can do is set the -m PLL mode to suit the default 80 MHz. With the Eval Board I can change the default PLL mode from 12427f8 (XDIV=10, XMUL=40, XDIVP=1) to say 10003f8 (XDIV=1, XMUL=4, XDIVP=1) and it still correctly downloads.

    In the case of a 25 MHz crystal, to get the 80 MHz, it would be something like -m1100ff8 (XDIV=5, XMUL=16, XDIVP=1).

  • Ok, thanks Peter and Evan. Setting the clock mode to -m1100ff8 fixed it.

    I'm still a bit confused. Why does the loader require a special crystal frequency? Why does it need a crystal at all? On the P1 the loader used RC fast mode and did an auto-baud procedure so it could adjust to the RC clock tolerance. I don't see a reason why this shouldn't also work with the P2.

    At the moment I might be the only one with a custom board that doesn't use a 20MHz crystal. But a loader should be some sort of universal tool that works with all kind of boards. In the future there might be boards that have no crystal at all. For my geocache P1 boards, for example, I run at very low power from a Li cell.
  • jmgjmg Posts: 15,140
    ManAtWork wrote: »
    I'm still a bit confused. Why does the loader require a special crystal frequency? Why does it need a crystal at all?
    I think that is a bug...

    ManAtWork wrote: »
    On the P1 the loader used RC fast mode and did an auto-baud procedure so it could adjust to the RC clock tolerance. I don't see a reason why this shouldn't also work with the P2.
    It does, in the single stage loader, that uses RCFAST.
    That uses the ROM AutoBaud using "> " and it is widely clock tolerant.

    There must be an oversight in the faster loader that loadp2 inserts, that does not use the autobaud code.

    It may be that someone will need to specify both a XTAL and a PLL value, so that a correct clkmode can be derived, if it is too complex to include the Autobaud.

    ManAtWork wrote: »
    At the moment I might be the only one with a custom board that doesn't use a 20MHz crystal. But a loader should be some sort of universal tool that works with all kind of boards. In the future there might be boards that have no crystal at all. For my geocache P1 boards, for example, I run at very low power from a Li cell.
    You can always use -SINGLE from above, and that will skip the PLL step.
  • When loadp2 is in the CHIP mode it uses a 2-stage loader. The first stage loads a small second-stage loader that runs at the frequency specified by the command line option -f. The default frequency is 80 MHz. loadp2 computes a mode value based on a 20 MHz crystal and the specified system frequency. If a crystal other than 20 MHz is used, you have to specify the mode value using the -m option.

    As suggested above, the SINGLE mode can be used to avoid this. The SINGLE mode uses a single-stage loader running with RCFAST. It does not change the system clock frequency prior to running the user program. This requires that the user program changes the system clock frequency after it starts up.
  • The loadp2 fast loader does attempt to autobaud, but obviously it isn't working. I'm sorry for that, but I'm only one person and I only have a limited selection of hardware to test with. The code is open source (https://github.com/totalspectrum/loadp2) and I welcome contributions.
  • jmgjmg Posts: 15,140
    ersmith wrote: »
    The loadp2 fast loader does attempt to autobaud, but obviously it isn't working. I'm sorry for that, but I'm only one person and I only have a limited selection of hardware to test with. The code is open source (https://github.com/totalspectrum/loadp2) and I welcome contributions.

    It may be simpler to just let users define a XTAL ? (maybe -x ? default 20MHz) along with requested Baud and PLL. Then P2load can report actual Baud, PLL, PFD, and mode value used.
    SW Autobaud schemes rely on a known character, or apply assumptions, so are intolerant of reset exit in the wrong phase, whilst the P2 ROM-loader has a smart-pin hardware signature capture, that triggers on "> ' and is very tolerant of arriving in the middle of any random serial stream.
  • Sorry, Eric, this wasn't meant as complaint. I know your time is limited and I highly respect your work on fastspin.

    I have forked the loadp2 GIT but I don't understand much of the source code. loadp2.c is the PC program. MainLoader.spin2 is the 1st stage bootstrap loader and MainLoader1.spin2 the second stage? Where does MainLoader get its parameters from (res...)? Does the ROM bootloader supply this values?

    I thought, ideally, the whole loading process should not depend on anything except the P2 itself and pins P62/P63. But I see that the P2 silicon documentation has been updated and the serial loading protocol is described. There is a Prop_Clk command, so it's the way its meant to be to set a PLL instead of RC fast for booting... Ok, I didn't know.

    So it should be mentioned in the FlexGUI/Fastspin docs. A descriptive error message would help. Something like "checksum error, please check baud rate and clock/PLL settings". I didn't even know that it is necessary to specify clock settings when the crystal is different. If I get the right hint I know that I did something wrong and I have a chance to look up what I have to do.
  • The fix for loadp2 is pretty simple. There is a routine in loadp2.c called get_clock_mode() that is used to compute the clock mode value in the CHIP mode. It contains a local variable called xtalfreq that is declared with "int xtalfreq = 20000000;". This declaration just needs to be moved to the top of the program so it is global, and then a "-x" option should be added to change the xtal frequency.
  • ManAtWork wrote: »
    I have forked the loadp2 GIT but I don't understand much of the source code. loadp2.c is the PC program. MainLoader.spin2 is the 1st stage bootstrap loader and MainLoader1.spin2 the second stage? Where does MainLoader get its parameters from (res...)? Does the ROM bootloader supply this values?
    I've renamed those files now to MainLoader_fpga.spin2 (the old MainLoader.spin2) and MainLoader_chip.spin2 (the old MainLoader1.spin2). Thanks for reminding me, I've meant to change those names for a while.

    MainLoader_chip.spin2 is the one that's used by nearly everyone nowadays, and we could probably remove MainLoader_fpga.spin2.

    The first thing MainLoader_chip.spin2 does is to set the desired clock mode (the value is plugged into the binary by loadp2).

    There's something wrong with the autobaud code, it only seems to work at 80 MHz and below. But I don't know what it could be, and I don't remember changing anything in that code since when it did work at 160 MHz.

    The simplest course of action for you is to always just use the -SINGLE flag to loadp2, that uses just the built-in ROM loader. The only downside of this is that (a) it's a little slower (it sends ASCII encoded data rather than binary), and (b) it doesn't support the scattered loading feature of loadp2 where you can put different data at different addresses.
  • evanhevanh Posts: 15,126
    I'll have a nosy at mainloader later today ...
  • I've updated mainloader_chip to stay in RCFAST mode. That at least seems to work-around the autobaud problems, and since it uses smart pins now there's no harm in doing this (the original mainloader bit-banged the serial, so it wanted to run at a high clock frequency).
  • evanhevanh Posts: 15,126
    Thanks Eric. I see -m, along with -f, is now only for the mailbox handover mechanism, with the -PATCH option. That's cleaner.

Sign In or Register to comment.