Making firmware hacking easier


#81

I got a new one and it works. my old one but have broken. So … carry on. Confirmed that serial upload works from vagrant without any config (using FTDI chips)


#82

I have an Olimex, but not the adaptors. Unfortunate that I’m in Thailand and ordering from Adafruit will cost me several times the purchase price in shipping! I do have a Discovery board and I’m comfortable using the STLink utility. Does anyone here have experience with this setup, particularly the connection of the Discovery to the MI SWD? Thanks!


#83

Alternatively, can someone give me the pinout for the adaptor for the Olimex? I’m sure I can rig something. Much appreciated.


#84

@Gary:

Yes, I always use openocd / SWD via the 6 pin discovery header.

It’s a bit messy / fiddly without a proper 2x5 1.27 cable and suitable adapter though. Here is a template for a 6 pin SWD < > 2x5 Cortex Debug < > Old school JTAG adapter : https://github.com/PatternAgents/JTAG20M-STLV2F (Someone posted it on Muffwiggler.com)

As there’s only a few (SWD) signals involved, I suppose the alternative would be to just solder some cables onto a 2x5 1.27 socket, directly.


#85

@ubiubu

Many thanks. I’m trying to figure out the 6-pin first, as I haven’t had any luck finding the right socket for the 2x5 locally. (pain in the arse)

There’s only 3 pins connected on the Peaks board, 4 and 5 being RX and TX respectively on Peaks, and TMS and TRST/ on discovery. Do you happen to know if I need to swap these or connect them straight?


#86

That’s USART1 you’re looking at – For JTAG/SWD, you need to use the 2x5 header:

SWDIO (4) < > JTMS (2) and SWDCLK (2) < > JTCK (4) , as well as VDD and GND.


#87

Is openocd support of SWD good? I have a few upcoming boards which are very dense and I’d like to use something lighter than the 2x5 JTAG and all those damn traces.


#88

I’m using SWD with OpenOCD on a newer project. Works like a charm (once you find the right combination of arcane options in the config file). I don’t know about the gain with traces, but the standard-sized 4-pins headers are not that larger than the tiny 8-pins JTAG ones…


#89

It’s faster to put 4 big blobs of solder than 10 small ones - and this frees a few MCU pins. Sometimes it’s just enough to make a project doable with a 48 pin MCU instead of the 64-pin version.


#90

I see (and yes, it’s 10 pins not 8).
Well, what I can say is that all features I used with JTAG on your modules (code upload, memory mangling, break/watchpoints…) still work with SWD with no apparent difference. The updated config files with SWD support are in my stmlib fork on GH.


#91

I had no issues with SWD either, did the 4ms SMR which only had SWD headers and the process was no different on windows/STlink2 other than the different connector


#92

@altitude

Maybe you can help me. I just finished flashing 4ms DLD (I’m the co-designer) using STlink2 with Discovery board. Works simply and flawlessly Then I moved to Peaks and had no luck at all. I could put Peaks into ‘load’ mode but STlink reports ‘No target detected.’ Experimented with connections, settings in STlink etc. But no joy. Do you see anything I might be misunderstanding or neglecting? Thanks.


#93

The SMR has a 4 pin SWD header, that’s P13 (SWDIO) and P14 (SWCLK) (and VDD and GND), as with Peaks (and I presume, the DLD). Except on Peaks, these two signals are available on the 2x5 “Cortex debug” header. It will work the same way, if you use those signals.

As I said above, I strongly suspect you’re looking at the wrong header (which has PA9 (TX) and PA10 (RX) (and no VDD)). It simply happens to be 6 pins.


#94

Yes, the TX/RX pins are for a serial adapter (like those FTDI thingies).

My modules don’t have connectors for SWD - but with the right adapter cable, you can use a SWD programmer.


#95

Okay! I got it.

The DLD uses a 6-pin SWD the first 4 pins of which match the SMR’s connector. I couldn’t tell you why. Dan changed it in a relatively recent turn of the board.


#96

What is the best way to work with this virtual environment and organize changes/branches to my firmware hacking endeavors? As someone who is still learning and making mistakes along the way through trial and error, I am curious how to best approach this without having to make a bunch of back up files whenever I make changes. I know branches with git is very useful for this but I am not sure how to handle this with the virtual box and how to move files back and forth efficiently.


#97

You can use all the git commands you want (for example, the very useful “git stash”) from the VM command line.


#98

Ah okay, that makes sense. Git stash looks very useful, I’ll need to do some more research to get used to the available commands. Thank you, I’m excited to try to wrap my head around what is going on under the hood of my favorite modules. Hopefully I can make something useful enough to share in the future.


#99

Edit: oops, double posted


#100

bonobo: if you’re not already I suggest to get really confortable with Git, it’s an invaluable tool. My whole life basically happens under git control :). The key is to commit really often, and even to split your commits into atomic changes, so that you can go back and analyze your log if things go wrong.
A useful tool for the beginner (that I still use every day) is git gui it allows you to prepare commits by selecting changes line-by-line. “git stash” is indeed irreplaceable too. In many cases, “git bisect” can also help you spot long-standing issues. And don’t underestimate the power of “git diff”!