loadp2 and 25MHz crystal
ManAtWork
Posts: 2,176
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
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
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.
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
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.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.
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
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 ?
If the startup time was a problem then it should rather fail after power up and not when re-booting.
with.
I'm not at my computer atm, so don't have loadp2 to play with. Will get back later.
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 loadbtw, I'm using ozpropdev's Python loader instead now.
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).
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.
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.
You can always use -SINGLE from above, and that will skip the PLL step.
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.
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.
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.
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.