Propeller Loader

cgracey · 2006-06-14 06:28

This object lets you load/program one Propeller from another·Propeller·(instead of a PC).

This function may be a little early for most users, but·the object·demonstrates how ABORTs are used - they can get you all the way out of deep mess in a snap.

I will augment this object later for loading an array of Propeller chips (ie. the old Propeller Supercomputing thread).
·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey (Parallax)) : 6/14/2006 6:35:34 AM GMT

Cliff L. Biffle · 2006-06-15 01:19

Neat! I may have to take back some of my comments in the Operating System thread; this looks like most of what I'd need to program a binary onto the Propeller from $OS_HERE. (Not that the binary format is documented. One step at a time...)

What's the deal with the 500-bit exchange from the LFSRs? Checking that you're talking to the right device and that the link is working?

Is the bitrate here fixed, or derived from the initial synchronization pulse?

cgracey · 2006-06-15 01:35

Cliff L. Biffle said...
Neat! I may have to take back some of my comments in the Operating System thread; this looks like most of what I'd need to program a binary onto the Propeller from $OS_HERE. (Not that the binary format is documented. One step at a time...)

Yeah, we use serial from the PC, but it's really a matter of 1T and 2T pulses. T can be as short as 4us, and as long as 10ms (not that you'd want to be so slow).

What's the deal with the 500-bit exchange from the LFSRs? Checking that you're talking to the right device and that the link is working?

That's right. It makes sure that both parties are not false-triggering.

Is the bitrate here fixed, or derived from the initial synchronization pulse?

It's all derived from the initial two pulses. The whole time the Propeller is loading, it's running off its fast internal RC oscillator which might be from 8MHz to 20MHz, but nominally 12MHz. Whatever its frequency is, it's pretty stable. If your top-level Spin file calls for a crystal and PLL, those things get turned and allowed to stabilize for 20ms before they are switched over to and your app begins executing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chip Gracey
Parallax, Inc.

Cliff L. Biffle · 2006-06-15 01:49

[noparse][[/noparse]quote]Yeah, we use serial from the PC, but it's really a matter of 1T and 2T pulses. T can be as short as 4us, and as long as 10ms (not that you'd want to be so slow).

Neat. Everything I'd want to program from (my workstations and my robot's central controller) have UARTs, so this should be straightforward.

(You must have been very worried about false-triggering to use such a grandiose handshake.

)

Kaos Kidd · 2006-06-15 13:27

Chip:
This is sweet!
I guess it might be time for me to get the second propeller onto the breadboard and make-em co-work!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket

KK
·

Muncher · 2006-06-18 04:21

could you use this to create self-developing programs?

RinksCustoms · 2006-06-18 05:39

You speak of AI (Artificial Intelegence), what a wonderful and terrifying idea.....

IAI-Captain · 2006-06-18 08:40

to RinksCustoms:
Sorry to nag!
But, Please consider:
No form of Intelligence is Artificial! And that All forms of Intelligence·are Real!
It's not the Intelligence that's Artificial!
It's the thinking medium that's not biological in it's nature. (IE. Silicon·compared to biological Carbon based organisms.)
One day, soon, machines and their Intelligence will be indistinguishable from human intelligence.
The Turing test will be passed.
Please consider the term, "Machine Intelligence", instead.
Check out the book' "GROWING UP WITH LUCY: How To Build An Android In Twenty·Easy Steps", By STEVE GRAND
and or the book,·"CREATION: Life and How·to Make It", ALSO BY STEVE GRAND

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
IAI (Indigenous Alien Intelligence),
The New View on Machine Intelligence.
Because There is nothing Artificial about it!

Cliff L. Biffle · 2006-06-18 23:43

Muncher said...
could you use this to create self-developing programs?

Believe me, I'm already thinking about genetic programming on this beast. Being able to load a new image without hitting an EEPROM could make for some seriously fast generations.

Michael O'Brien · 2009-01-07 03:33

Hi,
I would really like to get the PropellerLoader.spin code working but I am having trouble just before the chip version exchange section.
I inserted some debugging code and cannot get past the following section without an abort ErrorConnect.

'receive and verify LFSR pattern
repeat 250
if WaitBit(1) <> IterateLFSR

So, calibration, LFSR send work, I fail at LFSR receive and don't get to the chip version exchange.

I followed the hardware setup for BOEn and the VSS tied 1M resistor as well as different combinations of clock PLL speeds (this shouldn't matter as only the internal RC is used during bootup right?) including the default internal one.
There seems to be no problem with either 40 pin dip, I set BOEn back to VSS and temporarily connect the 2nd propeller to its' own eeprom and prop plug and it works fine using two separate propeller tool IDE's. The PropellerLoader.spin in this configuration only resets prop2 which then boots normally from eeprom if p31/p32 serial comm fails as described in section 3.1 of the propeller datasheet.

thank you
/michael

Paul Baker · 2009-01-08 19:52

The Propeller chip will time out if it doesn't receive information in a set time frame, if you are adding debugging information in one of those critical windows, you run the potential of timing out the Propeller and breaking the downloading process.

If you must add debugging information, create another thread to handle processing debugging information. The Propeller Tool has a dedicated thread which handles nothing but the downloading process so that system calls do not affect it's timing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker

Post Edited (Paul Baker) : 1/8/2009 7:57:30 PM GMT

Rumple · 2009-11-18 16:32

Chip Gracey (Parallax) said...

I will augment this object later for loading an array of Propeller chips (ie. the old Propeller Supercomputing thread).
·

Just wondering if this plan ever came to fruition.· If so, I can't seem to find it.

Sounds very useful.

Regards,
Tim

Cluso99 · 2009-11-18 16:50

Yes there is a thread describing how to load a group of propeller chips but I cannot recall it's title or link. Maybe someone else can chime in.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Michael O'Brien · 2009-11-19 03:45

See the work by Christian, Ken and Pems in 2008
http://forums.parallax.com/showthread.php?p=758971
/michael

Post Edited (Michael O'Brien) : 11/21/2009 2:00:18 AM GMT

Clock Loop · 2011-09-14 20:21

The descriptions behind the various programming modes isn't clear.

#0, Shutdown, LoadRun, ProgramShutdown, ProgramRun

I figured ProgramRun would take the binary file you include and dump it onto the props eeprom.
And then that prop would run its program.

I can get LoadRun to work, but it will not program the props eeprom.

I looked at the code in propeller loader, and it looks as if the code is incomplete for program modes "ProgramShutdown, ProgramRun"

Can anyone confirm this?

Oh, and about the wiring of props with proploader, I did it with 55 props that get parallel programmed when wired right.
http://forums.parallax.com/showthread.php?127983-55-Parallax-Propeller-s-Parallells-Processing-of-Permanent-Perturbations.

Mike Green · 2011-09-14 21:07

These programming modes command the "slave" Propeller. Shutdown sends a program to the other Propeller, then forces it to halt ... doesn't accomplish much really. LoadRun sends a program to the other Propeller where it's stored in RAM, then executed. ProgramShutdown sends a program to the other Propeller, causes the other Propeller to copy the program to EEPROM, then halt without executing the program. ProgramRun is like LoadRun except the program is copied to EEPROM before executing. Essentially, if the high order bit of the mode is one, the program is copied from RAM to EEPROM. If the low order bit of the mode is one, the program is run from RAM.

Remember that the loader is for the "master" Propeller. It only sends the program to the other Propeller (along with the programming mode value). The "slave" Propeller's bootloader (in ROM) does the rest of the work.

idbruce · 2011-09-15 00:37

@Mike

That was a very nice answer! I truly believe that answer should be added to object within this thread and the OBEX to make it "GOLDEN"

Or at least I think it is in the OBEX.

It is already a very nice object, but that clarification should be made within the spin file.

Bruce

EDIT: I added that description to my copies of that file.

VG · 2011-12-29 18:36

Hi All,
I am receiving non readable character from my set up.

Connection: PC <-> Proto board (master) <---> Slave (Prop DIP on breadboard)

The slave blinks LED and it seems to be working.
But characters I type in PST are coming back strange.
Image:

Image from PST:

Master Loader.spin:
(Calls loader sends bytes from slave to PC and PC to slave)

CON
   _clkmode  = xtal1 + pll8x
   _xinfreq  = 5_000_000

  #1, ErrorConnect, ErrorVersion, ErrorChecksum, ErrorProgram, ErrorVerify
  #0, Shutdown, LoadRun, ProgramShutdown, ProgramRun
  
  ' Set pins and baud rate for PC comms 
  PC_Rx     = 31  
  PC_Tx     = 30
  PC_Baud   = 9600   

  ' Set pins and Baud rate for Slaveee comms  
  Slave_Rx     = 1    ' Slaveee DOUT
  Slave_Tx     = 5    ' Slaveee DIN                  
  Slave_Baud   = 9600

  LED_PIN   = 16
                                   

DAT loadme file "Serial_Loopback.binary"

OBJ
  PC  : "FullDuplexSerial"             
  Slave      : "FullDuplexSerial"
  loader  : "PropellerLoader"
VAR

  long P31, P30, LFSR, Ver, Echo
  long stack[50]                ' stack space for second cog
 

pub mainPrg |i
  dira[LED_PIN]   :=1
  outa[LED_PIN] := 1

  dira[15] := 1
  outa[15] := 1
  
  Delay(1000)
  i := loader.Connect( 3,5,1,1,ProgramRun,@loadme )           'Load
  PC.dec(i)
  PC.tx(13)
  PC.start(PC_Rx, PC_Tx, 0, PC_Baud)                   
  Delay(4000)
  outa[LED_PIN] := 0                                       
  outa[15] := 0
  StartComm                                                'Pass through
   

Pub  StartComm |i
  Slave.start(Slave_Rx, Slave_Tx, 0, Slave_Baud) ' Initialize comms for Slaveee  
  cognew(Slave_to_PC,@stack)       ' Start cog for Slaveee--> PC comms

  PC.rxFlush                    ' Empty buffer for data from PC
  repeat
    Slave.tx(PC.rx)                ' Accept data from PC and send to Slaveee
       
Pub Slave_to_PC  |i

  Slave.rxFlush                    ' Empty buffer for data from Slave
  repeat
    PC.tx(Slave.rx)


{{ Clock Functions }}
Pub Delay(mS)
'' Delay ring
'' Delay(1000)     ' pause 1 second
  waitcnt(clkfreq/1000 * mS + cnt)

Code loaded into slave with eeprom (no xtal) :::: Serial_Loopback.spin

CON
  _clkmode = RCFAST


  ' Set pins and baud rate for PC comms 
  Mastr_Rx     = 31  
  Mastr_Tx     = 30
  Mastr_Baud   = 9600      
   
Var
  long stack[50]                ' stack space for second cog
                                                                       
OBJ
  Master: "FullDuplexSerial"  

Pub  Start   |i
  dira[15] := 1
  outa[15] := 1
  waitcnt(clkfreq * 4 + cnt)
  outa[15] := 0
  
  Master.start(Mastr_Rx, Mastr_Tx, 0, Mastr_Baud) ' Initialize comms

  Mastr.rxFlush                    ' Empty buffer 

  repeat
     Mastr.tx(Mastr.rx)

kuroneko · 2011-12-29 19:00

VG wrote: »

I am receiving non readable character from my set up.

Serial_Loopback runs with RCFAST. The FullDuplexSerial object relies on the clkfreq setting for its baud rate calculations. Most likely your RCFAST isn't close enough to 12MHz (built-in setting) for this to work. I know that my demobard runs at 13MHz so manually changing long[0] to 13M before starting FDS works for me. So either give your slave an XTAL or figure out the real RCFAST rate (monitor a slave square wave from your master).

And if you post code please use [noparse]

[/noparse] tags.

VG · 2011-12-29 19:52

Thank you kuoneko. I thought clkfreq will be set based on clkmode. I am not sure. I am googling more info about it.
How can I monitor the slave sqwave? Is there an object??

VG.

kuroneko · 2011-12-30 01:14

VG wrote: »

Thank you kuoneko. I thought clkfreq will be set based on clkmode. I am not sure. I am googling more info about it.
How can I monitor the slave sqwave? Is there an object??

It is based on _clkmode but RCFAST can be anything from 8..20MHz. The value stored in clkfreq (long[0]) is 12MHz no matter what the actual frequency is (the compiler has to put something in there).

For measuring the frequency simply generate a square wave on the slave side (use a counter or the Synth object which is part of the PropTool library) and you can use [thread=123170]Bean's frequency counter[/thread] on the master side.

Update: or simply try all possible frequency values from 8..20MHz in say 500kHz steps and go from there. At some point the master should get it.

Cluso99 · 2011-12-30 11:01

You could generate 5MHz on a master output pin and connect this to Xin on the slave, and then the slave will have a 5MHz clock to give 80MHz operation with PLLx16. Alternately you could output 80MHz to Xin and use PLLx1 (see _clockmode in the manual)

Just in case you have not realised, the manual is available in the help section of PropTool (it's downloaded as part of the PropTool set of info, including some demo programs and tutorials)

Phil Pilgrim (PhiPi) · 2011-12-30 12:28

Cluso99 wrote:

Alternately you could output 80MHz to Xin and use PLLx1 (see _clockmode in the manual)

No you can't. All the PLL modes specify a clock source between 4 and 8 MHz, although ~14 MHz seems to be the real maximum. 80 MHz is way over the horizon. You could probably use XINPUT by itself, though, without the PLLx1.

-Phil

Cluso99 · 2011-12-30 14:28

Of course you are correct Phil. I was thinking about the XIMPUT mode without PLL.
Preference is of course not to route high frequency clock signals.

Its amazing what old threads can dig up and remind you of. The download mechanism can be faster to boot than eeprom loading because the download is only for the length of the data whereas the eeprom is always 32KB, plus the fact that the download has to timeout.

The other interesting bit to look at is the fixed locations at the beginning of the binary. The length is contained within this.

BTW: Did you note Chip provided for revisions/versions of the Prop chip. Amazing we still have only 1 version - meaning no revisions due to bugs. Take a look at the AVRs etc to see the revisions, and these are only variations of families of chips and they often run to Rev E.

VG · 2011-12-31 21:56

Happy New year.
I used the following code to sense the frequency:

SLAVE on pin 26

CON
_clkmode = rcfast 

PUB NCO_single_ended_mode
' mode PLL BPIN APIN
ctra := %00100_000 << 23 + 1 << 9 + 26 'Establish mode and APIN (BPIN is ignored)
frqa := $8000_0000 'Set FRQA so PHSA[31] toggles every clock
dira[26] := 1 'Set APIN to output
repeat 'infinite loop, so counter continues to run

Master: Bean's "Freq Counter Simple.spin" code. Thank you Bean.
My output is around
3900 only.

I was expecting in the range of 8Mhz to 12Mhz. This is way below. Did I miss something.

VG

kuroneko · 2011-12-31 22:22

VG wrote: »

My output is around 3900 only. I was expecting in the range of 8Mhz to 12Mhz. This is way below. Did I miss something.

Interesting. That is indeed rather low. What unit is this? I just checked RCFAST/256 and I get 52.8kHz (external multimeter) which puts this particular board at 13.5MHz. Can the master measure say a 20MHz square wave from itself correctly (frqx := $40000000 @80MHz)?

FWIW, with your NCO setup you should see clkfreq/2 so something around the 6M mark. Also, how do you have your setup wired (signal/GND)?

VG · 2012-01-01 13:25

Kuroneko thanks for that hint. Originally my slave was on a separate circuit sending ONLY the clock signal to the master. I had only around 3K (upto 9K sometimes). I got your hint to share GND. After powering slave from the protoboard (master) I am getting around 6.657MHZ (or at 13MHz). Thank you.
VG.

RockyD · 2012-08-27 09:31

I have found that there is a problem with this object with RCFAST. This might have been mentioned in other threads. I have found a work around where the first 250 bits of IterateLFSR can be per-computed into an array. This lets it get past the first 150ms timeout inside of the boot loader until it gets refreshed. It seems a better solution would be to write this routine in PASM, since there is not much time to spare with RCFAST.

With the propeller internal boot code, that first 150ms timeout, to get 250 bits, is the biggest speed hurdle to pass. The rest of the boot code will extend the timeout when the boot code sends bits and revives longs.

I found a mention of the T1 and T2 pulses used:
http://forums.parallax.com/archive/index.php/t-86311.html

Chip mentioned in the thread:

Yeah, we use serial from the PC, but it's really a matter of 1T and 2T pulses. T can be as short as 4us, and as long as 10ms (not that you'd want to be so slow).

It looks like the pulses would need to be much faster than 10ms to get the first 250 bits to the propeller before it hits the 150ms timeout.

Some code from the boot loader. Note that the timeout is reset after getting a long, but not a bit. The first 250 bits are received as bits not longs, so there is no time extension.

booter.spin: http://forums.parallax.com/showthread.php?101483-Propeller-ROM-source-code-HERE

' Receive long
'
rx_long                 mov     time,time_load          'reset time limit

                        mov     bits,#32                'ready for 32 bits
:loop                   call    #rx_bit                 'input bit
                        rcr     rxdata,#1               'shift into long
                        djnz    bits,#:loop             'loop until done

rx_long_ret             ret
'
'
' Receive bit (c)
'
rx_bit                  test    mask_rx,ina     wc      'wait while rx high
        if_c            djnz    time,#rx_bit
        if_c            jmp     #boot                   'if timeout, boot from eeprom

                        mov     delta,time              'time while rx low

:loop                   test    mask_rx,ina     wc      'h?h    2 instructions/loop
        if_nc           djnz    time,#:loop             '1      400ns @20MHz...1us @8MHz
        if_nc           jmp     #boot                   'if timeout, boot from eeprom

                        sub     delta,time              'delta = rx low time in loops
                        cmp     delta,threshold wc      'resolve bit into c

rx_bit_ret              ret

Rocky

Clock Loop · 2013-08-12 10:50

Is it possible to provide an included object as the address for the binary file?
I would like to do this so when I compile my objects do also. (my object i include is the program I want to run in spin form)

Texan · 2014-10-29 13:46

Yes, PropellerLoader.spin doesn't work at RCFAST. But, since I'm only doing PASM in my project, and I need this functionality with RCFAST (no crystal), I have used booter.spin to guide development of this loader.spin. (Search as I have, I haven't found this in PASM. But it seems to be in almost every other language!)

I developed this by connecting a QuickStart board target (J1 VSS(39), VDD(38), RESn(37), P31(35) and P30(33)) to a breadboard 40PIN DIP host (VSS, VDD and pins 0, 1 and 2) (using jumper wires). I didn't modify either BOEn or RESn on the QuickStart so it doesn't comply with Chip's recommendation. However, by continuing to control RESn, it seems to work as expected.

I haven't really decided how I'll fit this with other things, but I know I'm not using EEPROMs (so LoadRun is hardcoded) and the pins are in variables (I'll probably pass them in through par at some point.)

As my first post to this forum, excuse any errors in convention.

Propeller Loader

Comments