A definitive guide on uploading programs by other means than proptool+propplug

pems

Hi all

I would like this thread to be a collective effort at demystifying all the details and gotchas associated with the funky serial protocol and timing of the prop programming sequence.
I am trying to implement a system where another micro would initialize prop upon system reset (i.e no flash chip on pins 28,29 at all). This is needed in order to speed up the prop start-up delay (currently it's unacceptable for my application - around 1 second delay)

Below, i will outline my experiences with the uploading.


first off, here are references to "prior art": (thanks all who contributed to these threads)

loader protocol discussion
http://forums.parallax.com/showthread.php?p=670593

python based loader
http://forums.parallax.com/showthread.php?p=622354

also, you will find a zip attached with Csharp source of a loader written by someone whose name unfortunately escapes me. This code helped me the most out of all available loaders written by the community



continued in next post...

pems

So, i've decided to start the journey of making an externally loadable prop from trying to load a program using a simple serial comm app (written in c) running off cygwin of my winxp laptop.

I am attaching my messy serial_test project (comments should help making sense of it). Credit for some of the code i reused here goes to the guy who wrote the CSharp loader (sorry, don't know your name), and whoever wrote the captain example of serial port comms in C.

Also see Chip's doc on the boot sequence (attached)

I used propplug with this serial_test to talk to the prop proto board. I've gotten as far as getting LFSR's and prop version back from prop, but could not load the actual binary.
In the code's defense, i've tried the tried and true pyloader on the same system (cygwin+xp) and it could not load the binary either, so i am thinking it's not the code's problem but rather perhaps some delays in communication (which make or break this communication with prop as witnessed by hippy)

What i found very strange (see comments in the serial_test code, ser.c file) is that i had to have a specific range of delay between sending the initial LFSR+F9's sequence and starting to receive the LFSR response from the prop in order to get the right LFSR sequence.


More on my experiments with external micro bootloading later

jazzed

Now this is timely[noparse]:)[/noparse] Thanks for sharing!
I would like to be able to download over a bluetooth modem or a network attached serial port. Any chance that might work?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

pems

jazzed said...
Now this is timely[noparse]:)[/noparse] Thanks for sharing!
I would like to be able to download over a bluetooth modem or a network attached serial port. Any chance that might work?

no problems, just passing the love along [noparse];)[/noparse]

What i (and others) found is that timing makes and breaks everything in the bootloading. Whatever you do, make sure your comms are VERY timely, in regards to both delays between communications and consistency of the data stream over the UART. One basically has to realize that prop's comm line for bootloading is more of a synchronous link as opposed to asynchronous (what UART is). It's just implemented ratiometric-aly to bridge the two.


anyway, here are the results of my latest observations trying to receive the correct LFSR sequence. I am using an USART port on the other micro along with DMA transfer mechanism to ensure that UART pipelines are always filled (see previous paragraph for importance of this)

btw, the 100ms from reset to start of comms is VERY important - make sure to tune your delay loop appropriately if real time (as in microseconds, milliseconds, etc) delays aren't used - which is my case here.

EDIT not a problem, i was just confused, read EDIT below

So, my current problem is that the input buffer seems to contain some garbage sequence for first 5 bits/slots (out of the received 250).
I figured that out by comparing the send and receive buffers. For some reason it receives the following sequence prior to receiving the normal LFSR sequence that was sent and in my send buffer (after the starting 0xF9 of course): 0xFE, 0xFF, 0xFE, 0xFE, 0xFE which translates to %01000 - what is this?

edit: forgot to add: last 5 slots are missing in the received LFSR sequence, instead there is just the version 8 slots (0x1)

EDIT: LOL! please disregard the above problem. silly me, it wasn't even a problem - i was supposed to be comparing the input buffer with running LFSRs and not with what went in the send (out) buffer.

Post Edited (pems) : 9/5/2008 6:15:59 PM GMT

pems

Small update:

I've succeeded loading program into RAM and running it (yip-tee-do! )

In retrospect: the 100ms initial delay after restart is actually quite flexible. I cannot tell in terms of actual milliseconds but, from experimentation, in terms of wait cycles the range of deviation it would still work with was quite broad

Basically, i ended up just putting everything that's being sent over: - initial f9, lfsr's, f9's to receive lfsr's and version back, encoded program - all in one big array. Then just scheduled to send this array on the UART peripheral using DMA (i am unsure if doing this using interrupts would feed UART fast enough and result in transmission consistent enough for the delay-sensitive bootloading of prop).

The important part was to wait certain amount of time (again, i use cycles, so don't have a solid time figure. Use Chip's recipe attached in my first post) before sending f9's with delays in-between after sending the encoded program.

So, my primary objective with this was to speed up the reset-to-start time that prop normally takes when loading from the flash or even from propplug at 115200. A second or so of total delay when loading from flash is unacceptable for my project.
I plan to load up a small program, let's call it 2nd bootloader, over the UART with the method above. Now i have to come up with a way to load the rest of the program over something faster than UART - either a single SPI @ 10 or 18Mbps or even a parallel bus. I hear people did 4 parallel lines + clock.

Post Edited (pems) : 9/11/2008 12:48:41 PM GMT

Ariba

I had a lot of problems to write a bootloader for Linux in PureBasic. Fortunately Chip has released the Original Boot code in the ROM, so I took this Source and made a modified version, that only shows where the Download failes. It uses 3 LEDS on P16,P17 and P18 to show a status. All the routines come from the Original code, so the timing is exactly the same as the ROM bootloader.

Because this can be useful for everyone, who writes his own Loader Application, I release it here.
You have to write the code to the EEPROM and also have to modify the Reset sequence a little bit to use this code (see description at CON section).

Andy

Paul Baker

Jazzed, as mentioned in the other thread both bluetooth and internet have variable timing between packets, the Propeller has very strict timing requirements on it's serial programming. This means there is almost no chance of being able to directly program a Propeller through bluetooth or internet. In order to make this work you would have to have another microcontroller receive the datastream and temporarily store the program, then upon completion of the program transmission, program the Propeller through a directly connected interface to pins 30 and 31 using the same protocol a directly connected PC would use.

Because of this long delay, and the Propeller Tool is expecting the Propeller to be directly connected, it is doubtfull you could use the Tool to transmit the program through Bluetooth or internet. You would have to create your own PC program to send the program datastream.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 9/11/2008 5:05:31 PM GMT