5 Replies Latest reply on Mar 8, 2018 9:54 AM by jett

    Using mass storage for device programming?


      Folks, this is a request for input.


      KitProg (and MiniProg3)  has a mode that implements a mass storage connection to the target device. So you can drag a Cypress-compatible hex file onto the target.It isn't really a file system, it intercepts the file transfer request, parses the hex file, and programs the target.


      Does anyone use this feature? If so, why? Any pros and cons? It strikes me that this is not used by the vast majority of developers. My typical build process is to use the flash capability of the IDE I'm working in, OR, a programmer like PSoC Programmer.





        • 1. Re: Using mass storage for device programming?

          I would like to use this mode for programming a PSoC 5 development kit from the Linux command line, but I am currently trying to figure out if this is possible.


          I have a prototype robot that's using a Raspberry Pi for high-level tasks and a CY8CKIT-059 for low-level tasks. In daily operation, the PSoC device is physically inaccessible, and programming requires minor robot disassembly, but I have a network connection to the Raspberry Pi. I'm trying to plug the KitProg on the unsnapped CY8CKIT-059 into the Raspberry Pi so I can upload .hex files to the Pi over the network and then copy them to the KitProg drive to program the PSoC.


          When I try this, it does take some action. The program on the target device stops running for some time when a .hex file is copied to the mounted device on Linux. But, if the note below is accurate, the PSoC 5LP on the CY8CKIT-059 board isn't supported.


          Directly after exiting and entering mass storage mode and mounting:

          After copying a .hex file to the disk:

          Too bad, because this would be my use case. I don't see any reason to have an alternate way to program it when connected via USB cable to my Windows development machine.



          • 2. Re: Using mass storage for device programming?

            I tried it on Windows as well:


            Seems like this really does only work for PSoC 4 devices?

            • 3. Re: Using mass storage for device programming?

              Thanks for the feedback Dan.


              Like the note says, Only PSoC 4 families are supported. The programming algorithms for PSoC 4 and PSoc 5 differ. Only the PSoC 4 is supported.


              What happens when you drag a file, the file transfer process is intercepted and something completely different happens. Which is.... firmware parses the hex file and calls the programming algorithms to flash the target. So in fact no file every really moves. This simplifies programming from the user end - you don't have to invoke a programmer, that happens transparently. But in fact you are invoking a "hidden" programming tool.


              As you note, if you're connected to a development machine, mass storage programming is pretty pointless. But you describe the kind of case where it might be useful.Thanks!

              1 of 1 people found this helpful
              • 4. Re: Using mass storage for device programming?

                I wonder if Cypress has any plans to develop this mode for the PSoC 5.


                I've started another thread here asking the same: Updates on PSoC 5 Mass Storage Programming?


                I think I'm going to order a couple of CY8CKIT-043 and see how hard it would be to port my application to a PSoC 4 for short-term convenience. I suppose that making my project bootloadable and writing my own Linux tool to load firmware over the UART or something is the only way for me to achieve what I want to do with the PSoC 5.

                • 5. Re: Using mass storage for device programming?



                  At the moment, no plans to implement mass storage programming for PSoC 5. Part of why I asked the question is to get actual customer feedback on this whole issue. As you noted, from a developer tools perspective, the main use case does not require mass storage programming.