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.
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.
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
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.
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.
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.
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.
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)
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
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....
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.
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.
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.
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.
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.
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.
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.
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.
Comments
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.
The JS STAMP.
That means you need some additional ISP method to first program the device.... Ugh..
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
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.
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.
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
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:
Amazingly, when I finished the code it came to exactly $200 longs of code and data.
Is there a means to fast-skip the Try-Serial ?
Maybe a pulldown on RX could be a signal to skip serial?
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 ?
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
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....
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.
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.
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.
But nonetheless, a pulldown on say CS would be fastest to boot.
Yes, but I'd like to make it use a single cog, in case we ever make single-cog versions.
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.
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.