Author Topic: AVR: best practice regarding fuse settings  (Read 21144 times)

0 Members and 1 Guest are viewing this topic.

Offline eneuro

  • Super Contributor
  • ***
  • Posts: 1562
  • Country: 00
Re: AVR: best practice regarding fuse settings
« Reply #25 on: July 18, 2014, 01:22:16 am »
Under which circumstances does it set the fuses on your uC, when they were specified like this?
I didn't looked too much for such things into avrdude documentation so far and to ensure it will behave exactly on my PC Linux based automated programmer the way I want it, I wrote my own factory tools which reads binary AVR file with those additional sections but declared different using attribute section statements in my C source file:
Quote
...
char lfuse_tag[6]  __attribute__((section (".lfuse_tag"))) = "FUSEL:";
uint8_t lfuse  __attribute__((section (".fusel"))) =  LFUSE;
...
and without .fuse section just in the case if avrdude wanted to do something strange during programming  >:D

This eneurotools software simply reads compiled binary AVR file and parses it and outputs to Linux shell  script commands needed to reflash device and program fuses if needed based on its contents and additional passed parameters if needed to calibrate it.
It can take this input binary file as template, substitute defined sections with eg. measured voltages and write changed binary file to reflash device with calibrated data put into these defined sections.
This tool simply loads binary program to memory, scans for tags and when they are found I can change them and write new program without recompilation-just set calibration data for mentioned AVrefs , I2C assigned adress, etc. sections.

If per-chip calibration is needed, I'd be expected to provide a test jig that performed any testing and reprogramming necessary, and would have to pay by the hour for the operator's time.
Thank you for this hint with test jig  ;)
I've included in my MCUs source code section .id which could be PCB serial number identifier for example, so I could have MCUs reflashed with calibrated data linked to PCB, but while they are again back on reel, how PCB assembly factory will know that MCU is for given PCB?

Is it possible to get something like electrical test detail log with PCB serial number if any and voltage measured by PCB manufacturer?
Than based on those automated measurements I could use my software to generate binary program file to reflash MCU for given PCB.

I'm thinking on other option too-operator or software in factory has barcode scanner, scans PCB serial number, puts it into WWW form interface on my WEB page with electrical test result and in real time my tools provide needed binary program code to reflash MCU before final assembly.

This step with external MCU programming and re-real seams to be additional logistics  challenge.
Maybe for specific 8pin MCUs it makes sense to try to make DIY machine with a few optical encoders and OpenCV USB camera app to rewind such reel and reflash those small MCUs and be independent-wait only for electrical tests results, update calibration data and assighn IDs and make final PCB assembly?

Will see, If I had electrical tests logs with PCB serial numbers in text file than, reflashing MCU does not have to take too much time-a few seconds for ATTiny85 reflash even using LPT dapa pararel port  ^-^

« Last Edit: July 18, 2014, 01:29:21 am by eneuro »
12oV4dWZCAia7vXBzQzBF9wAt1U3JWZkpk
“Let the future tell the truth, and evaluate each one according to his work and accomplishments. The present is theirs; the future, for which I have really worked, is mine”  - Nikola Tesla
-||-|-
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf