Shop OBEX P1 Docs P2 Docs Learn Events
Using the P2 ROM monitor for debugging — Parallax Forums

Using the P2 ROM monitor for debugging

David BetzDavid Betz Posts: 14,516
edited 2013-03-28 18:38 in Propeller 2
It seems many have fallen in love with the P2 ROM monitor and I don't blame them. It provides some nice on-chip debugging assistance. I'm wondering though how this is going to work once we move to the real P2 and production boards. We've already seen that it is necessary to pull the SPI flash chip from the FPGA boards to get into the ROM monitor because otherwise the P2 boot ROM will start the program in the flash instead of entering the monitor. This is fine on the FPGA boards because the SPI flash chip is in a socket. What happens on production boards which most often have soldered-on chips? It seems like it will be necessary to either provide a jumper to disable the SPI flash chip or to program something bogus into it that won't pass authentication. The nice thing about the ROM serial loader is that it will work even if there is a program in the boot flash without modifying the flash. How do we expect this to be handled when using the ROM monitor to do debugging on a production board or any board with a soldered-on SPI flash chip?

Comments

  • SapiehaSapieha Posts: 2,964
    edited 2013-03-28 08:42
    Hi David.

    That is NOT necessary --- You need only run slightly modified Chip's "programmer.spin" that remove PROGRAMMED flag in Flash



    David Betz wrote: »
    It seems many have fallen in love with the P2 ROM monitor and I don't blame them. It provides some nice on-chip debugging assistance. I'm wondering though how this is going to work once we move to the real P2 and production boards. We've already seen that it is necessary to pull the SPI flash chip from the FPGA boards to get into the ROM monitor because otherwise the P2 boot ROM will start the program in the flash instead of entering the monitor. This is fine on the FPGA boards because the SPI flash chip is in a socket. What happens on production boards which most often have soldered-on chips? It seems like it will be necessary to either provide a jumper to disable the SPI flash chip or to program something bogus into it that won't pass authentication. The nice thing about the ROM serial loader is that it will work even if there is a program in the boot flash without modifying the flash. How do we expect this to be handled when using the ROM monitor to do debugging on a production board or any board with a soldered-on SPI flash chip?
  • potatoheadpotatohead Posts: 10,261
    edited 2013-03-28 08:47
    Seems to me one could always include a call to the monitor with any signed program. It's not like it won't run signed, it just won't run automatically.

    Whether or not the monitor runs on boot then is up to the developer no matter what the board looks like right? This isn't any different than thoes autoload EEPROM programs on P1.

    If somebody does that, they essentially have a signed booter, that will then load unsigned code and or the monitor. Great for development, then when it's time for field deployment, remove those things, and it's just a signed booter loading the authorized code set.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-28 08:50
    potatohead wrote: »
    Seems to me one could always include a call to the monitor with any signed program. It's not like it won't run signed, it just won't run automatically.

    Whether or not the monitor runs on boot then is up to the developer no matter what the board looks like right? This isn't any different than thoes autoload EEPROM programs on P1.

    If somebody does that, they essentially have a signed booter, that will then load unsigned code and or the monitor. Great for development, then when it's time for field deployment, remove those things, and it's just a signed booter loading the authorized code set.
    This is true but it requires the cooperation of the program stored in the SPI flash or it requires that a program be downloaded over the serial port. You can't get to the ROM monitor otherwise unless there is no flash or it contains a program that won't authenticate. If you're going to download something with the serial loader, you may as well download your own monitor program. No real advantage is gained bu having the monitor in ROM at that point. This is one reason why I preferred more hub RAM to a monitor in ROM.
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-03-28 15:20
    David Betz wrote: »
    This is true but it requires the cooperation of the program stored in the SPI flash or it requires that a program be downloaded over the serial port. You can't get to the ROM monitor otherwise unless there is no flash or it contains a program that won't authenticate. If you're going to download something with the serial loader, you may as well download your own monitor program. No real advantage is gained bu having the monitor in ROM at that point. This is one reason why I preferred more hub RAM to a monitor in ROM.

    While I don't disagree that I would have preferred other things (like SD boot), that is what we have.

    This is my understanding of the inclusion of the Rom Monitor...
    The SPI flash runs if there is valid code in the flash because that is what is expected to run. That code can get to the monitor if required. You want to ensure authorised protection.
    If there is no flash, or it is unprogrammed, and no code protection, then the rom monitor runs. This allows a user to play with the prop quite simply.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-28 17:42
    Cluso99 wrote: »
    While I don't disagree that I would have preferred other things (like SD boot), that is what we have.

    This is my understanding of the inclusion of the Rom Monitor...
    The SPI flash runs if there is valid code in the flash because that is what is expected to run. That code can get to the monitor if required. You want to ensure authorised protection.
    If there is no flash, or it is unprogrammed, and no code protection, then the rom monitor runs. This allows a user to play with the prop quite simply.
    Yes, I understand this. My problem with this is that once you've programmed the flash, you can't ever get back into the monitor without either trashing what is in flash or doing a serial download and starting the monitor from the downloaded program. Once you have to download a program, there is no real advantage to having the monitor in ROM. Essentially, it is only useful if you have an unprogrammed flash chip or if you have a program in flash that starts the monitor. And, if you have a program in flash that is willing to start the monitor, it could just as easily load it from flash rather than start it from the ROM. Anyway, as you say, it's there and it *is* handy for initial prodding of hardware before you get into serious program development.
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-28 17:59
    Hi David.

    You can have any data in Flash that You can use without starting it -- Boot see only Flash as programed if You place that in it.

    data7E0 byte long $00000001[8]

    You only need erase that positions in Flash -- Not entire data to be able starting with Monitor

    data7E0 byte long $00000000[8]

    Look in my post in this thread.

    http://forums.parallax.com/showthread.php/144683-Propeller-II-programing-questions-to-Chip?p=1173213&viewfull=1#post1173213

    David Betz wrote: »
    Yes, I understand this. My problem with this is that once you've programmed the flash, you can't ever get back into the monitor without either trashing what is in flash or doing a serial download and starting the monitor from the downloaded program. Once you have to download a program, there is no real advantage to having the monitor in ROM. Essentially, it is only useful if you have an unprogrammed flash chip or if you have a program in flash that starts the monitor. And, if you have a program in flash that is willing to start the monitor, it could just as easily load it from flash rather than start it from the ROM. Anyway, as you say, it's there and it *is* handy for initial prodding of hardware before you get into serious program development.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-28 18:12
    Sapieha wrote: »
    Hi David.

    You can have any data in Flash that You can use without starting it -- Boot see only Flash as programed if You place that in it.

    data7E0 byte long $00000001[8]

    You only need erase that positions in Flash -- Not entire data to be able starting with Monitor

    data7E0 byte long $00000000[8]

    Look in my post in this thread.

    http://forums.parallax.com/showthread.php/144683-Propeller-II-programing-questions-to-Chip?p=1173213&viewfull=1#post1173213
    That is true but you still have to write to the flash to re-enable the monitor and after doing that you will no longer be able to boot from flash until you reprogram it. That seems unfortunate and awkward to me.
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-28 18:15
    On emulators You need only rewrite.
    data7E0 byte long $00000001[8]
    To re-enter Boot from it.

    On real P2 -- I dont know what type of check value Chip will use


    David Betz wrote: »
    That is true but you still have to write to the flash to re-enable the monitor and after doing that you will no longer be able to boot from flash until you reprogram it. That seems unfortunate and awkward to me.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-28 18:38
    Sapieha wrote: »
    On emulators You need only rewrite.
    data7E0 byte long $00000001[8]
    To re-enter Boot from it.

    On real P2 -- I dont know what type of check value Chip will use
    You'll still have to rewrite those same bytes. It's just that with the real P2 those bytes will contain a real signature not just a dummy one like on the emulator.
Sign In or Register to comment.