Booting a P1 from a P2

ManAtWork

If I have a system with both a P1 and a P2 I thought it would be a good idea to boot the P1 over RX/TX from the P2 instead of having two local flash memories. That would not only save a few cents and some board space but also simplifies factory programming and later software updates.

I can make sure that both propellers are powered up at the same time so the P2 should be ready to provide boot data before the serial window of the P1 times out. Is it necessary to also control /RESET of the P1 from the P2 (Progplug DTR emulation)? For development and on-the-fly rebooting or updating I think the answer is yes. But for power on booting only it shouldn't be necessary.

Has anybody already done this so that there are code examples? Or where can I find documetation about the P1 boot protocol?

Simonius

I found nothing in the official Handbook, unfortunately.
However, i came across this, which might help:
Proploader

Ariba

There is a Spin1 code from Chip that boots a second P1 from a first P1: https://github.com/parallaxinc/propeller/tree/master/libraries/community/p1/All/Propeller Loader

Should not be hard to convert this to Spin2.
If both P2 and P1 start at the same time, a Reset connection is not necessary, you just need to start the download after 90..110 ms after both are powered up.

Andy

tritonium

Hi

There is a pdf on my PC called 'Propeller Programming Protocol'. Don't know where I found it but I was able to write a freebasic loader using the information in there.

We will see if the 'pdf' got attached its about 1.7 Mbyte

after a search found this
https://forums.parallax.com/discussion/download/131200/PropellerProgrammingProtocol.pdf

Dave

iseries

Would it not be easier to go in the side door instead of the front door? Why not emulate the EEPROM which is a simpler and know protocol since the P2 is the master and a reset to the p1 so that it loads its program from the image on the P2.

Mike

ManAtWork

@iseries said:
Would it not be easier to go in the side door instead of the front door? Why not emulate the EEPROM which is a simpler and know protocol since the P2 is the master and a reset to the p1 so that it loads its program from the image on the P2.

There is an isolation barrier between the P1 and P2. I need a serial connection between them anyway so RX/TX are already connected via optocouplers (well, actually digital couplers like the ISO7721). Any additional signal path would cost money and board space.

@Ariba, @tritonium: Thanks, I'll check it out.

ManAtWork

Whoaaa!! The protocol seems to be quite complex. Or it is explained far more complex than it actually is. Or I'm to stupid to understand... But the PropellerLoader.spin code should be easily translated to Spin2 although it contains dependencies on Spin1 interpreter timing. I think the BitsOut() function can be implemented on the P2 with some smart pin pulse/cycle output to have a well defined bit timing instead of runtime and compiler dependant bit-banging.

Thanks again, @Simonius , @Ariba , @tritonium !

iseries

Yes, the loader code is big and complex because of timing on the P1. On the other hand, EEPROM loading is simple and once the program is loaded it can be used for serial communications because you have control over what is loaded from those pins.

Mike

Ariba

I would try something like that for bit timing:

PRI BitsOut(Value, Bits)

  repeat Bits

    if Value & 1

      'output '1' (1t pulse)
      outa[P31] := 0                        
      waitus(2)
      Echo := ina[P30]
      waitus(1)
      outa[P31] := 1
      waitus(6)

    else

      'output '0' (2t pulse)
      outa[P31] := 0
      waitus(2)
      Echo := ina[P30]
      waitus(4)
      outa[P31] := 1
      waitus(3)

    Value >>= 1

I've found once that the a '1t' puls should not be under 2.5us to work with the booter in the P1.

Andy

ManAtWork

@Ariba said:
I've found once that the a '1t' puls should not be under 2.5us to work with the booter in the P1.

Thanks, Andy. The docs say

● Low Pulse (t) ­ Represents bit value 1 
● Low Pulse (2t) ­ Represents bit value 0 
● Low Pulse (t) Width ­ 4.3 μs to 26 μs (recommend ≅ 8.6 μs) 
● High Pulse Width ­ 4.3 μs to 90 ms (recommend ≥ t μs)  

Ariba

I don't think that document is an official spec. looks too overdone. 4.3us is just 230400 baud bittiming, and that may be the highest standard baud rate you can use, if you boot from a PC.
I was booting a P1 from a PIC and raised the baudrate until it failed. It worked up to 400 kBaud, if I remember correctly.

ManAtWork

The P1 has an RCFAST tolerance band of 8 to 20MHz with 12MHz typical. So if we assume that the typical chip fails at >400kBd then it should work with t=3.75us in the worst case. This is quite close to the 4.3µs in the specs.

I think my P1 software will not use the full 32kB and I don't care if booting takes 0.5 or 1s. So 4µs should be a good choice leaving some safety margin. The P2 can do other tasks with the rest of the cogs while booting like auto-calibration of the ADCs. It's good when they have some time to settle thermically. So no hurry.

rosco_pc

Not sure this helps: https://github.com/rosco-pc/propeller-wiki/wiki/Download-Protocol

ManAtWork

Nothing new but far more clear and understandable than the PDF from post #4. Thanks

It will take a while until I can test it. The board doesn't exist, yet.

ManAtWork

Wow, this worked perfectly on the first go! I've just modified the original PropellerLoader.spin slightly for the P2. (as suggested by @Ariba in post #9 but with slightly longer delays)