STM32 disassembler

[adaniel]

Posted on August 30, 2010 at 15:24

STM32 disassembler

#cortex-disassembler

[picguy2]

Posted on May 17, 2011 at 14:04

You could always ask ST for the source.  The answer may be “no.�?  But I would start there.

Many Cortex-M3 development packages have a built-in disassembler.  At least with IAR’s (the free version at least) you don’t get to disassemble to a file.

While I am here let me ask a question.  Where can I find the information needed to write a Cortex-M3 disassembler?  I have several books and docs from ARM but no binary description of that instruction set.  The information has to exist else on one could write low-level tools like C compilers and assemblers.  Anybody?

[daviddavid92]

Posted on May 17, 2011 at 14:04

The ARM ARM has instruction encodings

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0403c/index.html

Chris.

[adaniel]

Posted on May 17, 2011 at 14:04

1 - The answer was NO

2 - I use the Keil version of RealView which has a disassembler. All what I get is a disassembly of ny own C-files.

3 - The problem is: I have a binary file (or intel HEX file), how do I disassemble it?

Details about what I am trying to do: I wrote a command line program to download frimware through a serial port (RS232). My board has the necessary hardware to

hold the BOOT pins before RESET in order to enter the bootloader. The problem is

that my board has also an ON/OFF button, so that the board is switched OFF

after RESET. In order to download a new firmware I have to hold the ON/OFF

pushbutton depressed. I want to avoid this annoying situation by jumping directly

to an appropriate point into the bootlader, bypassing the ports setup.

Thanks for your answer, anyway.

[domen23]

Posted on May 17, 2011 at 14:04

With gnu toolchain i got this far:

arm-none-eabi-objcopy -I binary -B arm -O elf32-littlearm foo.bin bar.elf

arm-none-eabi-objdump -xD bar.elf --disassembler-options=force-thumb --start-address=0xaddress

It annoys me that it just stops when it gets to something invalid (?).

picguy: armv7 architecture reference manual and possibly also cortex-m3 technical reference manual

[Tesla DeLorean]

Posted on May 17, 2011 at 14:04

Different batches/versions of the STM32 have different boot loaders.

You can always call the boot loader from your own code using the standard entry point (SP/PC @  0x1FFFF000/0x1FFFF004)

The Keil tools are capable of downloading the ROM via JTAG into a HEX file, and certainly capable to debugging/disassembling code directly in the ROM. Just change the PC to point inside the ROM, or jump to the code, while in the debugger.

The instruction set is documented as the ARM THUMB2 ISA, which is a superset of the original THUMB ISA.

[stforum2]

Posted on May 17, 2011 at 14:04

You can use the Crossware simulator to disassemble the bootloader, available from here:

http://www.crossware.com/trialware/21499113stm/index.htm

Image attached.

[Andrew Neil]

Posted on May 17, 2011 at 14:04

''3 - The Keil disassembler doesn't see the bootloader because it is not part of my project.''

I'm sure that's not true!

The Keil disassembler can see any arbitrary memory location!

http://www.keil.com/support/man/docs/uv4/uv4_cm_unassemble.htm

[adaniel]

Posted on May 17, 2011 at 14:04

Codery and Crossware: thanks for your answers, I have downloaded the stuff and I'll inform you of any progress.

Clive1: thanks for your answer, but it is of no use:

 1 - At the standard entry point, the bootloader sets the ports and switches my board OFF.

 2 - I already downloaded the bootloader binary through the bootloader itself and its instruction set.

 3 - The Keil disassembler doesn't see the bootloader because it is not part of my project.

[Tesla DeLorean]

Posted on May 17, 2011 at 14:04

Attached is my rough disassembly and annotation of the boot loader from my STM32.

Personally I think it is small enough that it would be easier just to recode it, or a better one dealing with S-Records, Intel Hex, or X/Y Modem. If you start jumping into specific ROM addresses you need to be concerned about chip/stepping issues with assorted versions of the loader.

>>As a side point - where does the bootloader read the Boot0 pin?, and can we read it in our code?

Hard to say, mostly done in hardware initialization in order to pick the appropriate boot vector address, and memory mapping. The primary boot loader code does not read the pin, but does look at the ROP state and disables certain functions. Want to see how it booted? check the memory which is mapped/shadowed at zero. In the ROP state code running in FLASH/ROM can read data in FLASH/RAM/ROM. Code running in FLASH/ROM can copy and execute code in RAM which can also access all the memory. Code booted from RAM in the ROP state cannot however touch or execute code in FLASH/ROM. Technically, I think it can execute, but it can't read values from the PC relative literal pool so you are basically SOL.

There is some conjecture that the STM32 might execute some hidden code, or copy something to RAM or other shadowed memory at zero during initial startup. Weird things happen with a RAM boot, don't assume it reads the boot vector. Different STM32 variants start execution of user code at 0x140 and 0x1E0 when you boot into RAM.

[daviddavid92]

Posted on May 17, 2011 at 14:04

Interesting stuff!!

As a side point - where does the bootloader read the Boot0 pin?, and can we read it in our code?

Chris.