1
\$\begingroup\$

We have a AT32UC3C1512 presenting a Failure, part of the analysis that is normally performed to isolate the failure is to perform ABA swap of components, we have performed the swap in several components in the board and the failure follows the microcontroller.

The next step is to perform a verification of the firmware in the uC, we have a "master" bin file that is programmed via avr-gcc (in the production floor) and we use that to perform a verification, the verification was failed by the microcontroller, so we extracted the faulty microcontroller flash memory file and perform a comparation using HxD, there are 2 sections that have corrupted data.

I have the .map file of the compiled project. I was wondering if there is a way to obtain the address of the corrupted data from the BIN file to compare against the map file to see in which function or what variables/sections are being the ones throwing the error.

Any ideas? Thank you :)

\$\endgroup\$

1 Answer 1

Reset to default
0
\$\begingroup\$

Read back the image from failed MCU (read couple of times if you are not sure if the chip is okay). Then convert the .bin files to Intel Hex (for example: srec_cat input.bin -Binary -Output output.hex -Intel --line_length=44) and use any text diff tool to spot the differences. Addresses are obviously visible in Intel Hex files. Then you can just search the map file for a particular address.

I would dump the flash from suspected boards before doing any other analysis (flash protection can be a problem - if you use it, some MCUs have a backdoor function to facilitate that eg. NXP Kinetis).

If you are experiencing flash corruption in the field I would suspect the firmware in the first place (especially if you store some settings in MCU flash).

\$\endgroup\$
4
  • \$\begingroup\$ Hello thank you for your help i will try that, but can i ask you why is the line_length=44? it has to do with the 32bits of the MCU? \$\endgroup\$
    – user2982010
    May 24, 2017 at 20:38
  • \$\begingroup\$ Try it, change to a different value and have a look. Intel Hex can have different row lengths, I've found that 44 is the same amount that objcopy delivers, so when I convert back from bin I can directly compare it with the file my toolchain generates. \$\endgroup\$
    – filo
    May 24, 2017 at 20:40
  • \$\begingroup\$ I used your method, the corrupted block is from 0xFEF0 to 0xFFDF, should i divide the address by 4, because 4 bytes are 32 bits?, also, the program in the MCU starts at 0x80000000 should i add the address? \$\endgroup\$
    – user2982010
    May 24, 2017 at 21:05
  • \$\begingroup\$ Addresses in map files (GCC) are in bytes, it does not matter if the target is 8-bit or 32-bit. I doubt that the entry point would be at 0x80000000. I don't know AVR32, but on AVR and ARM and flash starts at address zero. I would just look for something between 0xFEF0 and 0xFFDF in the map file. \$\endgroup\$
    – filo
    May 24, 2017 at 21:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.