# ARM Cortex M3 firmware

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

• Can you provide information regarding the bootloader ? You are talking about a custom one, not the one from STMicro already in ROM of the MCU, right ? Who developed it ? This same company ? – dim May 31 '16 at 10:40
• I have no information about the bootloader and the devices were supplied with a Windows application that handles firmware upload. No reference to the developer of the firmware upload application (has some chinese characters, though) and is delivered with one DLL that may come from ST (STUARTBLLIB.dll). – Iulian May 31 '16 at 11:00
• @Iulian - "nasty bugs that turn the product into a brick at random intervals [...] the solution is to rewrite the firmware by myself". I recommend keeping an open mind about the possible cause & solution. Assuming the hangs occur on multiple devices then, in addition to firmware, the hangs could also be caused by (a) hardware design bugs in the device and/or (b) something specific to your usage of the devices including, but not limited to, power supply-related issues. It would be a shame if you rewrite the firmware and still have the same problem! Can you share a web link for the device? – SamGibson May 31 '16 at 12:51
• @SamGibson: Thanks for the hint. I arrived to this conclusion by trying out the product also on a filtered power supply, on the bench and having as result different bricks, depending on the firmware version (one of them will complain about the heap, while other will say nothing). Still, I am not ruling out the hardware completely, as I am also adding some extra wires to do some more checks. Will look for the product online and provide a link. – Iulian May 31 '16 at 13:25
• How is the board connected to the PC for upload? The factory bootloader on the STM32F103 supports a UART connection, but not a USB connection. The DLL you mention suggests the UART bootloader may be in use, but if you connect via USB the bootloader would instead be something custom. You should also be able to tell by determining the strapping of the boot mode pins. To do development, you will want a board where you pick up the two SWD pins, unless they used the BGA version that should be possible with care and magnification. – Chris Stratton May 31 '16 at 13:30

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.

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.

• Yes, the MCU has only TCK and TDI available as test points and there is no other connector on the PCB. Thank you for the idea to check with the ST bootloader, will try that too. Yes, I disassembled the bin file and there is nothing that looks like a vector table, as you mentioned. – Iulian May 31 '16 at 13:18
• SWD uses tck and tdi only, doesn't it? If you don't have a SWD probe, get a £10 Dev board that has one on board. – Sean Houlihane May 31 '16 at 13:22
• The reason you didn't see a vector table is because this post incorrectly describes one. It does not consist of branch instructions, it consists of raw absolute addresses. Look for a 16-bit little endian value of 0x0800 (ie 0x00 0x08) which will interleave with offsets of the firmware within the flash region. – Chris Stratton May 31 '16 at 13:48
• All the instruction addresses in the vector table have the LSB set (this is the T bit for the handler) - sorry for the mistake, will fix it later. – Sean Houlihane May 31 '16 at 13:55
• Actually SWD uses TCK as its clock but TMS rather than TDI for bidirectional data. Of course it is possible the poster is mixing up what is actually broken out. – Chris Stratton Jul 30 '16 at 4:54