Strange opcodes disassembling .hex (AVR8)

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been toying with writing a custom simulator. Barring all comments regarding the number of simulators currently available, I've run into an issue I could use some assistance with.

AVR Simulator seems to disassemble instructions I am not familiar with (i.e. aren't in the AVR opcode/instruction 'bible').

Case in point:

+0000004F: E9EE LDI R30,0x9E Load immediate
+00000050: FBFC CPC.L R28,R24 32-bit Compare with Carry
+00000051: F5F2 BRPL PC+0x3F Branch if plus

What is CPC.L (32-bit compare with carry)? I was not aware AVRs had any 32 bit compatible instructions. Is the simulator flagging non-existent opcodes from AVR32? I selected Atmega644P as the device in question, FYI.

-Hope someone can help
-Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The other day it was found to be disassembling LAT, LAS, and LAC opcode for a mega168, clearly it is FUBAR!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Doing some more digging (I made an opcode table in Excel!). This is what I *think* is going on.

The instruction FBFC is actually 'BST'. Here's its opcode.

1111 101d dddd 0bb

So FBFC corresponds to BST r31,4

If I'm correct, I guess that means I've ran into a bug in the disassembler of AVR Studio 4. I haven't tested AVR Studio 5, because attempting to open .hex files in Studio5 opens them as a plaintext file.

So, as a further question, anyway to disassemble prebuilt .hex in Studio5?

-Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI the cpc.l is a valid instruction for a 8-bit AVR core with MEXT opcode extension (ATMega64HVE). Although nobody have seen this chip, this extension has been implemented - see this post.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good to know, is there some reference that lists the different core architectures and the chips that fall under them?

In writing a disassembler, a convenient location to reference chip core revision etc. would be ideal.

-Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Indirectly the AVR-LibC manual has such a list though I'm not sure it actually mentions the esoteric part my learned colleague refers to. Similarly see avr-gcc --target-help

BTW, I too have a simulator in me and previously drew up an analysed list of AVR opcode. I think I have posted that here before now under my normal ID "clawson " but I'll repost it when I am back in the UK tomorrow.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It wasn't BST after all. I needed to take a quicker look. I went and located the original project for this .hex file and these unknown opcodes are coming from sections I don't have the source for (GCC stuff, project was built with an older version).

So the unknown stuff must be data that doesn't align with any valid opcode, probably juxtaposed against data that appears to be an opcode but isn't.

Still, I'm of the opinion ATMEL should fix the problem where non-existent instructions can be disassembled (for a particular chip).

-Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

WrightFlyer, I don't believe the studio disassembler is doing anything incorrectly. It is just blindly reading the raw machine code and attempting to translate each word pair or 32 bit pairs into instructions. What happened to you LAT, LAS, whatever is the same thing I believe happened to me.

Data being interpreted as code. I believe if you traced the execution paths of your code these rogue instructions would never execute.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The LAT thing wasn't me but someone who posted here. In that case it was definitely a mis-decode of .cseg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW here's the opcodes.txt I have been using...

The last figure is the number of words - as you can see there are very few 2 word opcodes,

Attachment(s):