Shop Learn
Prop2 ROM code - Page 4 — Parallax Forums

Prop2 ROM code

1246719

Comments

  • jmgjmg Posts: 14,857
    edited 2016-08-04 23:37
    tonyp12 wrote: »
    PSoC 4200L with USB2.0 $2.95 @ 1K
    Low Power 1.71 to 5.5 V Operation
    Use point and drag schematic for custom smart pins, including opamps
    48 pin LQFP
    Does that have a ROM-based USB loader ? (maybe we need a new thread for Stamp-2016 upgrade musings...)


  • tonyp12tonyp12 Posts: 1,950
    edited 2016-08-05 00:18
    No, There is a hid usb boot loader that you can drag and drop in to you project schematic.
    There is emulated eeprom, but complete erase of secured flash would remove this and the loader.
    So let user only get access to it with HID (no driver needed) and don't let bootloader erase itself.

    SiLabs (Happy Gecko) installs a usb bootloader in flash at the factory, but the optional erasablility is on by default,
    so you would needed to reflash the same bootloader but remove the erasability check.




  • Heater.Heater. Posts: 21,233
    jmg,
    Yes, or even JavaScript, especially for Heater
    Ha, I was purposely not saying that here.

    The JS STAMP.
  • Heater. wrote: »
    jmg,
    Yes, or even JavaScript, especially for Heater
    Ha, I was purposely not saying that here.

    The JS STAMP.
    The BASIC/JS/FORTH/LISP Stamp.

  • jmgjmg Posts: 14,857
    tonyp12 wrote: »
    SiLabs (Happy Gecko) installs a usb bootloader in flash at the factory, but the optional erasablility is on by default, so you would needed to reflash the same bootloader but remove the erasability check.
    The HG is not 5V Drive or 5V ADC, so it does not make the short list.
    tonyp12 wrote: »
    No, There is a hid usb boot loader that you can drag and drop in to you project schematic.
    That means you need some additional ISP method to first program the device.... Ugh..
    tonyp12 wrote: »
    There is emulated eeprom, but complete erase of secured flash would remove this and the loader.
    So let user only get access to it with HID (no driver needed) and don't let bootloader erase itself.
    Sounds too fragile for a Basic Stamp level of product.
    The PSoC4 scores well on Wide Vcc, but it is light on RAM, & 48 pin part also limits code & it is M0 only, not M4 ( for more $ ?!)

    Nuvoton show up to 256KF/32KR available in TQFP48.
    I downloaded their NuMicro_ISP_Programming_Tool_Rev1.47
    Looks to use HID, & nicely includes the Source, so you could thus add a button to something like PropellerIDE


  • tonyp12tonyp12 Posts: 1,950
    edited 2016-08-05 01:09
    Psoc5 $3.44 @ 1K (CY8C5267LTI-LP089)
    ARM Cortex-M3 67MHz 128KB flash and 32K ram.
    It's looks like i2c factory installed boot loaders only.

    It got real 2K eeprom, and better segmented flash locks.
  • cgraceycgracey Posts: 13,638
    Cluso99 wrote: »
    Chip,
    Any news on the shuttle run?
    New FPGA binary date?

    BTW I tested the shared LUT between cogs (without interrupts). Nice!!!

    Test chips are supposed to back near the end of this month.

    I'm working on the new boot loader, still. I had a realization today that the events need to be reorganized a little to accommodate more than one pin-edge event. With smart pins, edge events become critical. What I'm thinking I'll do is combine the pin-edge and LUT-r/w events so that we can have up to three pin-edge events. This is a minor change, but will allow multiple smart pins to act as interrupt sources.

    An FPGA update is probably a week away.
  • cgracey wrote: »
    Cluso99 wrote: »
    Chip,
    Any news on the shuttle run?
    New FPGA binary date?

    BTW I tested the shared LUT between cogs (without interrupts). Nice!!!

    Test chips are supposed to back near the end of this month.

    I'm working on the new boot loader, still. I had a realization today that the events need to be reorganized a little to accommodate more than one pin-edge event. With smart pins, edge events become critical. What I'm thinking I'll do is combine the pin-edge and LUT-r/w events so that we can have up to three pin-edge events. This is a minor change, but will allow multiple smart pins to act as interrupt sources.

    An FPGA update is probably a week away.
    Hi Chip,

    I wouldn't mind to see photos of those chips. I want to take a look for the sake of my curiosity.

    Kind regards, Samuel Lourenço
  • cgraceycgracey Posts: 13,638
    edited 2016-08-25 23:59
    I finally got the new ROM booter done. It's amazing how much more complex things get when you are dealing with text, instead of binary. There are a lot more potential failure points that have to be handled.

    This still needs testing to make sure the SHA-256/HMAC code works properly. I need to modify PNut.exe next to accommodate this new scheme.

    Here is the ROM booter's flow:
    timeout = 100ms
    try serial
    	if load successful, send "PASS", execute (done)
    	if command received and error, send "FAIL"
    
    try SPI flash
    	if load successful, execute (done)
    
    timeout = 60s
    try serial
    	if load successful, send "PASS", execute (done)
    	if command received and error, send "FAIL"
    
    load shutdown program, execute (done)
    
    
    
    try serial:
    	clear command flag
    	if any command, set command flag
    		wait for valid command
    			if load successful, pass
    			if timeout, fail
    			if wrong chr, fail
    			if wrong signature, fail
    

    Amazingly, when I finished the code it came to exactly $200 longs of code and data.
  • RaymanRayman Posts: 12,322
    should work as .zip file, at least I think...
  • cgracey wrote: »
    I finally got the new ROM booter done. It's amazing how much more complex things get when you are dealing with text, instead of binary. There are a lot more potential failure points that have to be handled.

    This still needs testing to make sure the SHA-256/HMAC code works properly. I need to modify PNut.exe next to accommodate this new ROM booter.
    Looking forward to trying it out.
    I'm trying to post the code here, but the forum software is telling me that ".spin2" is not an allowed filename extension. How can this be? It wouldn't let me post the raw code, either, as it was ~4300 characters too long. These limitations are ridiculous. I'll email the web monster at Parallax.
    I've had to ZIP code to get around the the spin2 extension issue.


  • jmgjmg Posts: 14,857
    cgracey wrote: »
    Here is the ROM booter's flow:
    timeout = 100ms
    try serial
    	if load successful, send "PASS", execute (done)
    	if command received and error, send "FAIL"
    
    try SPI flash
    	if load successful, execute (done)
    

    Is there a means to fast-skip the Try-Serial ?

  • cgraceycgracey Posts: 13,638
    Here's the ROM booter:

    ROM_Booter_Prop2.spin
  • RaymanRayman Posts: 12,322
    skipping serial is interesting... I think Prop-side RX would be pulled high if there was a serial chip connected.

    Maybe a pulldown on RX could be a signal to skip serial?
  • jmgjmg Posts: 14,857
    Rayman wrote: »
    skipping serial is interesting... I think Prop-side RX would be pulled high if there was a serial chip connected.

    Maybe a pulldown on RX could be a signal to skip serial?
    Ideally, you want to be able to have a serial part connected, just skipped by a bridge+resistor.

    During reset, pins should not float, but need either light pull-up, or pull-down. This keeps current predictable and avoids mid-threshold lotteries...

    With open collector and active low selects, the common choice seems to be light pullup.

    Perhaps a pull-down resistor on the Chip Select line of SPI could signal Skip Serial ?
  • Thats an interesting idea.

    You'd probably want to make sure it was low for at least a few byte periods just to make sure there isn't a serial stream that happens to be sitting on 0 momentarily
  • cgraceycgracey Posts: 13,638
    Skipping serial would save 100ms. Is that very much time?
  • jmgjmg Posts: 14,857
    cgracey wrote: »
    Skipping serial would save 100ms. Is that very much time?
    It might be quite important, eg in a watchdog recovery situation.
    Even a live update usage, where you download new code, then reset-to-apply clean, that can be a long time...

    To me, it seems best to avoid any brick-walls in the ROM, as they will be very hard to fix later....

  • ElectrodudeElectrodude Posts: 1,440
    edited 2016-08-26 03:03
    Can you have it set up a smartpin to listen for serial and set interrupts on it for receive and autobaud, and then have it start loading the flash while it's waiting for serial? Then, if a host PC shows up, an interrupt will fire which will stop the flash loader and go to the PC loader part. That way, it can be doing something useful while waiting for a PC, in case there is no PC.
  • cgraceycgracey Posts: 13,638
    edited 2016-08-26 03:21
    We could always load and verify the flash first, then use it if nothing comes in serially within 100ms.

    It would probably take 50ms to load and validate the flash. This would just delay how soon a host could attempt to send something after a reset. I think that would be hardly noticed.
  • cgraceycgracey Posts: 13,638
    The original Propeller skips the serial if RX is low. We can do that, too.
  • jmgjmg Posts: 14,857
    edited 2016-08-26 04:13
    cgracey wrote: »
    The original Propeller skips the serial if RX is low. We can do that, too.
    I think that makes sense with i2c loading, as there are little other 'involved pin' choices, but it does conflict with any connected serial port, that you do want to use for other than Boot.

    With P2 having SPI-boot, the CS# pin of the SPI is available, and that could be used with no impact on serial-connected devices.
    ie It is treated same as on P1, if CS# is read as LOW, then Skip Serial Wait.
    cgracey wrote: »
    We could always load and verify the flash first, then use it if nothing comes in serially within 100ms.

    It would probably take 50ms to load and validate the flash. This would just delay how soon a host could attempt to send something after a reset. I think that would be hardly noticed.

    That could be useful, tho it sounds like the code gets larger to do this ?
    It saves total time, but does not avoid the dead-time problem after a watchdog reset ?
    Checking CS# for low, would allow a very short watchdog recovery time - a small flash stub load is all that is needed, likely measured in microseconds.


  • cgraceycgracey Posts: 13,638
    jmg wrote: »
    cgracey wrote: »
    The original Propeller skips the serial if RX is low. We can do that, too.
    I think that makes sense with i2c loading, as there are little other 'involved pin' choices, but it does conflict with any connected serial port, that you do want to use for other than Boot.

    With P2 having SPI-boot, the CS# pin of the SPI is available, and that could be used with no impact on serial-connected devices. It is treated as on P1, if CS# is LOW, then Skip Serial Wait.
    cgracey wrote: »
    We could always load and verify the flash first, then use it if nothing comes in serially within 100ms.

    It would probably take 50ms to load and validate the flash. This would just delay how soon a host could attempt to send something after a reset. I think that would be hardly noticed.

    That could be useful, to it sounds like the code gets larger to do this ?
    It saves total time, but does not avoid the dead-time problem after a watchdog reset ?
    Checking CS# for low, would allow a very short watchdog recovery time - a small flash stub load is all that is needed, likely measured in microseconds.

    Using CS as a determinant means there must be a pull-up or pull-down.
  • jmgjmg Posts: 14,857
    cgracey wrote: »
    Using CS as a determinant means there must be a pull-up or pull-down.
    Yes, but if the pins are defined during reset with a light pull up, that's ok ?

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-08-26 04:37
    We do need a fast boot time for restart as the equipment I have been designing P2 into would not be very happy to wait 100ms. I wouldn't like to see the receive line pulled down though as this is what I use to reset my Tachyon software through a break condition. Ideally a pulldown should not be applied to a chip select either but it shouldn't hurt either. My feeling is that if the PC initiated the reset it should perhaps send a break or null characters at least to signal a serial load but in the absence of any such signal we can assume that the PC is not trying to load the Prop. Multiple samples of the receive line only need to detect a few low samples within a brief period to assume that it should attempt serial boot.

    But nonetheless, a pulldown on say CS would be fastest to boot.
  • Why not do both at the same time? Isn't that what this thing is supposed to be good at?
  • cgraceycgracey Posts: 13,638
    Why not do both at the same time? Isn't that what this thing is supposed to be good at?

    Yes, but I'd like to make it use a single cog, in case we ever make single-cog versions.
  • Martin HodgeMartin Hodge Posts: 1,246
    edited 2016-08-26 06:53
    ..........................
  • cgraceycgracey Posts: 13,638
    Think about this scenario: some host is trying to send a program, but it doesn't have control of RESn. It's sending the Prop_Chk command over and over until it gets a response. It's likely that the chip sees a low on RX, first thing, but it's just part of a byte. You would not want to go boot from flash in that case. Also, the host could be sending at any baud rate, so you have no way of knowing if that's a break or a bit. On the Prop1, there is an orderly sequence of reset, then communication. This new scheme is more flexible.

    I think accommodating serial means giving it an initial time allowance, then checking the flash, then retrying serial with a longer timeout. If there is no way for serial to butt in, a system could get stuck with whatever's in the flash. Then, there needs to be some jumper to allow serial by not automatically loading from flash. Getting rid of that 100ms creates complexities.

    Also, these pins are going to float on reset. It's too late to change that around.
  • cgraceycgracey Posts: 13,638
    There is a 20ms hardware timer on RESn. Any reset event gets an additional 20ms.

    I estimate reading the flash takes 16ms. I will measure the HMAC compute time tomorrow.

    These are all things that can't be gotten around, and add to any serial allowance.

    I heard the Raspberry takes 1 minute to boot.
Sign In or Register to comment.