Help with a EEPROM boot loader

bambino

I've been trying to replace this program with a simple hello world app by writting it to the eeprom then rebooting. I've worked out the bugs in my visual basic app and can send 32 bytes at a time to the prop. My problem is no doubt in my use of the I2C object, as I have not used it much.
Could someone look at the code here and see if anything jumps out. I have not made an installer for the vb app so you couldn't test it, but perhaps something is obvious.
Thanks

Mike Green

The first REPEAT is wrong. The 2nd change I made is cosmetic:

pub flash | total, page, idx, j, start_time
    com.rx
'   repeat j from 0 to constant(($8000/PAGESIZE)-1)
    repeat j from 0 to constant(($8000/PAGESIZE)-1) step PAGESIZE
      repeat page from 0 to num
         buffer[noparse][[/noparse]page]:=com.rx
      com.rxflush
      i2c.WritePage(i2c#BootPin, i2c#EEPROM, (j*PAGESIZE), @buffer, PAGESIZE)
      start_time := cnt ' prepare to check for a timeout
      repeat while i2c.WriteWait(i2c#BootPin, i2c#EEPROM, (j*PAGESIZE))
        if cnt - start_time > clkfreq / 10
          quit
      readit
'     eepromAddress := eepromAddress + 32
      eepromAddress := eepromAddress + PAGESIZE
      repeat page from 0 to num step 2
        com.tx(buffer[noparse][[/noparse]page])
        com.tx(buffer[noparse][[/noparse]page+1])
      com.str(string("endofstring"))   
      com.rxflush

bambino

Thanks Mike!
It loops through, but I'm still not rebooting into the Hello World app. So it may still be my vb app isn't sending the correct sequence!
Thanks for your time.

kuroneko

@bambino: I assume your 'Hello world' app runs when started from RAM (functional test)!? You can use the attached application (courtesy of Phil) to read back the EEPROM content (into a *.eeprom file) and compare it against what you programmed from your VB app. That might give you an idea where it goes wrong.

bambino

@kuroneko

Indeed, It does run from ram.

I was just thinking before leaving the shop that I needed to write it to upper 32k, and read back what I'm writting.............. And finding the time to write this code!................. Thanks...I could have reinvented the wheel!

Mike Green

If you haven't already, you might look at the COPY statement code from FemtoBasic. One section of that copies a file from an SD card to any 32K block of EEPROM 32 bytes at a time. It's roughly lines 1080 through 1111.

bambino

I think WOW was the word I used. I didn't know Phil had made such a program.
I doubt I would have been reinventing this wheel. Thanks.

Thanks mike, I think this will help me see whats going on now.

bambino

Well I ran my app and then Phils unload program and it says the file is 0k bytes. So somehow my code is wipeing the eeprom clean instead of writting my hello world app.

kuroneko

You mean it's empty (file size should be 32K)? What h/w are you using?

I noticed that if the system is under heavy load the download may fail (empty file). This is probably due to a connection timeout. A console window should pop up and show a download countdown.

bambino

I am using a usb protoboard. The upload program works great after I load eeprom with the prop tool, but after my app runs I get O.
Here's a cool point: I modified my vb app to stop sending if it didn't get back what it sent. It delays on the first write of 32 bytes and shows that the eeprom has only the first 16 bytes. Does the I2c object require a 64 instead of 32 where it asks for the count paremeter?

bambino

Just ran the app with the count set to 64 instaed of 32 and get up to the 4th set of 32 bytes when my vb app gets gibberish in it's buffer.

bambino

This one here will send and receive fine the first 3 iterations and then the upper 16 bytes· of the 4th read from the eeprom shows up gibberish.

Unsoundcode

Hi Bambino , messed with this some more today. Really doing well but can only write the first 512 packets (16K byte) . Here's a VB snippet that writes 0 through 31 to the first 512 32 byte packets.

[color=#0000ff][color=#0000ff]Dim[/color][/color] fileContents() [color=#0000ff][color=#0000ff]As[/color][/color] [color=#0000ff][color=#0000ff]Byte[/color][/color] = [color=#0000ff][color=#0000ff]New[/color][/color] [color=#0000ff][color=#0000ff]Byte[/color][/color](31) {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}
SerialPort1.Write([color=#a31515][color=#a31515]"S"[/color][/color])
[color=#0000ff][color=#0000ff]For[/color][/color] x = 0 [color=#0000ff][color=#0000ff]To[/color][/color] 1024
Threading.Thread.Sleep(15)
SerialPort1.Write(fileContents, 0, 32)
[color=#0000ff][color=#0000ff]Next[/color][/color]
MsgBox([color=#a31515][color=#a31515]"done"[/color][/color])

Attached is the spin file that writes the EEPROM adapted from Mikes example

Jeff T.

To read the EEPROM I used the same file attached in the Sandbox thread.

bambino

Thanks unsoundcode,

I won't have time this morning, but hopefully tonight. It's not looking like my first device will go out with this code in it, but the second will I guess.

Unsoundcode

I have been thinking (and learning) about the page write size , the data sheet says my EEPROM is capable of a 64 byte page write.

I don't know whether this would have an effect on the way my data is being stored or not but if I have the time this evening I will adjust the write loop to 64 bytes . The spin file is a little sloppy but I'm sure you will see whats going on , maybe you can also try the 64 byte page write.

Jeff T.

Edit : BTW the thread sleep pause in the VB loop may or may not be able to be got rid of , it's there for now to slow things down while testing.

bambino

I increased to 64 and was able to write 512 pages before failing.

So many apps take bin's from an sd card, but woe unto he that attempts it through a serial port. I didn't realize how slow my grasp of this was going to be this week.

kuroneko

bambino said...
I increased to 64 and was able to write 512 pages before failing.

What does the failure look like? Is it that you end up with 512 pages new stuff followed by the previous content or is it all (32K) new but just garbled from this point onward?

Also, I assume a dry run works OK, i.e. receiving data and sending it back without actually programming it? For test purposes you could insert an artificial delay (e.g. 5ms) instead of the program call.

Unsoundcode

Hi , the problem with the write was due to the scope and data type of a variable. Once I had that sorted I was able to read , write and dump to screen the EEPROM contents.
Once this was resolved and I got the test data to write to all 32K of EEPROM memory I played around writing different packet sizes , its possible to do 64 byte packets but I got better results writing 32 byte packets. Finally I tried it with the obligatory "Hello World" program and it worked fine.
The VB app needs a couple of·file dialogs to choose where to save and what to open and generally clean the file selection process up rather than keep it hard coded. It also needs several other cosmetic touches to get it to behave in a more user friendly manner.

To test:
Go to vb design view and set the com to match your com port #
In vb code view change the 3 instances of file path and location to suit your own preferences
Load your own "Hello World" program into the Prop [u]EEPROM[/u]
Load Bootloader spin ( contained in the zip file ) into the Prop [u]RAM[/u]
Run the vb app and READ 
Overwrite your "Hello World" program thats in the EEPROM and reload Bootloader into [u]RAM[/u]
Go back to the VB app and hit the write button 
When thats done reset the Prop an test for the "Hello World"

Tweak this as you desire and use as and if you wish. I have tried it a few times and it looks good , if there are any problems I can help with let me know

Jeff T.

bambino

@Kuroneko No, The vb app I was using sends 32 bytes to the prop, which writes then reads, and sends tose 32 back to the PC.
The PC would compare sent 32, and received 32, then move on or stop if data was the same, respectively

@unsoundcode The last of my parts needed to build a unit are due here today. So many thanks, I was getting nowhere!

bambino

@unsoundcode, Other than changing the Port # and the file location, this worked straight out of the box. Many thanks. As fate would have it my parts are not here. Something about some silicone glue needing to dry overnight before I can pick it up.
That's good though, it will give me a chance to look over your code and find out what I kept running into. And even with a progress bar it loaded fairly quickly.

This would make an excellent object. Everyone is posting for the update from sd card, where as I'm surely not the only one that needs to update serially from a pin other 30, and 31.
Only problem is the vb app. I guess you could post in this thread when your done.

I'll continue to work with you on it, just bear in mind that my finished app will target a PDA. Most everything will still apply though. I doubt I'll be able to transmit faster than 56k though using 2008. Which is a big gripe I have with MS.. 2005 proved, with the help of a CFserial object, that 270k was possible with a PDA. All I had back then was a trial version and ended up with 2008, with limits port speed to a number less than 63768.

Unsoundcode

That's excellent news Bambino , thanks for the feedback. If you think it would make a good object go ahead and do it , I am not very Prop savvy just yet and I am sure you would make a better job of it than I. As a side note , I thought earlier today about the spin code involved and the 3 objects it contains , it makes things very very much easier . Credit is due to all that have submitted to the Obex and in this particular case Mike Green , Martin Hebel and Chip Gracey

The project as a whole is interesting especially the PDA aspect , if it's possible to somehow link your spin object to some small Visual Basic application I may go ahead and ·finish what I started.

Jeff T.

bambino

There in is the problem, no matter what the spin object turns out to be, It will be dependant on the vb app for it's protocol. It may be a while but I don't mind posting it here for you. And when I say thanks, I mean thanks alot because I am pretty much going to abandon the angle I was using and use your code. The string builder object works great for my device, but this boot loader was not taking to it. I'll probably only use the write function and add some sort of homebrew crc to check each page as it is sent. And it would ultimately use a hardcoded eeprom file, as I don't want the end user to flash the wrong data to the device.

I think I can add the file functions to your app as is though. One thought that I had was to close the serial port when downloads where complete.
This would allow you to turn around and use the new code with say the serial terminal without haveing to shut down the app. Then reopening the port when a button was pushed.

Unsoundcode

Bambino , your opinion on a couple of things and a question. I was wondering whether your intention is to download the whole 32k or write to a pre-defined block of memory. I see potential in enabling the user to write a certain area of EEPROM if needed.

With regard to error checking I had originally thought of downloading the source , then uploading the destination and comparing the two. VB has functions for creating checksums for files , pros .. the code is there ,·cons..·consumes more·time.

I would also appreciate a pointer to the documentation that describes the Propeller programing protocol ( RAM / EEPROM )

Jeff T.

Mike Green

Here's a Propeller loader written in Spin to document the protocol:

http://forums.parallax.com/showthread.php?p=591445

bambino

Indeed, I was shooting for a whole 32k download process that was super simple for and end user(with no spin, vb, or programming experience at all) to flash the update to the propeller. I have spent a lot of time getting my device to be functional. Looking back, however, I see alot of changes I would make if I had time to start from scratch. My device wieghs 20lbs and it would be a shame for people to have to mail that back to me just to have an updated program.

The idea of writting to certain addresses would not be a big jump from what you have now! increase your buffers from 32 to say 64( out of thin air).
Send your data just as you are now but make the spin code filter out the second set of 32 bytes. Have your arguments for address, offsets, bytes-to-write, etc. encoded into that second set of 32 bytes.

CRC's unfortunately are not within my grasp( other than their purpose). I downloaded some material once and was planning to learn more about what is actually happening during a crc, but wrapping this product up has barely left me time to walk my dog. My plan was to send each packet back for comparison and continue or resend the packet. If speed becomes a problem I thought I might just add the 32·bytes together and send that sum back for comparison. That is what I meant by homebrew crc.

I will not be useing the programming pins, but rather a serial connection with a blutooth radio, so the propeller chip programming protocol is and will remain a dark fog on the horizon for me. Fascinateing what Phil did with the load ram program above. My next project is allready waiting on me so I want have time to follow you down that road if you try to write programs of that nature. If you do, look at what Mike is referring to and the Propellant application in the downloads section. Get them two to talking and the possibilities are many to say the least.

Unsoundcode

Thanks guys , of course my mind is racing with different possibilities and I am not naive enough to think all my thoughts are original as I have already seen many brilliant applications along the same vein.

The first thing that strikes me is the possibility of loading our "loader" spin·program to RAM via the VB program thus cutting out the Proptool. Keeping the "loader" would be nice I think because it gives us the additional option of altering·specific EEPROM contents ,·on the fly if need be. I am lost with the explanation of how and where to write those bytes but I will make up.

Downloading and uploading the same file then using a file checksum to compare the two seems like it would work pretty well .

My set back is time just as it is with yourself·, I check the forums throughout the day but being able to sit and program for fun for 2 or 3 hours is very rare .

As soon as I have something worth showing I will post it here .

later

Jeff T.

·

Unsoundcode

@Bambino , I have a VB app here that makes use of the Propellent dll . If you can fit this application and the Propellent dll onto a PDA it might be exactly what you need for your end user.

I still have features that I would like to include for my own preferences and that is why I have extra room on the main form. If you decide to check it out and feel it suits your needs let me know.

To get up and running put the Propellent dll in the system directory and run the setup file contained in the zip.

Jeff T.

bambino

My understanding of propellant is that it uses programming pins only! 30 and 31. If it can do other pins then yes, It would probably be the ticket. Am I wrong , will it allow me to load eeprom from my serial port on pins 27 and 26?

Mike_GTN

Hi Jeff,

Whilst I can not add anything to the help you are offereing here, I would be interested in seeing how you have used Propellent.dll from within VB.Net I do recall looking at this quite some time ago but found problems and gave up after a few hours.

I think would make an excellent tutorial for many people.

Thank-you for any light you can throw on this.

Regards

Mike.

Unsoundcode

Hi Mike , Managing the calls was a little tricky from my point of view and took a little trial and error . Everything seems to work fine but I could not say 100% that there are no errors in the sub/function signatures.

I placed the instruction FinalizeDLL() in the Form closing event and though it maybe overkill I also included the garbage collection instruction GC.Collect.

I only needed 5 of the library functions so they are the only ones I tried and tested , I attach an Open Office document with the declarations and usage.

Also an image of an app I used the library with that I called Prop Remote for off site downloads , if that name is in use I may have to rethink.

Jeff T.