none
Booting is just not reliable RRS feed

  • Question

  • I have been working on a product that incorporates Raspberry Pi 3 and the official RP 7" touchscreen display.  Product is almost ready to launch, but during testing we have found out that we are having inconsistent booting issues on power up.  We have done all forms of testing to see if the issue is hardware related, but what we have seen is that Windows iOT does not boot consistently.  We have tried multiple PI samples, multiple display samples, isolated the GPIO, tested multiple power supplies powering both through the Micro USB and the GPIO, and multiple SD cards both 16 GB and 32 GB sizes.  Tried powering screen up before powering the PI.  Everything we have tested has been on the recommended compatibility lists.  Card is Samsung EVOs for the most part, but also tested many brands some on the compatibility list and some not.  We have been able to also test with Raspbian Linux with ZERO boot problems...no power supply issue indicators and never a hung boot process over hundreds of power-ups.  Testing multiple builds of Win iOT including the current stable build 15063 and the current 16XXX prerelease builds.  Nothing helps, we are getting approx. 3 boot failures out of 10 power ups (30%), but same exact setup has ZERO failures with Linux.  Boot failure is the unit just hangs after the rainbow screen test on start up.  We have also added commands into config.txt to prevent the rainbow test pattern on boot-up thinking it might do something, but it does nothing.  During a boot failure, we have a red power led and an initial green LED, but screen goes black after the rainbow test screen and no Windows icon with the rolling process balls.  Very rarely, we get a boot selection menu, but that can be resolved with another power cycle.  Tested with no peripherals attached to USB and with and without wired Ethernet.  Tried multiple delay settings in config.txt, timing settings, and other force display settings.  Something is wrong software-wise with the Windows iOT boot process and at this point we don't have a known method to analyze.  Our company has thrown a few thousand dollars at the issue, and at this point, because our app is written in C# and fully developed, we are going to have to include a hardware watchdog to kick over the PI's power if our app does not come up in a given time....our Universal app on running the PI would be used refresh the hardware by cycling power after a power loss triggering an enable input on our power supply.  If anyone has any other ideas to solve this boot problem it would be very helpful.  Someone at MS must have some ideas on this.  Hard to make something that is a reliable IOT device if it won't boot every time.  The hardware based watchdog is a dirty hack that will help the situation but it's just a work-around.  Also I noticed that with the RP build, the core speed should be 400 Mhz on the RP3 but since the build is common to the RP2 and RP3, it's set for 250.  

    Thank you,

    Dan DeMerchant
    Highpower Security Products LLC


    Dan DeMerchant




    • Edited by danoplus Wednesday, August 9, 2017 4:37 AM
    Wednesday, August 9, 2017 2:45 AM

Answers

  • Andre,

    I got UWF installed and applied the exceptions.  It's a home run.  Boot problem has went away and we can not produce a lock up on boot failure.  MS should be telling industrial users more about this feature it brings up reliability when used correctly.  We have to get our app on there and make sure that our data files are being written through the exception but other than that I think that this is licked! SLAM DUNK

    Thanks again,


    Dan DeMerchant


    • Marked as answer by danoplus Thursday, August 10, 2017 9:15 PM
    • Edited by danoplus Thursday, August 10, 2017 9:21 PM
    Thursday, August 10, 2017 9:15 PM

All replies

  • hello

    i only can say to report this through the Feedback Hub as this creates an item within the work database and will be reviewed by the IoT Core Team

    br
    Andre

    Wednesday, August 9, 2017 8:43 AM
    Moderator
  • Hi Dan,

    I have the same configuration as you have, but I don't experience any issues with booting being unreliable. As far as I have understood to have a reliable configuration you need a proper SD card and a proper PSU.

    As I am a Windows Insider I use all the previews from the Fast-ring (now at build 16232) and I have yet to experience any problems with booting (except when you power off the PI uncontrolled. The SD will often go bad that way).

    My PI is fed by a phone PSU (yes, from my Lumia 950XL) and I have a small adapter cable from micro-USB to USB 3.1. That way I don't have to fiddle with the Original micro-USB PSU connector on the PI, which is quite fragile.

    Hope this helps!

    Leo


    Leo

    Wednesday, August 9, 2017 12:50 PM
  • I don't know what to tell you besides maybe you not using it rigorously enough.  There is definitely a problem somewhere on our setups.  Linux boots every time during testing without fail, but IOT does not.  If you do a search online, there are tons of people having booting problems with good power supply setups.

    Dan DeMerchant


    • Edited by danoplus Wednesday, August 9, 2017 2:54 PM
    Wednesday, August 9, 2017 2:47 PM
  • Linux boots every time during testing without fail, but IOT does not.  If you do a search online, there are tons of people having booting problems with good power supply setups.

    you will find tons of people having booting problems with Linux as OS

    i like especially the sentence "With a known good power supply and known good SD card, the R-Pi boots occasionally, but other times shows only a tiny green flicker from the "OK" LED and it fails to start, even with no USB devices and no Ethernet. This has been reported several times and remains an open issue."

    i find it interesting that every OS on the Raspberry Pi seems to fail at the same steps..

    do you really think this is an OS issue ?

    br
    Andre

    Wednesday, August 9, 2017 3:13 PM
    Moderator
  • Sure do.  It's reproducible.  Hardware is all official and known good.  Visit my facility in Connecticut would be happy to review.  Raspian is never failing for us.  We are only using it to test our hardware setups.

    Dan DeMerchant


    • Edited by danoplus Wednesday, August 9, 2017 3:17 PM
    Wednesday, August 9, 2017 3:16 PM
  • so you have 2 SD Cards one with Linux and the other with Windows 10 IoT Core and you swap SD Cards and your Raspberry Pi does not boot with Windows 10 IoT Core but with Linux ?
    Wednesday, August 9, 2017 3:19 PM
    Moderator
  • No, we have approx. 25 SD cards of various brands and types, many of which are official.  8 brand new PIs and several displays.  Multiple people observing and doing power cycle tests.  We have official RP power supplies and custom power supply we designed for the product running at 5.25V @ 6 Amps with low pass filters.  No power supply issue indicators showing.  This is not a hobby project, this is to be a volume product.  We have several images of Raspian and Windows IOT.  The unit boots, it just does not boot consistently, like 3 out of 10 times IOT hangs.  Raspian never hangs.

    Dan DeMerchant


    • Edited by danoplus Wednesday, August 9, 2017 3:32 PM
    Wednesday, August 9, 2017 3:24 PM
  • I am trying to check the LED indicators to see where in the boot process the problem is.

    Dan DeMerchant

    Wednesday, August 9, 2017 3:25 PM
  • Initially when the PI starts, you get a Red LED and two flashes of the Green Activity LED and then the boot process is up and running...you would see Windows logo and the rolling balls...on hangs, you see RED LED, same two Green flashes and then no more Green LED activity, but RED led remains lit consistently.

    Dan DeMerchant

    Wednesday, August 9, 2017 3:28 PM
  • on hangs, you see RED LED, same two Green flashes and then no more Green LED activity, but RED led remains lit consistently.

    2 flashes: The SD Card cannot be read.

    so this seems not OS related

    edit:

    how did you powered Raspberry Pi off with this SD Card before the next boot fails with this state ?

    may be during SD Card writes ?


    Wednesday, August 9, 2017 3:37 PM
    Moderator
  • These are not two flashes one right after another.  The two activity flashes are typical of both a good boot and a bad one.  Trust me we tried MANY cards and MANY PIs.  It's not the card.

    Dan DeMerchant


    • Edited by danoplus Wednesday, August 9, 2017 3:42 PM
    Wednesday, August 9, 2017 3:41 PM
  • other question, what's your future plan ?

    to switch from Raspberry Pi to other boards with no issues like this one ?

    or to stay on Raspberry Pi but switch to Linux ?

    or something else ?

    Wednesday, August 9, 2017 3:55 PM
    Moderator
  • Typically we boot to the default welcome app and then pull power.  If the boot process fails, then cycling power again brings up a good boot.  

    Dan DeMerchant

    Wednesday, August 9, 2017 3:55 PM
  • We can't switch to Linux because the Universal App we have been developing for the last 14 months can't be ported.  At this point our plan is to add a hardware watchdog to the product to make sure that if our app does not boot up after a given amount of time we kick over a reset signal in the power supply.  Sucks and not sure why Linux is more reliable but you have to do what you have to do to ship the product.  No reason to leave the PI as the power is more than sufficient and pricing is super. The product is already developed and circuit board has been laid out for 4 revisions at this point. Our circuit has a lot of added hardware to protect the PI electrically in this application.

    Dan DeMerchant





    • Edited by danoplus Wednesday, August 9, 2017 3:59 PM
    Wednesday, August 9, 2017 3:57 PM
  • Typically we boot to the default welcome app and then pull power. 

    so you don't do a clean shutdown, what if you shutdown the system clean ?

    If the boot process fails, then cycling power again brings up a good boot.  

    that's what also some Linux users have reported

    Wednesday, August 9, 2017 3:59 PM
    Moderator
  • Wednesday, August 9, 2017 4:08 PM
    Moderator
  • One of the test setups on my desk.  We just did six shutdowns from the Welcome App by pressing the power button and doing a shutdown on the touch screen.  I can't really tell when the unit is shut down because the screen just goes blank and eventually the screen shows a brief white field (screen controller is shutting down).  On the first shutdown, we pulled power and then powered up again.  System booted and then ran a disk check.  Once we got back into the Welcome app on the first run, we repeated the process waiting around 10 seconds between pulling power after the white field on the screen appeared.  On the sixth attempt, system froze on boot-up again at the point where the process should start...no Windows logo and blank screen just sitting doing nothing.  A seventh power cycle booted.

    Dan DeMerchant


    • Edited by danoplus Wednesday, August 9, 2017 4:23 PM
    Wednesday, August 9, 2017 4:12 PM
  • Let me read this.  Do we have to implement a shutdown feature in our App?

    Dan DeMerchant

    Wednesday, August 9, 2017 4:13 PM
  • Do we have to implement a shutdown feature in our App?

    well, Raspberry Pi's are designed to stay always on, they are not designed to shutdown like a PC and you have to check the green LED status (flashes 7 times) to know if the shutdown process has ended

    since you never did a clean shutdown before the boot problem occurred i would try this if this change the behavior

    Wednesday, August 9, 2017 4:22 PM
    Moderator
  • Let me install the UWF process and run some more tests.  This was some good information that you sent over thank you!  We know that the PIs are not industrial grade, but for our application it should be OK.  Even with another board type, we would still have SD drive considerations...

    Dan DeMerchant

    Wednesday, August 9, 2017 4:42 PM
  • Something else to look at is the length of the wires between the power supply and the connector into the Raspberry Pi.  If those wires are long and/or thin, you will measure between 4.75V and 5.25V when the Pi isn't running, but when you turn it on, the voltage will drop below the point where the Pi starts to have problems with power.  Everything can look fine when you measure it, but when you power things, you get bitten.

    This is as much for future readers as it is for the topic originator.  If you have an oscilloscope, measure the voltage on the 5V pin(s) while you power the Pi on.

    Wednesday, August 9, 2017 7:07 PM
  • Great, can't get UWF even installed on build 15063.  I brought the files over, did the applyupdate commands which were successful, did applyupdate -commit which was successful.  After reboot, powershell-ed back in and tried to run uwfmgr and it's not found.  Any idea on it's path location?

    Dan DeMerchant

    Wednesday, August 9, 2017 8:26 PM
  • Wednesday, August 9, 2017 8:36 PM
    Moderator
  • Yes did it with a completely fresh install of 15063.   See screenshot.

    Dan DeMerchant

    Wednesday, August 9, 2017 9:14 PM
  • interesting, i did the same except i used the full path instead of .

    could you please execute

    PS C:\> ApplyUpdate.exe -getinstalledpackages | Where-Object { $_ -like "*Unified*" }
    INFO: Microsoft-IoTUAP-UnifiedWriteFilter-Package,mainos,10.0.15063.0
    INFO: Microsoft-IoTUAP-UnifiedWriteFilter-Package_Lang_en-US,mainos,10.0.15063.0

    PS C:\> Get-ChildItem -Path C:\ -Filter uwfmgr.exe -Recurse

        Directory: C:\Windows\System32

    Mode                LastWriteTime         Length Name
    ----                -------------         ------ ----
    -a----        7/29/2017   5:36 AM         139696 uwfmgr.exe

    br
    Andre

    Wednesday, August 9, 2017 9:25 PM
    Moderator
  • On our custom supply voltage is regulated at 5.25V.  I did not measure voltage on the official supply, but in both cases we are not seeing undervolt conditions.  Makes no difference if we supply power to the screen with a separate supply or no on boot up.  We have tested several switching regulators in the design but are finishing the design with the Micrel/Microchip MIC45205.

    Dan DeMerchant


    • Edited by danoplus Wednesday, August 9, 2017 9:35 PM
    Wednesday, August 9, 2017 9:28 PM
  • This is what the product looks like FYI


    Dan DeMerchant

    Wednesday, August 9, 2017 9:44 PM
  • awesome !
    Wednesday, August 9, 2017 9:50 PM
    Moderator
  • No Go.  See pic


    Dan DeMerchant

    Wednesday, August 9, 2017 9:52 PM
  • Now if we can just get issues to a manageable level we can ship this guy.  We are starting on adding the hardware watchdog feature into the product.  The board is basically a PI shield with a display and a secondary ARM processor for high speed input and operations.  The ARM coprocessor runs on a bare metal C program and we are going to put the watchdog in there and have it kick over the MIC power supply if the app does not come up in a couple of minutes...would still like to solve the boot issue though.  The coprocessor and the PI talk to each other over SPI.

    Dan DeMerchant


    • Edited by danoplus Wednesday, August 9, 2017 9:59 PM
    Wednesday, August 9, 2017 9:58 PM
  • I'm guessing that the goal here is to use the UWF to protect the original system image and we will be excluding a few directories, especially the one with our application data...then retest for boot issues.

    Dan DeMerchant

    Wednesday, August 9, 2017 10:03 PM
  • so please use the full path during applyupdate -stage
    Wednesday, August 9, 2017 10:04 PM
    Moderator
  • Unfortunately, no go.  I used two new fresh installations and also re-downloaded the IOT Kit files just in case something was wrong with the file images.  I used full paths both times...I used the ARM platform files. I will have to revisit this tomorrow during the next work day. See screenshot:


    Dan DeMerchant


    • Edited by danoplus Wednesday, August 9, 2017 11:12 PM
    Wednesday, August 9, 2017 11:10 PM
  • hello

    unfortunately i cant replicate this behavior

    i have tried it on 16257 and also 15063 and in both cases i have successfully installed uwf

    br
    Andre

    Thursday, August 10, 2017 1:00 PM
    Moderator
  • Andre,

    Can you give me the source URL and folder path for the source files that you are using to install UWF?

    Wondering why Microsoft does not include this in the distribution.

    Thank you


    Dan DeMerchant

    Thursday, August 10, 2017 2:06 PM
  • Can you give me the source URL and folder path for the source files that you are using to install UWF?

    you mean the the link to IoT Core Kits ? 

    https://www.microsoft.com/en-us/download/details.aspx?id=55031 (the same as mentioned in uwf docs)

    Wondering why Microsoft does not include this in the distribution.

    it does not make sense to include everything in the images which are available to everyone for various reasons

    br
    Andre

    Thursday, August 10, 2017 3:57 PM
    Moderator
  • I did get the software from this URL.  After downloading, I ran the MSI and it created c:\Program Files (x86)\Microsoft IoT\UWF\arm location where the files are.  Are these what you used?  I am trying this again.  Windows iot is writing to the SD during boot?

    Dan DeMerchant

    Thursday, August 10, 2017 4:02 PM
  • i followed exactly the documentation

    Based on your device architecture, copy UWF packages ( Microsoft-IoTUAP-UnifiedWriteFilter-Package.cab and Microsoft-IoTUAP-UnifiedWriteFilter-Package_Lang_en-us.cab ) from your PC (C:\Program Files (x86)\Windows Kits\10\MSPackages\Retail\<arch>\fre\) to C:\UWFTemp.

    and

    applyupdate –stage C:\UWFTemp\Microsoft-IoTUAP-UnifiedWriteFilter-Package.cab
    applyupdate –stage C:\UWFTemp\Microsoft-IoTUAP-UnifiedWriteFilter-Package_Lang_en-us.cab
    applyupdate –commit

    br
    Andre

    Thursday, August 10, 2017 4:07 PM
    Moderator
  • add on, of course you have to use arm as <arch> ...
    Thursday, August 10, 2017 4:32 PM
    Moderator
  • I took the files from the wrong source.  Let me try again and see if I can get this humming.  Thanks for your help.  I will get back to you on findings with boot up issues once this feature is enabled.

    Dan DeMerchant

    Thursday, August 10, 2017 6:09 PM
  • Andre,

    I got UWF installed and applied the exceptions.  It's a home run.  Boot problem has went away and we can not produce a lock up on boot failure.  MS should be telling industrial users more about this feature it brings up reliability when used correctly.  We have to get our app on there and make sure that our data files are being written through the exception but other than that I think that this is licked! SLAM DUNK

    Thanks again,


    Dan DeMerchant


    • Marked as answer by danoplus Thursday, August 10, 2017 9:15 PM
    • Edited by danoplus Thursday, August 10, 2017 9:21 PM
    Thursday, August 10, 2017 9:15 PM
  • MS should be telling industrial users more about this feature it brings up reliability when used correctly.

    well, its already part of the docs...

    anyway happy your problem is solved

    br
    Andre

    Thursday, August 10, 2017 9:22 PM
    Moderator
  • Docs seem to be all over the place...?  This should be turned on as part of the system.  I can't imagine any IOT device running on an SD card that would not want this. I mean it took a few conversations back and forth to come up with the UWF option no? :)

    Dan DeMerchant



    • Edited by danoplus Thursday, August 10, 2017 9:58 PM
    Thursday, August 10, 2017 9:56 PM
  • UWF is not the solution for everything and for everybody and not every user wants to disable Windows Updates

    its part of the docs so its up to everyone to use it or not and the installation is pretty simple

    may be you could speed up the troubleshooting and installation process in the future so it does not took a few conversations back and forth with a working solution at the end ;)

    Thursday, August 10, 2017 10:21 PM
    Moderator
  • I think I mentions that your results was a bit limited in testing, but UWF does help with sudden power loss issue.

    Sean Liming - Book Author: Starter Guide Windows 10 IoT Enterprise - www.annabooks.com / www.seanliming.com

    Friday, August 11, 2017 12:50 AM
  • So tell me again why IOT has to write to the card on boot?  Also, these updates on devices is not such a hot idea.  I had a device set up in my office and it was not an insider preview...then it started updating and updated to a preview.  If your app is tested on a known good installation, why would you want to risk it acting differently in the future with an update?  These are not really PCs but they are being treated as such.  Not a criticism but I've been writing firmware for 20 years and once it's tested on a piece of hardware usually you want to keep things stable.

    Dan DeMerchant



    • Edited by danoplus Friday, August 11, 2017 1:04 AM
    Friday, August 11, 2017 1:00 AM
  • Hi Dan,

    Did it stayed stable after several reboots?

    I went with similar results across of dozen systems literally. The latest finding is that even with UWF enabled and update service disabled, after enough reboots system will hang on … update! which it should not do...

    Get log after crash:

     Get-CimInstance Win32_NTLogEvent > Events.txt

    See with text editor what was your problem.

    Lets see if you have similar findings, my problem was:

    Message          : Fault bucket , type 0
                       Event Name: StoreAgentScanForUpdatesFailure0
                       Response: Not available
                       Cab Id: 0
                      
                       Problem signature:
                       P1: Update;
                       P2: 80070422
                       P3: 17763
                       P4: 253
                       P5: Windows.IoT
                       These files may be available here:
                       \\?\U:\ProgramData\Microsoft\Windows\WER\ReportQueue\NonCritical_Update;_d6a5ecb43cbe9b0b14f24286e50                   9aecd39f32d_00000000_0664b5b3

    Thanks,

    Wojciech

    Wednesday, January 16, 2019 10:37 AM
  • Even with the UWF enabled we noticed the brand and type of MicroSD is still important. Boot failures can occur on both high quality and low quality MicroSD's for whatever reason. We found the Samsung MicroSDXC EVO Plus Memory Card to be the most reliable. We use the 32gb model that costs between $9-$15. These cards are even more reliable on the Windows IOT operating system than the Samsung Pro variant.
    Wednesday, January 16, 2019 4:19 PM
  • This might be a dumb suggestion, but you need to make sure that you turn off the update service BEFORE you turn on the UWF.  If you turn on UWF then deactivate the service, the next time you boot up everything will be back to the way it was as the UWF preserves the protected volume.  I have not seen our devices reboot with the update service disabled...

    Dan DeMerchant

    Wednesday, January 16, 2019 7:29 PM
  • SD is important.  I have had zero problems with the Samsung and the Sandisk Ultra SD cards.  We ship the product with the Sandisk Ultra that we buy in bulk for around $3.50...16 Gb versions.

    Dan DeMerchant

    Wednesday, January 16, 2019 7:30 PM
  • Dan;

    Hey, we have a industrial application were we are using the Pi and a UWP app very similar to your project. I also faced this issue and was very discouraged until I found your post here.  Installing the UWF took care of our boot issues as well.  We have everything working like a charm thanks to this thread.

    However, we are facing a issue with updating the app.  Originally we had it setup were you would click a button and it would check the USB port for an update.  If there was one there it would update the software and reboot.  Now, with the UWF it will update but when you reboot it default back as it should.  We only ever want to update our app not windows or anything else.  With your system do you have it so you can update it without physically going to the customers site to disable the filter update and enable the filter again? 

    I think there are some Registry items that need to be excluded but not sure what.  So, I figured I would take a chance and see if you did anything in this area?

    Thanks

    Paul

    Friday, September 13, 2019 2:32 AM
  • I actually do not know how you would perform an app update via USB, and if you can give me a method for how this is done, it would be interesting to me. 

    Is this update just a data update or actually updating the application?  We do data updates via USB by excluding the data folder for our application in the UWF exclusions.

    We have been shipping quite a few of these products lately all with the UWF turned on.  We also, in later hardware versions had to scrap our "watchdog" feature as it didn't work out properly.  Originally, we had a processor on our product that acted as a watchdog for the PI...and if the PI didn't fire up to our application, the watchdog never got reset and a PI reset would then occur.  The only problem we found out that sometimes Win IOT takes longer to boot on the Pi3 for whatever reason (drive repairs?) and the watchdog put the product into a continual reboot cycle, causing much damage to the SD card in the process despite the UWF.  After ditching this feature we originally thought was a good idea, customers have not had any problems with just the PI3 running with the UWF filter.

    To handle updates we do one of a few things, which are cumbersome.  1) log into the customers computer remotely, powershell to the device, turn off the UWF (or put it into service mode), remove the old app using web interface on port 8080, add the new app with any new requirements, keep the powershell open to turn back on the UWF and reboot, cumbersome as hell but it works 2) next day air or mail the customer a spare or updated SD card (easy but costly) or 3) have the customer swap out the whole motherboard (costly also but great with customers that are not savvy).  This method is good because we can include hardware improvements along with software updates.  It's expensive doing this, but it does provide us as a company the ability to provide customers with refurbished update units for service issues..  Obviously none of these methods are ideal. 

    We have been treating this product line up to now as a hardware fleet that requires service procedures whether physical circuit repairs or software repairs that are slightly cumbersome.

    You might be able to add a bunch of exceptions to the UWF in order to perform updates without turning it off or dropping to service mode (which is recommended method) but these exceptions would leave areas like where your app is unprotected. 

    In short, you need to use the UWF to deploy WinIOT in environments where you could loose power at any time for reliability but it really puts a cramp in your style when it comes to updates.  In the future, we may have to incorporate a charge to the customer if it's a feature update, but in our corporate case, many of the updates were bug related in both the hardware and the software so our policy has been to quickly perform one of the above procedures with early adopters that are not up to a particular software version or hardware revision.  Kind of like when you break a screwdriver and you bring it back to Home Depot and they give you a new one without hassle under warranty, which is what we have been doing. 

    Our customers appreciate the service and although we are actually putting them through additional steps, they are happy.  We also have the hardware and software in a stable place now so the upgrade cycle is slowing down.  In the future, if we add new features, and there are many requests, we have not decided yet how to handle  the update requests.  Perhaps sell them a new mailed SD card.

    Not ideal for sure.  Wish there was a better way. 

    Weird to me also that Microsoft expects these devices to update on their own when the UWF is not used.  They are not PCs.  I treat my Windows core as a fancy micro-controller really.  Our product is used in our case for door control...anyone at any time could swipe their card and try to get in and if the unit is in an update cycle people could get locked out of their facility until the unit finished updating, which is why we appreciate that UWF requires updates to be shut off.

    We are experimenting moving from the PI to the MX8 platform, but that it pretty complicated.  I expect the use the UWF with this platform also although this platform has a chip that might be more reliable than the SD card for boot storage.  We found that we have to re-compile our app for 64 bit operation on this platform and that is what we are working on at the moment...future roadmap in the case the PI3 is not available and always looking for more performance from newer parts...

    The gratuitous pitch, our website featuring the new product: www.highpowersecurity.com

    Overall I'm proud of it and the .NET core app I built for it is really huge amount of code.


    Dan DeMerchant




    • Edited by danoplus Friday, September 13, 2019 3:30 AM
    Friday, September 13, 2019 3:10 AM
  • Thank you for the quick response and information. I was certain with this being an old thread I may not have heard from you :-) I would defiantly like to talk further with you on projects, even though they are totally different we share a common core (Raspberry Pi, UWP, Iot Core). I'm sure we could be of assistance to each other.

    Being our project is new as well it is extremely important to be able to update from our app.  We don't let it update from the web only USB. This allows us to control who gets the update and when.  This is a very nice feature and I can defiantly share how to do this with you.  As others have helped me along the way.

    Maybe it would be easier to do through normal E-mail rather than expanding this thread to all different topics.

    Paul

    Friday, September 13, 2019 12:15 PM