# Relate Bin file (read from uC) to map file

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 :)

## 1 Answer

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).

• 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? – user2982010 May 24 '17 at 20:38
• 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. – filo May 24 '17 at 20:40
• 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? – user2982010 May 24 '17 at 21:05
• 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. – filo May 24 '17 at 21:14