- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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
Solved! Go to Solution.
- Labels:
-
PSoC3 MCU
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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:
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I found the solution. It was "hidden" in "flash memory layout" diagram from bootloader and booladable
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello.
Can you enlighten us as to what was "hidden" so that others will know what to look for if this happens to them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good sleuthing on your part to find the issue.