Prop2 Flash loader

2»

Comments

  • With 'FLASH' on and both P59 switches off you only have 100mS to start serial comms after reset.
    After that time if a valid 'Prop' checksum is calculated from the 1024 bytes loaded, from SPI FLASH, the code executes.
    This will block ypu from starting TAQOZ from a terminal.
    Melbourne, Australia
  • samuell wrote: »
    evanh wrote: »
    samuell wrote: »
    evanh wrote: »
    Try turning on P59 Up. I can make it program with both P59 Up and Down on together.
    Thanks evanh! That worked while programming with Spin 2 GUI. I get the program loaded up and apparently running. P56 blinks, although it doesn't show anything on the terminal yet.
    Next step is turn P59 Up off again and press the reset button.
    Strange, after pressing reset, with P59 Up already in the off position, P56 blinks no more. ...
    At that point it has run and finished. If you didn't have the terminal monitoring already then you would have missed the report.

    P56 blinking just indicates that programming of the flash is complete. To get it to run from the flash requires the reset. So, repeated resets will keep rerunning the program in flash.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • ozpropdev wrote: »
    With 'FLASH' on and both P59 switches off you only have 100mS to start serial comms after reset.
    After that time if a valid 'Prop' checksum is calculated from the 1024 bytes loaded, from SPI FLASH, the code executes.
    This will block ypu from starting TAQOZ from a terminal.
    Thanks! That's what I thought.
    evanh wrote: »
    samuell wrote: »
    evanh wrote: »
    samuell wrote: »
    evanh wrote: »
    Try turning on P59 Up. I can make it program with both P59 Up and Down on together.
    Thanks evanh! That worked while programming with Spin 2 GUI. I get the program loaded up and apparently running. P56 blinks, although it doesn't show anything on the terminal yet.
    Next step is turn P59 Up off again and press the reset button.
    Strange, after pressing reset, with P59 Up already in the off position, P56 blinks no more. ...
    At that point it has run and finished. If you didn't have the terminal monitoring already then you would have missed the report.

    P56 blinking just indicates that programming of the flash is complete. To get it to run from the flash requires the reset. So, repeated resets will keep rerunning the program in flash.
    So, how can I see the report? I'm programming with Spin 2 GUI and see nothing on the terminal window after I press the reset button, with the switches in the correct position.

    Kind regards, Samuel Lourenço
  • Oops, I never ran Oz's version. There is 20 seconds pause before the number gets printed. You might not be waiting long enough.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • I seem to need the P59 pull-up on in order to reprogram flash.

    Also, don't need the P59 pull-down for anything...
    Prop Info and Apps: http://www.rayslogic.com/
  • evanh wrote: »
    Oops, I never ran Oz's version. There is 20 seconds pause before the number gets printed. You might not be waiting long enough.
    Well, I notice that the cursor on the Spin 2 IDE terminal advances every so often. This might be an issue with the baud rate.

    Kind regards, Samuel Lourenço
  • RaymanRayman Posts: 9,486
    edited 2019-01-21 - 16:43:42
    My plan to use this to automatically load flash from SpinEdit isn't going so well...

    I can't figure out why hardcoding the file size doesn't work...

    In this test, I've just hard coded the file size and commented out the 3 lines that overwrite the file size. Doesn't work... Can't figure out why not...

    It works for the a very small program like "Larson scanner", but not this big one...
    Prop Info and Apps: http://www.rayslogic.com/
  • Never mind, figured it out...
    Added this line to fix it.
    rdlong byte_count,##size
    
    Don't know why, but it works...

    So, I take the fastspin binary of this and remove the last 32 bytes (fastspin seems to pad the end with 28 bytes of zero for some reason) to remove the file size. Then, I add the filesize. Then, add the program's binary. Add in those 28 zeros (just in case). Load this into ram and it programs the flash.

    Now, I have Load Flash option in SpinEdit. Thanks ozpropdev!
    Prop Info and Apps: http://www.rayslogic.com/
  • Hi ozprodev

    I am using your flash loader to load Catalina programs into Flash on the P2_EVAL - many thanks!. But I have noticed that it sometimes does not program correctly on the first attempt, but generally seems to work on the second.

    Have you seen anything like this in your own testing?

    Ross.
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • I see it predates the discovery about unreliable PLL mode switching. He's used the older simpler method that is known to randomly fail.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • evanh wrote: »
    I see it predates the discovery about unreliable PLL mode switching. He's used the older simpler method that is known to randomly fail.

    Ah! Thanks. I will amend the program.
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • evanh wrote: »
    I see it predates the discovery about unreliable PLL mode switching. He's used the older simpler method that is known to randomly fail.

    Hmmm. Still having problems. Can you point me to the correct way we are supposed to set the clock on boot? I thought I was doing it correctly, but perhaps I am not.
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • Here's my write up - https://forums.parallax.com/discussion/comment/1466702/#Comment_1466702

    There was also a big discussion in another topic. Basic structure is to remember and reuse the prior mode config to cleanly switch back to RCFAST clock source before making any adjustment to PLL configuration.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • Hi RossH
    I haven't had any issues with the flash loader so far.
    I've been using it for quite some time now with my micropython stuff.
    My eval board does seem to behave slightly differently to others though. :)
    Melbourne, Australia
  • ozpropdev wrote: »
    Hi RossH
    I haven't had any issues with the flash loader so far.
    I've been using it for quite some time now with my micropython stuff.
    My eval board does seem to behave slightly differently to others though. :)

    Yes, it might not be the P2 itself. It could be the P2 EVAL board. Or the boot ROM. I have noticed some odd things previously - they generally seem to sort themselves out with enough power cycles, SD Card removal/re-insertions and/or reboots :(

    But your flash loader is very useful - thanks!
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • Ross,
    IIRC the current ROM boot code for SD can leave the DO pin from the SD card driven. This interferes with the Flash SPI such that it will not work. This has hopefully been fully corrected in the new ROM by forcing the SD card to release DO after each use/transaction.
    Not sure if this is causing your problems.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Ross,
    IIRC the current ROM boot code for SD can leave the DO pin from the SD card driven. This interferes with the Flash SPI such that it will not work. This has hopefully been fully corrected in the new ROM by forcing the SD card to release DO after each use/transaction.
    Not sure if this is causing your problems.

    That may be causing some odd problems I was having with some other code, even if it is not causing this particular problem.
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • For the current engineering samples, consider that if you access the SD, then Flash is a no-go, even after reset!!!

    There was an old thread where this was discussed as there is a sequence of clocks (96*8) if memory serves me correctly to force the sad to release the DO pin.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
Sign In or Register to comment.