5 Replies Latest reply on Oct 23, 2020 3:39 PM by LePo_1062026

    Bootloadable HEX File Reverse Engineering

    DaGr_294516

      I'm trying to do some manipulation of Bootloadable hex file for a custom application and I'm struggling to understand a couple of things.

       

      I have a very simple Bootloader/Bootloadable application - it starts in bootloader, pauses, runs the main app for two seconds then switches back to boot loader. So far so good.

       

      I want to be able to extract only the bootloadable region for insertion into another application. I need the meta data as well. I'm examinging the hex file and I can see the bootloader at the beginning then a region of bootloadable starting at row 0x1000 (as set in the bootloadable component so that makes sense).

       

      Then I get a region of of bootloadable application. So far so good.

       

      Then for some reason, at address 0x27000, I get another region of non zero data - Any idea what that might be about??

       

      My main question though is about the meta data. As far as I can tell from the datasheet, the last 64 bytes of the last row should be meta data, so I'd expect a final line of 64 bytes in my hex file.


      However, the end of my hex file looks like this. That last line contains only 12 bytes, which isn't enough to be even the info fields of the meta data without the reserved regions..

       

      Also, what are those random bunches of 5, 5 and 2 bytes at 0x90000000, 0x90000010 and 0x90000030 respectively.

       


      I've attached the hex file. Any insights very gratefully received. Happy to post more info/project files if needed.

       

      Thanks in advance

       

      Dan

        • 1. Re: Bootloadable HEX File Reverse Engineering
          LePo_1062026

          Dan,

           

          There is a hex file format document available.  I'm not sure where it is on the Cypress site.  Try this:  https://community.cypress.com/external-link.jspa?url=http%3A%2F%2Fwww.cypress.com%2Fdocumentation%2Fprogramming-specific…

           

          Here are reasons I'm aware of for post-loading unique data into each PCB built.

           

          Serial number (Manufacturing encoding)

          Many companies will include a unique Serial number that can identify metrics of when the board was manufactured.  If there is a communication standard being used for the product, It is common to create a set of manufacturing specific diagnostic codes to load the Manufacturing metric data into EEPROM.   A form of communication standard is the Bootloader.   The Bootloader code supplied by Cypress can be modified to add diagnostic extensions for this purpose without resorting to modifying the hex file.

           

          Serial number (Unique system or Global ID)

          Many companies will include a unique Serial number to uniquely identify the board in a system (like a PC host) or globally when data is exchanged in a WAN.   The Cypress Silicon ID is commonly used in BLE and USB to provide a unique-like number for this purpose.  This silicon ID is added to the PSoC chip at Cypress manufacturing.

           

          Calibration Data

          When using sensors, it is common to calibrate the sensor measurement components to a known reference.   To do this, an application needs to be running and communicating to external equipment to force a known stimulus and instruct the end-device to make the sensor processing correction to the expected output result.  The correction factor is then stored into EEPROM.

           

          If you are using the first Bootloadable code as this calibration application, once completed and the correction value stored, the second Bootloadable application can be the customer-targeted application with the correction factor that can be read from EEPROM.

           

          Is any of these types of uniqueness what you are trying to achieve?

           

          Len

          • 2. Re: Bootloadable HEX File Reverse Engineering
            DaGr_294516

            Hi Len,

             

            Thanks for you reply. I did have look for the PSOC 5 hex format on the Cypress website but couldn't find it. I'll have another look. Maybe I'm not searching for the right thing...

             

            What I'm actually trying to do is implement a non-standard bootloading mechanism. It needs to work through our own communication stack that's already highly integrated with an existing product. There are multiple psocs on a custom bus and I need to be able to bootload any of them from our host software.

             

            The way I was intending to do that is have a very simple copier style bootloader, and use our main psoc program (which already handles the coms, checks integrity, can write to flash and importantly works with our driver) to receive and store the new program in a spare region of flash. Then the bootloader would then simply copy it over the main application.

             

            I know how to do all of that, except how to extract the bootlloadable application and the metadata reliably from the compiled hex.

             

             

            I guess there are probably other ways to accomplish the high level goal... If there's a more obvious way to do it, I'm open to suggestions but I suspect this way will save me a lot of work. I'm tantalisingly close - I basically have all the other elements in place from existing features. Also, this is they way we've implemented bootloading previously on other MCUs so it's got the advantage of familiarity...

             

            Cheers,

            Dan

            • 3. Re: Bootloadable HEX File Reverse Engineering
              LePo_1062026

              Dan,

               

              The pdf link I provided describes the hex format in some detail.   The question:  Did it cover enough for you?

               

              Len

              • 4. Re: Bootloadable HEX File Reverse Engineering
                DaGr_294516

                I had actually already found a definition of the hex format - my interpretation of the data just didn't seem to match with what I was expecting to see and where.

                 

                I have actually worked out what was going on though I think...  I've found the meta data - I was just looking in the wrong place!! #rtfd

                 

                Those random bits and pieces at the end of the hex are actually way past the end of the flash address space. I still don't know what they mean, but I don't think i need to worry about it...

                 

                Thanks for your help

                Dan

                • 5. Re: Bootloadable HEX File Reverse Engineering
                  LePo_1062026

                  Dan,

                   

                  I looks like you're on the right track.

                   

                  Thanks for your help

                  I'm not sure I was any help but at least I tried to be.

                   

                  Len