First I'm using studio 4 with WinAVR-20100110.
And I don't use a bootloader.
Are there a way that winavr (I guess the linker)can calculate CRC of the program, so the AVR at first boot can show ok/error?
2.
If no
Are there a small tool that can do it by adding CRC to the Intel hex file? (and best if it can run from indside the IDE, so I don't forget to run it :) )
If you have WinAVR you have "SRecord". This is actually a set of tools for dealing with Intel Hex and other binary formats. The tool you want is srec_cat. It can easily read .hex file you have built, calculate a CRC over it then embed the result back into a modified .hex file. In fact you would usually have it read the .hex, pad the unused bytes to some boundary with 0xFF (say) then do the CRC and embed it (often at a fixed address).
The AVR code could then implement the same CRC routine within its own code and CRC over the same (fixed/variable) region and finally compare with the CRC embedded in the image at the fixed address.
I wrote a bootloader that does exactly this. See:
https://spaces.atmel.com/gf/proj...
My description there shows a sample srec_cat invocation to do what I just described. If you look at the code itself:
https://spaces.atmel.com/gf/proj...
See line 359 onwards - the two functions there combine to perform the same CRC operation that srec_cat uses to calculate and compare against the CRC that it embedded.
Thanks
You really think the flash is going to be the unreliable part of your project?
If you don't know my whole story, keep your mouth shut.
If you know my whole story, you're an accomplice. Keep your mouth shut. 
It's mostly for updates (by others) in the field.
for updates (by others) in the field.
And I don't use a bootloader.
If the 3rd party were using a bootloader then I could see scenarios with half programmed micros and it's better to have the executive program (bootloader) check the app integrity before launching into it.
But you appear to be talking about ISP (or maybe JTAG). Surely that's a pass/fail with no remedy as there is no executive in the AVR to watch over things and determine whether the app image is intact of not. What use is an app that checks its own integrity. The break in its integrity may be such that the app checking cannot precede.
I would have thought the verification read phase of ISP was a much better indicator of complete/not than the app trying to check itself.
If you do want to follow this path then I would split the AVR code into bootloader and app. That doesn't mean the bootloader has to actually bootload (as in SPM the flash) but it needs to exist as a separate, protected (lockbits) executive to police the rest of the image.
Only thing is ISP tends to be "all or nothing". You cannot (until Xmega) easily say "just this bit" so I guess the ISP session is going to be erasing/replacing all the app and bootloader - in which case maybe it does not make a lot of sense to have it. Which brings me back to where we came in: who watches the watchers?
What use is an app that checks its own integrity. The break in its integrity may be such that the app checking cannot precede.
Flash [pun intended] back to a previous millennium and it was quite common to have microcontrollers checksum/CRC their own memory. What can it hurt? Now, do you put the expected checksum in e.g. EEPROM to address one of your concerns?
Also, there might be rules/standards that require it. Prior "who will watch the watchers" discussions:
https://www.avrfreaks.net/index.p...
https://www.avrfreaks.net/index.p...
It's not that simple, we use keyfob's to update FW, and I don't 100% trust them, and this should remove one possible error.
yes because if the output is OK I can trust it, I don't really care if output is fail or no output. :)
yes because if the output is OK I can trust it, I don't really care if output is fail or no output. :)
Imagine the simplest case where the breq instruction that tests the computed CRC against the stored CRC gets corrupted into a brne instruction. All it would take is for 1 bit to flip:
breq: 1111 00kk kkkk k001 brne: 1111 01kk kkkk k001
This single bit error in the CRC check code, if it were accompanied by any number of errors elsewhere in the code, would result in a 'pass' when in fact the CRC check failed.
I imagine there are a non-negligible number of corruptions which would similarly lead to a false 'passed' conclusion.
How likely is this? It's hard to say. A proper analysis would not be easy, I'd guess. However if you're concerned enough to want a verification, why not do it in a verifiably correct way?
Do the field updates via a bootloader instead of ISP. Use a proven bootloader which does CRC verification of app code on every reset. Burn that bootloader onto the device once - and set the lock bits appropriately - in-house.
Any field updates are then done via the bootloader. Since the bootloader cannot be changed in the field, you can be certain that the pass/fail conclusions it makes about app code are trustworthy.
There are a few circumstances where this may not be true:
1) device/flash failure.
2) hash collision.
3) someone has altered the bootloader
You've said you're not trying to catch 1). You can mitigate 2) with a larger CRC. You cannot control for 3) in any circumstance.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
I hear what you say and disagree.
this is down to statistics what I do will at least catch all simple errors, and I guess make it 10000 times better or so.
I would say that just by having a bootloader in the flash, is a bigger risk, because an erratic error (HW and/or SW) could make a page write, and the program are destroyed !!!
because an erratic error (HW and/or SW) could make a page write, and the program are destroyed !!!
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
I don't have the code sekvens that open for write to flash anywhere, you have it in the bootloader so just one wrong PC value can overwrite a page.
just one wrong PC value can overwrite a page.
If you're saying that 'one wrong PC' during bootload and the bootloader could overwrite itself, then no. You haven't mentioned what device you're using, but if it's one with a BLS, all you need to do is set the boot lock bits correctly to prevent that. The only page SPM instructions permitted will be those to app code space initiated from the BLS.
If you mean that 'one wrong PC' during bootload and the wrong app page gets written... so what? Isn't that exactly the kind of error you're trying to trap for? Bootloader vs. ISP is irrelevant as far that that's concerned.
If you mean that a coding error in the app code could land you in the bootloader and eventually overwrite an app page, again so what? In that case your app code was already broken before you put it on the device!
Burn and verify a bootloader in-house and set the lock bits. Now the bootloader is effectively immutable. This is a requirement if you need to validate app code CRC. If you simply reflash via ISP in the field, you are now relying of field-updated code to validate field-updated code.
I still don't see why any of this is necessary. If the updates are done over ISP can you not simply read back the programmed flash?
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
If you mean that a coding error in the app code could land you in the bootloader and eventually overwrite an app page, again so what? In that case your app code was already broken before you put it on the device!
I still don't see why any of this is necessary. If the updates are done over ISP can you not simply read back the programmed flash?
I must be missing something. Don't these keyfob programmers (I've never used one) do a read back verification phase after programming? As long as it reads back what it thought it should have written then everything is OK isn't it?
Yes there should be a read LED on if verify fail, but again I just want to double check, because we have had some where it didn't work the first time (but the FW showed correct ver. in Display!), but a 2. programming (with same keyfob) solved the problem!
Our problem is that it happend 2000 km from here.
This is the problem, if noise spike etc. give bad behaviour you could end up with a bad program, I can't.
You write the bootloader so that the instructions which implement that timed sequence confirm that the device is in fact in bootload mode and not in app mode.
This can be done with MCUSR:
wdr
ldi r16, 0x03 ; page erase
out SPMCSR, r16
in r16, MCUSR
brne fail ; halt? wdt reset?
spm
A few things are required for this to work. First, no instruction in app code should ever write to SPMCSR. Second, the bootloader must handle all device resets. Third, MCUSR must be cleared by the bootloader, but only right before vectoring to the app, it must remain untouched during bootload.
This sequence should be used everywhere in the booloader where SPM is used to modify flash, i.e. erase or write.
The one remaining caveat is that even if your app code has no instructions that write to SPMCSR, it might be possible for the PC to point to data in flash which decodes into such an instruction, or an indexed write could do the same. Similarly a data word in flash might decode to SPM, but with proper setting of the BLBn lock bits, any such 'rogue' SPM in app flash will be incapable of altering flash.
It is extremely unlikely that a 'rogue' write to SPMCSR would set the correct bits for an erase or write, and then be followed by a jump directly to an SPM in the BLS, all within 4 cycles.
It is not impossible. However the only circumstances which could lead to this are buggy app code in which case you've got bigger fish to fry, or device failure (noise spike) in which case all bets are off anyway. A noise spike or other environmental event which leads to incorrect operation of the PC can also lead to incorrect operation of the rest of the device including the logic that handles SPM lockout via fuse setting.
If your device is not protected from this kind of environment, you need to go back to the drawing board.
So while bootloading vs. ISP opens up an extremely unlikely path by which app flash might self-destruct, that risk is IMO far smaller than the possible scenarios in which it could manifest itself (app bug, device failure). Furthermore, putting self verification in the app code the way you propose can't provide the safeguard you are hoping to add.
we have had some where it didn't work the first time (but the FW showed correct ver. in Display!), but a 2. programming (with same keyfob) solved the problem!
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|