Shop Learn
Proposed loadp2 changes — Parallax Forums

Proposed loadp2 changes

I'm working on some changes to loadp2 and would like some feedback from interested parties before I release an "official" version. The changes affect only the fast loader (-CHIP) and add the following features:

(1) Autobaud detection: the fast loader no longer relies on the frequency and clock settings sent by the host to be accurate. It does apply the clock mode setting (so it will be running faster than RCFAST) but it doesn't use the frequency; instead the host sends some space characters and the fast loader detects those and sets the baud accordingly. This should allow downloads to work on boards other than the P2ES without needing an accurate -f option, so the defaults for FlexGUI will (I hope) work for all boards.

(2) Multiple file support: loadp2 can load multiple files into memory at the same time. For example you can do something like:
   loadp2 -b230400 @0=vgaprog.bin,@1000=picture.bmp
to load vgaprog.bin at 0 and picture.bmp at $1000, and then execute vgaprog.bin. The loaded data may optionally be preceded by its size by usiing "@ADDR+" instead of "@ADDR=". For example:
   loadp2 -b230400 @0=flashloader.bin,@1000+myprog.bin
will put the size of "myprog.bin" at $1000 and the actual contents of myprog.bin at $1004.

The changes are in github now, so if you're able to build and test them I'd like to hear your results. Suggestions for improvements to these features are also welcome.

Eric

Comments

  • jmgjmg Posts: 14,822
    ersmith wrote: »
    (1) Autobaud detection: the fast loader no longer relies on the frequency and clock settings sent by the host to be accurate. It does apply the clock mode setting (so it will be running faster than RCFAST) but it doesn't use the frequency; instead the host sends some space characters and the fast loader detects those and sets the baud accordingly. This should allow downloads to work on boards other than the P2ES without needing an accurate -f option, so the defaults for FlexGUI will (I hope) work for all boards.
    It's nice to have the fine control of a full HEX clock config word, but that will be cryptic to most users.
    Maybe loadp2 can take a Xtal spec (default 20MHz) and a SysCLK desired, and create a clock setting itself (which it reports).

  • evanhevanh Posts: 11,906
    I suppose the multi-file support could be very handy for filling a boot EEPROM with megabytes of content data. And being able to specify placement means not having to keep reprogramming them for every update.
  • evanh wrote: »
    I suppose the multi-file support could be very handy for filling a boot EEPROM with megabytes of content data. And being able to specify placement means not having to keep reprogramming them for every update.

    The placement only works in HUB memory; loadp2 still doesn't understand how to program boot EEPROM. Indeed, the multi-file support is how I plan to implement programming EEPROM, since it allows us to download a flash programmer (like yours) and a file to program, without having to re-compile the flash programmer.

    Unfortunately I'm having trouble with flash programming this way. Really simple LED blink type programs work with this scheme, but longer programs do not. I don't think it's a problem with the loader itself (the loadp2 fastload code has a checksum and seems to be working). More likely it's some bad interaction between the loader and flash programmer, or a misunderstanding I have about how the flash programmer works, or (probably less likely) a bug in the flash loader... it almost acts as though it's only programming the first part of the downloaded code.
  • evanhevanh Posts: 11,906
    With Brian's Flash_loader.spin2 demo code, the SPI chip definitely is programmed in two parts - matching the resulting two stage booting.

    First part is is a fixed 1 kByte in length and is what the ROM will initially load from the SPI chip. It has a checksum in the last longword. Brian has this padded, with an ORGF $100, so that the adjoining main code is not overlapping the runtime placed checksum.

    Second part has a "size" value to also be filled at programming runtime. This tells the second stage booter how many bytes to read to load the main program. If left at a value of zero then it won't complete the boot.

  • I think I found the bug -- I had left some old code in when I converted the flash loader to use data from memory. The version now checked in with loadp2 seems to work, that is after compiling "board/P2ES_flashloader.bin" one can do:
       loadp2 @0=board/P2ES_flashloader.bin,@1000+whatever.bin
    
    to program "whatever.bin" into the SPI flash. I plan to make this into a menu command in the next release of FlexGUI.

    If you leave off the "@1000+whatever.bin" then the flash loader just programs a blinking LED, as it did before. But if you add it, then the code in the flash loader (including the code size, in the first long) gets overwritten by the 4 byte size of whatever.bin followed by the file data.

    Thanks for your help!
Sign In or Register to comment.