Shop OBEX P1 Docs P2 Docs Learn Events
loadp2 problems — Parallax Forums

loadp2 problems

Peter JakackiPeter Jakacki Posts: 10,193
in Propeller 2
For some reason I can't seem to use my versions of loadp2 on Linux with the revB silicon as it comes up with "Unknown version G".
But downloading a fresh source and building also has an error: 
peter@peter-XPS-15-9550:~/Downloads/loadp2-master$ ./build_linux
loadp2.c:63:10: fatal error: MainLoader.h: No such file or directory
 #include "MainLoader.h"
          ^~~~~~~~~~~~~~
compilation terminated.
Maybe I need a coffee.

Comments

  • roglohrogloh Posts: 5,787
    Try running "make" which will build the header files needed.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-11-10 00:41
    Ok, just had a coffee. 
    loadp2-master$ ls
build_cygwin  LICENSE	 MainLoader1.spin2  osint.h	   sb.c
build_linux   loadelf.c  MainLoader.spin2   osint_linux.c  sendfile.c
build_macos   loadelf.h  Makefile	    osint_mingw.c
build_mingw   loadp2.c	 osint_cygwin.c     readme.txt
loadp2-master$ make
mkdir -p ./build
fastspin -2 -o MainLoader.bin MainLoader.spin2
make: fastspin: Command not found
Makefile:63: recipe for target 'MainLoader.bin' failed
make: *** [MainLoader.bin] Error 127
loadp2-master$

    Maybe I need another coffee :)
    Has something changed with loadp2 as it used to build?

    I used the source from https://github.com/totalspectrum/loadp2
  • evanhevanh Posts: 15,916
    Yep, that's a relatively new feature where building loadp2 for the first time needs fastspin in the path. This is because it now assembles the mainloader from pasm source where as earlier versions had a fixed hex data in a constant struct that needed hand edited if mainloader got an update.
  • evanhevanh Posts: 15,916
    edited 2019-11-10 01:00
    I make use of shell history quite a lot now. I have this for first action of prop2 coding now: 
    export PATH="${PATH}:/home/evanh/hoard/coding/prop2/bin/"

    Works for both those C compiles and my pasm work.

    EDIT: Or you can just throw a copy of fastspin in /usr/local/bin or something.

    EDIT2: Huh, /usr/local/* is almost entirely empty in Ubuntu 18.04. I know little about organising the OS but presume they've been making changes to depreciate the use of that path. /usr/bin is always there I guess.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-11-10 01:59
    I built fastspin and put it in my path at /usr/local/bin and got past that new hiccup. Built a new loadp2 and ran my bake script and failed again.
    The thing is I never had problems with loadp2 before, it just worked.

    EDIT: muddle head has worked through it and I forced it to -SINGLE (I'm working with a non-standard 22.222MHz input while testing)
     
    TAQOZ$ ./loadp2 -v -SINGLE r3.bin
Searching serial ports for a P2
trying /dev/ttyUSB0...
  timeout
P2 version G found on serial port /dev/ttyUSB0
Loading r3.bin - 60032 bytes
Checksum validated
r3.bin loaded




    TAQOZ$ ./bake P2D2R3-22 r3
preprocessing files .....
assembling .spin2 file .....
Loading binary .....
ERROR: got incorrect initial chksum: �P�

    Confirming p2 response as Prop_Ver G plus it enters TAQOZ etc
    The other thing is while it is not a big thing to sort through this, it is just hat if I spend time on getting tools to work, then there is less time I can spend on getting my software and hardware to work.

    Here's some more output: 
    TAQOZ$ ./loadp2 -v r3.bin
Searching serial ports for a P2
trying /dev/ttyUSB0...
  timeout
P2 version G found on serial port /dev/ttyUSB0
Setting load mode to CHIP
Setting clock_mode to 12427f8
Loading fast loader for chip...
ERROR: got incorrect initial chksum: �P�
  • ersmithersmith Posts: 6,053
    Which version of Linux are you running, Peter? If it's a Debian derivative you could try this binary -- it's the one I use, and seems to work well for me.

    I'm curious about the "incorrect initial checksum" error you're getting, because @"David Betz" is also seeing that on his Mac. There may be a timing bug of some sort. Does reducing the loading speed to, say, 230400 baud with the "-l230400" option make this go away?

    zip
    zip
    loadp2_linux.zip
    14K
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-11-10 02:25
    @ersmith - I running Linux Mint 19.2 
    TAQOZ$ uname -a
Linux peter-XPS-15-9550 4.15.0-45-generic #48-Ubuntu SMP Tue Jan 29 16:28:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

    loadp2 seemed to work with -SINGLE so I will check this out more later.

    EDIT: really seems to be a problem with the fast loader
    Here's a manual reset and preset parameters 
    TAQOZ$ ./loadp2 -p /dev/ttyUSB0 -CHIP -f 22222222 -n -v r3.bin
Setting clock_mode to 1240af8
Loading fast loader for chip...
ERROR: got incorrect initial chksum: �`�

    TAQOZ$ ./loadp2 -p /dev/ttyUSB0 -CHIP -f 22222222 -SINGLE -n -v r3.bin
Loading r3.bin - 60032 bytes
Checksum validated
r3.bin loaded
  • evanhevanh Posts: 15,916
    Kind of figures. Older versions of loadp2, for Linux, also defaulted to using -SINGLE for a while.
  • evanhevanh Posts: 15,916
    edited 2019-11-10 03:35
    Ah, with -CHIP mainloader the "clock_mode" will be defaulting to an assumed 20 MHz crystal. This can be adjusted by using -m option, incorporating custom calculation to suit the target 80 MHz.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-11-10 03:51
    evanh wrote: »
    Ah, with -CHIP mainloader the "clock_mode" will be defaulting to an assumed 20 MHz crystal. This can be adjusted by using -m option, incorporating custom calculation to suit the target 80 MHz.

    I thought the -f would override that but I also tried it with out the -CHIP and it seems to default back again: 
    peter:TAQOZ$ ./loadp2 -f 22222222 -v r3.bin
Searching serial ports for a P2
trying /dev/ttyUSB0...
  timeout
P2 version G found on serial port /dev/ttyUSB0
Setting load mode to CHIP
Setting clock_mode to 1240af8
Loading fast loader for chip...
ERROR: got incorrect initial chksum: �`�

    and patching in the actual clock mode etc and I guess now that -f specifies the final frequency rather than the oscillator. 
    peter:TAQOZ$ ./loadp2 -PATCH -f 180000000 -m 010007f8 -v r3.bin
Searching serial ports for a P2
trying /dev/ttyUSB0...
  timeout
P2 version G found on serial port /dev/ttyUSB0
Setting load mode to CHIP
Loading fast loader for chip...
Loading r3.bin - 60032 bytes
chksum: d7 OK
r3.bin loaded

    So success with fast loader and the change to setting this as the default caused the problem which is why I had to use -SINGLE unless I specified the parameters



  • ersmithersmith Posts: 6,053
    I thought that -f always specified the final clock frequency for the fast loader, and -m the mode to use (which if not specified is calculated from the frequency based on assuming a 20MHz crystal).

    The original fast loader used bit-banging to read the bytes, so it needed to run at a reasonably high frequency. But the new fast loader is using the smart pins, so actually it makes sense for the loader to stay in RCFAST mode. The only drawback there is that RCFAST isn't at a known frequency, so we'll probably have to autobaud again to figure out the smart pin settings. Unless the ROM stores the information somewhere? That would be nice if it does, I'll have to look at the listing to check.
  • evanhevanh Posts: 15,916
    Yep, it does. It's one of those functional details that has barely been used by anyone before.

    Looks like Peter has it all under control now. No need to do autobaud really. But, if you're keen, I guess no-one will complain. :)

  • ersmithersmith Posts: 6,053
    Do the new P2D2 boards use the same crystal frequency as the P2-ES boards (20 MHz)? If so then I guess we can punt on the autobaud for now, but if not people will not be able to use flexgui out of the box on the P2D2 boards without autobaud. The configuration changes necessary to the command line are minor, but if there's one thing I've discovered it's that users (including me!) are reluctant to read documentation or to have to do anything to make their programs work.
  • Cluso99Cluso99 Posts: 18,069
    Yes, the autobaud value is available one time only at the start. IIRC it’s in a register a2 ???
    TAQOZ and the monitor use the smart pins that are already set, but it is available when either are called.
    Anyway, just check chips listing at the autobaud section.
  • Cluso99Cluso99 Posts: 18,069
    P2D2 used 12MHz
    P2EVAL used 20MHz
    Forget which one used a xtal and which used an osc
    P2EVAL2 is using 20MHz
    P2D2R2 is using 26MHz??? switches to 20MHz???

    Think I will use 20MHz xtal either 10pF or 20pF. The P2 only has options for 15pF or 30pF so the actual freq will be some ppm off which will be irrelevant since the xtal may only be 10-50ppm anyway. Unlike jmg, I’m not trying to get to 1ppm.
  • jmgjmg Posts: 15,173
    ersmith wrote: »
    Do the new P2D2 boards use the same crystal frequency as the P2-ES boards (20 MHz)?

    Close :) - the P2 Clock frequency is set by EFM8UB3 to be 20.00MHz on Si5351A CLK1 pin.
    Currently, at power up Si5351A inits & resets P2 concurrently, and I've mapped DTR _/= -> Reset P2 and RTS _/= -> reloads Si5351A from table

    The physically fitted Crystal/Osc frequency is what the Si5351A sees, and here 26MHz is a sensible choice, as it covers very low cost GPS oscillators.

  • jmgjmg Posts: 15,173
    ersmith wrote: »
    ...
    The original fast loader used bit-banging to read the bytes, so it needed to run at a reasonably high frequency. But the new fast loader is using the smart pins, so actually it makes sense for the loader to stay in RCFAST mode. The only drawback there is that RCFAST isn't at a known frequency, so we'll probably have to autobaud again to figure out the smart pin settings. Unless the ROM stores the information somewhere? That would be nice if it does, I'll have to look at the listing to check.

    Autobaud again is a good idea, as the RCFAST can drift as the P2 warms up. The ROM has a high quality AutoBaud, not sure if that can be called again ?

    Another drawback of RCFAST is the division to baud is not large, so granularity is coarse.
    EFM8UB3 can set to Baud values above 3MBd (anything 24M/N is valid, N >= 2), at higher rates USB pipe & SW delays is limiting factor, but for loaders, P2 takes data as fast as it can.

    It is possible users may use P2 with FT232H parts, and those can stream gapless at 12MBd, so the P2 loader should be able to define PLL settings that allow P2 to keep up, and keep Baud exact.

    Does anyone know what SysCLK P2 needs to load at 12MBd ? (for the SW to keep up? - I'd guess 120MHz is OK ?)
  • dMajodMajo Posts: 855
    jmg wrote: »
    EFM8UB3 can set to Baud values above 3MBd (anything 24M/N is valid, N >= 2), at higher rates USB pipe & SW delays is limiting factor, but for loaders, P2 takes data as fast as it can.

    With the EFM8 there is no problems at all as on the P2D2 it have direct access to the Flash/SD thus it is able to update the image stored there without engaging the P2 that could wait in reset.


    BTW @"Peter Jakacki" I think you have an error on the latest P2D2r3 schematic near P2 pins 1 and 2. It seems that VDD goes shorted to GND.
Sign In or Register to comment.