Skip to content

Occasional CRC Mismatch #55

@johnnyman727

Description

@johnnyman727

We have an inconsistent bug where after an update, an error will be thrown declaring a CRC mismatch. If the CRC of the new firmware image is provided with the update, the uploader will request the attiny to calculate the CRC and provide it over SPI for comparison.

To reproduce:

➜  ambient-attx4 git:(master) t2 run debug/update.js
INFO Looking for your Tessel...
INFO Connected to Tessel-02A3BBAD6C82.
INFO Building project.
INFO Writing project to RAM on Tessel-02A3BBAD6C82 (37.888 kB)...
INFO Deployed.
INFO Running debug/update.js...
Uploading new firmware...
Update finished!
/tmp/remote-script/debug/update.js:1
(function (exports, require, module, __filename, __dirname) { var e=require("tessel"),t=require("attiny-common"),o=new t(e.port.A),n={firmwareFile:__dirname+"/../firmware/src/ambient-attx4.hex",firmwareVersion:3,moduleID:8,signature:37383,crc:7861};o.updateFirmware(n,function(e){if(e)throw e;console.log("done updating...")});
                                                                                                                                                                                                                                                                                             ^

Error: CRCs do not match.
    at Error (native)
    at /tmp/remote-script/node_modules/attiny-common/lib/index.js:1:2849
    at null.<anonymous> (/tmp/remote-script/node_modules/attiny-common/lib/index.js:1:3057)
    at null.<anonymous> (/usr/lib/node/tessel-export.js:296:31)
    at emitNone (events.js:67:13)
    at Socket.emit (events.js:166:7)
    at emitReadable_ (_stream_readable.js:411:10)
    at emitReadable (_stream_readable.js:405:7)
    at readableAddChunk (_stream_readable.js:157:11)
    at Socket.Readable.push (_stream_readable.js:110:10)

You may have to run it a couple times before finding the issue.

I captured a logic trace of the output and it seems like it's not an issue with no CRC being provided (which might be the case if the module is mid-reset or the SPI parser is out of sync) but it seems like the image being flash was not written properly. It could be a SPI mode or speed issue:

screen shot 2016-04-15 at 1 41 26 pm

The module should have returned 0x1EB5 but instead returned 0xDF5F.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions