ARM Cortex M3 firmware

Question

First some background information.

There is one product (a sensor) bought from a far eastern manufacturer, bless their white cotton socks, that uses the STM32F103V microcontroller. The firmware that was originally supplied, along with any updates has some nasty bugs that turn the product into a brick at random intervals (and the product is expected to work without any downtime for months).

At the beginning they were responsive and eager to provide support; after the purchase they are not providing any reply to any of the e-mails sent.

So the solution is to rewrite the firmware by myself.

On to the problem now.

The microcontroller already has a bootloader and there is no JTAG port available on the boards. Is there any way to find - from the bin files I have - what is the start address of the firmware? Due to the bootloader, it is not 0x00000000. Also, is there any other thing I should be aware of when writing the firmware (ie: certain settings for registers, aso)?

Answer 1

I recommend you get an equivalent part and a breakout board. you should only need power and ground and vdda. get the smaller package if you prefer (cheaper breakout). another option is a nucleo board, and you may want the debug end of that anyway, will want to disconnect the swd/debugger so you can get at what I am after...

the parts come pre-programmed from ST with a bootloader in them. you strap boot0 the right way and then you can program via uart. at any time you should be able to use the swd interface (jtag-ish). I use the top end of these boards to program other chips, they want to use the mbed thing though and mount like a thumb drive and you drag and drop the file. not the experience you are after you want to in a controlled environment experience using openocd or something like that over swd to deal with one of these parts. thus the idea of getting a discovery board, or a breakout or other. shouldnt cost you more than $20 all told, maybe $10 depending on what path you take.

once you experience it with a board that has nothing else going on then you can adapt that knowledge to your board in circuit. the uart pins may be repurposed for example, so you might not be able to get at the st bootloader. I cant imagine the swd pins are repurposed, they would want to have a way to do a firmware upgrade in circuit. it is possible they pre-programmed the parts for production, but also possible they programmed them in circuit. also may be possible they are one time programmables, but didnt look that closely into your part number.

As Chris Stratton mentioned the vector table is going to be a list of addresses, start with some 0x2000x000 type number then odd numbers, anywhere from a handful to dozens, possibly a lot of them pointing at the same handler. 0x00000051 0x00000071, 0x00000103, etc. not necessarily increasing in value. the vector table, etc are all in the st and arm documents as to what they do.

I think the user flash is 0x08000000 based, so sprinkled in the code there may be addresses based on that. actually the vector table may/should contain vectors in that space

08000000 <_start>:
 8000000:   20001000    andcs   r1, r0, r0
 8000004:   08000041    stmdaeq r0, {r0, r6}
 8000008:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 800000c:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 8000010:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 8000014:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 8000018:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 800001c:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 8000020:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 8000024:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 8000028:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 800002c:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 8000030:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 8000034:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 8000038:   08000047    stmdaeq r0, {r0, r1, r2, r6}
 800003c:   08000047    stmdaeq r0, {r0, r1, r2, r6}

unless they have taken over the built in bootloader (if possible).

look at the package pinout and figure out where the swd pins are, and ring those out on the board, I wouldnt be surprised if there are some pads. going with a $10 nucleo board is cheaper than a $15 stlink both are cheap relatively though, I prefer the nucleo path or a discovery board and use the front end to program parts in circuit. pretty easy to connect with openocd.

Answer 2

Are you certain you can't access the SWD pins on the device? It seems unlikely that the manufacturer would have a part that they are unable to debug themselves. Its not like they have shown any concern about protecting ttheir IP to date. Check that the ST bootloader doesn't respond too. Maybe the manufactturer wrote custom tools to interface to this bootloader.

You have disassembled the bin file, I assume. Did you spot anything that looks like a vector table? Unlike the A-class cores which have a block of LDR PC,[PC#0x20] repeated (or something similar) - followed by a string of addresses, in M-class, the vector table is always a list of addresses with bit 0 set (same as for any branch to Thumb). Before the vector addresses is the initial stack pointer value. Actually any PC relative load-pc ought to give you some clues, again these will reference an odd-number value.