Flashing a cyacd file without having the original bootloader

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
burner
Level 1
Level 1
5 sign-ins First solution authored First reply posted

Hello everyone!

I am trying to flash a brand new PSoC 3 microcontroller after the old one died (and was replaced on the PCB). All I have is the precompiled .cyacd file. No access to the original code or the original bootloader code.

After following the tutorials and reading the documentation, I have successfully created an I2C bootloader and flashed it to the uC. I cannot just flash the bootloadable (.cyacd) file because of the following error: "The bootloader reported error 'Packet length invalid: the packet's length does not conform to the required packet format, see the Bootloader section in the System Reference Guild for the correct format'. "

So, I also created a new project and compiled a bootloadable file for my I2C bootloader, in order to see the output cycad format. I noticed that the row length of the original .cyacd is shorter than mine (525 vs 589 characters per row).  With a custom python script, I was able to reduce the row length, recalculate each row checksum and then I could upload the new file. However it shows an error at the end of the upload progress bar: "The row checksum does not match the computed value."

 

I uploaded these 2 files in fw.zip (see below)

Although The Get flash size, Send data, and Verify row commands are required by the Cypress
Bootloader Host tool, I noticed that the bootloader must also have the Verify application checksum.  If I uncheck this feature, the Bootloader Host returns "Unknown command " instead of the "The row checksum does not match the computed value." error

 

To recap: is there another way to flash the .cyacd file? (I don't even need the bootloader)

Am I missing something about the verify application checksum? I think this throws the error. I was hoping that disabling the bootloader application validation will make it work. Any tips for further documentation will be appreciated.

burner_0-1636711881960.png

 

Bootloader application validation
If this option is enabled, the bootloader validates itself by calculating the checksum and comparing it with the saved one that resides in metadata. If the validation is not passed, the device is halted. If this option is disabled, the bootloader is executed even if it is corrupted. This could lead to unpredictable results.
The basic summation checksum is computed by adding all the bytes (excluding the checksum) and then taking the 2’s complement

 

 

0 Likes
1 Solution

Take in consideration the 

.cyacd file format:
    [4-byte SiliconID][1-byte SiliconRev][checksum type]
    The data records have the format:
    [1-byte ArrayID][2-byte RowNumber][2-byte DataLength][N-byte Data][1byte Checksum]
    The Checksum is computed by summing all bytes (excluding the checksum itself) and then taking the 2's complement.

courtesy of https://github.com/gv1/hex2cyacd

If you look at the Byte L and convert these values back into HEX, you will notice this is the difference (between my own bootloadable and the original one) in data row that was preventing me to flash the bootloadable (DataLength).

burner_0-1637167995653.png

 

View solution in original post

0 Likes
6 Replies
KyTr_1955226
Level 6
Level 6
250 sign-ins 10 likes given 50 solutions authored

Hi,

I don't have a specific solution, but here's a few things to consider: 

Firstly, I don't actually know for a fact that what you want to do is possible (loading a cyacd without the original loader), but personally I'd imagine that you should be able to do it so long as the new loader settings match the original, and you are loading the same model PSoC.  It's entirely possible someone who knows more will chime in and tell me I'm big wrong, but my gut feeling is that you should be able to get it working.

I think it's worth noting that the "Invalid Packet Length" message from the bootloader is what I would expect to see when the bootloader receives a packet from the host with an incorrect or mismatched length. Consider the bootloader packet structure:

KyTr_1955226_0-1636729534594.png

The error you're seeing is probably because the Data Length word does not match the number of data bytes actually being sent in the packet, at least, that's how I've seen that specific error show up in the past.  If it was a problem with the cyacd file itself I would imagine an error would be thrown when the cyacd file is being parsed rather than showing up as an error in the bootload process.

As far as the cyacd file, you probably don't want to touch it if you can possibly avoid it.  If you open the cyacd file in your text editor of choice, you should be able to confirm the row length based on the DataLength word of the each cyacd row:

KyTr_1955226_0-1636731098095.png

Also note the 1-byte checksum type field in the header, this is what communicates either CRC-16 CCITT or Basic Summation. Unfortunately I can't seem to find a reference for that field as far as what value means what checksum type, but that should be easy enough to figure out by building a test .cyacd file with each checksum type selected and comparing the two.

The Checksum error also seems to be specifically complaining about the checksum of a transmitted row, not necessarily of the entire application (I think it would throw a different error if it was failing a "Verify Application Checksum" command?  But I'm not 100% sure on that).

If you have a logic analyzer/protocol decoder, it may be helpful to snoop your communication lines and see exactly where (on what command or row) in the loading process the error for invalid packet length is being thrown by the loader.  You can then examine the actual packet that triggered the error for anything unexpected.

If you can track down the  original firmware hex file that would be ideal, since you would not even need to worry about bootloading anything.  The hex file would include the original bootloader as well as the application and you could just flash it with PSoC Programmer.

Anyway, that's just some things to maybe look into.  Best of luck on figuring it out!

0 Likes

Thanks @KyTr_1955226 for the (very) fast response. Your insight is very appreciated

Verified the checksum, and is just basic summation.

I guess the other approach is, like you said, to don't modify the .cyacd file and look at the bootloader. I will look with a logic analyzer in the I2C protocol. I found this particular useful code in the bootloader

burner_0-1636755515827.png

burner_1-1636755529982.png

I also found some code that checks the Data Length. 

Do you know how I can modify the (auto)-generated code so that my edits will end up in the bootloader hex? Maybe an override in main() for a define will do the trick because I can see a warning is issued when I do this. But what if I want to edit the bootloader code?

0 Likes
burner
Level 1
Level 1
5 sign-ins First solution authored First reply posted

I found the solution. It was "hidden" in "flash memory layout" diagram from bootloader and booladable

0 Likes

Hello.

Can you enlighten us as to what was "hidden" so that others will know what to look for if this happens to them.

 

0 Likes

Take in consideration the 

.cyacd file format:
    [4-byte SiliconID][1-byte SiliconRev][checksum type]
    The data records have the format:
    [1-byte ArrayID][2-byte RowNumber][2-byte DataLength][N-byte Data][1byte Checksum]
    The Checksum is computed by summing all bytes (excluding the checksum itself) and then taking the 2's complement.

courtesy of https://github.com/gv1/hex2cyacd

If you look at the Byte L and convert these values back into HEX, you will notice this is the difference (between my own bootloadable and the original one) in data row that was preventing me to flash the bootloadable (DataLength).

burner_0-1637167995653.png

 

0 Likes

Good sleuthing on your part to find the issue.

0 Likes