Anyone have a good idea on how to get rid of the startup delay?
I want to use the GPIOs to bit bang a SPI bus, and I have it sort of working, but there is a 10-15 second delay on startup that locks up my circuit board. I tried going into the start of the BSP and setting all of the IOs to inputs (tri-state), but that only gained me a second or two.
Why on earth does it sit there doing nothing for so long?
-Erik
In case you’re still wondering, make sure that you uploaded the modified bootloader as well. The bootloader sets the GPIOs according to your BSP customizeSetupPortA function, then you get a long delay while it decompresses the application image. Once the application image starts, it also calls the customizeSetupPort functions.
Why are you having problems with the SPI bus? By default, don’t the GPIO pins power up high (as inputs)?
On the subject of reducing the boot time on a -C module, using the development kit, the knowledge base article at the following URL discusses a number of changes that can be implemented which, combined can produce a system which can boot in as little as <4 seconds.
http://search2.digi.com/support/kbaseresultdetl.jsp?id=943
Cameron
How do you update the bootloader? I don’t have any documentation newer than NetOS 5 except HLP files.
Thanks,
-Erik
You can find all the new documentation at
http://www.netsilicon.com/support/netos6.xuserguides.jsp
It sounds like you already did this, but make sure that you’ve editted customizePortA to reflect the changes in the GPIOs that you want. Once that is complete, you can rebuild the bootloader. I’ve only done this using the GNU tools. To rebuild the bootloader you need to go to netos60_gnu/src/bsp/ and do a “make PLATFORM=connectme clean” and a “make PLATFORM=connectme all”. In the distribution I have (6.0e) this also builds the bootloader, which you can find in /src/bsp/bootloader/romImage/rom.bin
You’ll then need to upload that image to your device just as you would a normal image file. Note that some versions of the connectmes have their bootloader blocks locked; I don’t think there would be a solution for you in that case.
That is where the confusion was - I work with the original modules (like the new -S) that have the bootloader locked.
Oh well, cest la voix!
-Erik
No, by default they are high, but as outputs. I need them to start as inputs (tri-state).
-Erik
Erik,
You may want to look at:
http://www.netsilicon.com/pdf/appnote_reducebooting.pdf
Hope it helps
The document is nice, but will this eliminate the 30 second power up time before applicationStart() is called?
I’ve noticed that the boot ROM will decompress the boot RAM image. Is this needed if the run-time image is CRC’d okay?
Can we eliminate this step, run the CRC check on the image, decompress the image into RAM, and then run it? All from the boot ROM code?
Also, how much time does it really take to run for loops to decompress the image? Is it really that much time?
Oh, here is another suggestion: in bsproot, there is a while loop waiting for ip_configured flag to change. If you remove the TCP down timer, and this while loop, the applicationStart() will be called a lot faster. The only problem is that before you start any network tasks, you will have to wait for the ip_configured flag to be set to IP_STATE_INITIALIZED.
Tim