OpenOCD with multiple stm32's

[Harvs]

I'm working on a project where I'm building an instrument that I want to access via TCP/IP.  I'm using two STM F4DISO boards to implement control algorithms and a RPi to do all the network comms and datalogging.  Ideally I'd like to be able to update the firmware in the DISCO boards remotely as well so I can work on new control schemes remotely.

I could have written a bootloader, but I thought the stlink interface would be an easier (more robust?) option.

After a bit of pain (I'm not a linux guru by any means) I've got OpenOCD compiled on the RPi and surprisingly it works well.  I can happily fire it up through SSH and connect GDB within Eclipse.  So if I was using a single board I'd be completely set and happy.

Now, I can open a telnet session into OpenOCD and issue the targets commands, and I only see a single board.

Code: [Select]

Open On-Chip Debugger
> targets
    TargetName         Type       Endian TapName            State
--  ------------------ ---------- ------ ------------------ ------------
 0* stm32f4x.cpu       hla_target little stm32f4x.cpu       unknown

If I unplug that board and restart OpenOCD I can now see the other board, so both boards are functionally fine, but I can't work out how to see them both (and hence be able to switch openocd between them.)

running lsusb returns

Code: [Select]

Bus 001 Device 005: ID 0483:3748 SGS Thomson Microelectronics ST-LINK/V2
Bus 001 Device 006: ID 0483:3748 SGS Thomson Microelectronics ST-LINK/V2

So they're both recognised by the system.

From what I can gather from the manual, it should work.

Any ideas?

[Harvs]

Well to answer my own question, I believe it's pretty much not possible how I was trying to do it.  OpenOCD looks for a device using LibUSB with a specific VID and PID. Obviously both boards will have the same VID and PID, so it has no method of finding the second one.  Infact when you put a second interface with the same VID and PID in the config files it throws errors that the device is already connected.

Second thing I tried was to unbind one of the interfaces so you could connect to them in turn.  That didn't work either, since LibUSB operates at a lower level (I'm assuming) that the linux USB drivers.

So end solution is to include power switching to each of the boards controlled via the RPi GPIO, allowing the RPi to take offline each of the M4 boards before opening OpenOCD.

[nctnico]

You can try and run multiple OpenOCD instances. A couple of years ago I made a gang programmer to program up to 8 boards simultaneously. I ran 8 OpenOCD instances (each with a different port to connect to) on an embedded Linux platform. Perhaps this works on your system as well. Maybe Linusb sees that one interface is already taken so it will use the other.

[Harvs]

You can try and run multiple OpenOCD instances. A couple of years ago I made a gang programmer to program up to 8 boards simultaneously. I ran 8 OpenOCD instances (each with a different port to connect to) on an embedded Linux platform. Perhaps this works on your system as well. Maybe Linusb sees that one interface is already taken so it will use the other.

What did you need to change to get that running?  I'm assuming you had to have multiple sets of config files with different ports for the daemon?

[nctnico]

I just had 8 different config file. You can specify the configuration file as a command line parameter.

[Harvs]

I just had 8 different config file. You can specify the configuration file as a command line parameter.

I tried it out but still no go, I just made separate config files with different ports specified for each of the tcp/ip ports.

With one instance running, opening the second just results in "Error: open failed".  Whilst not a particularly clear error, it is a different error than you get when it can't open a TCP/IP port.  So I'm pretty sure it's trying to open the same USB port as the other instance is running.

However, it's no big deal.  I'll just add two relays (or the solid state equivalent) to the power supply board and be done with it.

[alm]

Why not chain multiple targets together and connect them to the same interface? That's what JTAG was designed for.

[nctnico]

Another OpenOCD issues popped into my mind. For every JTAG action OpenOCD assembled a new bitstream. On a slow platform this may take a considerable amount of time. The gang programmer I mentioned earlier was driven by a 300MHz MIPS processor; it took the processor so much time to assemble the bit streams that it didn't matter whether I was using the FPGA JTAG accellerator or bit-banging. It took me quite a bit of hacking to get OpenOCD to use readily made bitstreams for the most common actions so programming went from 5 minutes to about 30 seconds. But then again the MIPS processor to be programmed required to load individual instructions and single-step through them which was painfully slow anyway.

[Harvs]

Why not chain multiple targets together and connect them to the same interface? That's what JTAG was designed for.

If it was JTAG, that's what I would have done.  But as far as I can tell, you can't do that with SWD, which is what's implemented on the disco boards.

Sure I could get a JTAG programmer and stuff in there as well, but that's no easier than switching power off to them individually for update.

[mrflibble]

I just had 8 different config file. You can specify the configuration file as a command line parameter.

I tried it out but still no go, I just made separate config files with different ports specified for each of the tcp/ip ports.

With one instance running, opening the second just results in "Error: open failed".  Whilst not a particularly clear error, it is a different error than you get when it can't open a TCP/IP port.  So I'm pretty sure it's trying to open the same USB port as the other instance is running.

Curious. I recall doing the same thing (with just 2 boards, not 8 ) and having no problems. Was this under linux or windows? Guess I'll have to re-run it just to be sure I am not mis-remembering things. That was during a period of too much mucking about with openocd so not 100% sure, but reasonably sure...

[ntfreak]

In theory it is possible however the current OpenOCD stlink driver lacks support.

The usual way to detect multiple devices is to use the serial (if supported) or usb bus address.
I guess this does not help with your current quest, but feel free to add support to OpenOCD 

Not tested but i do believe texane/stlink supports this.

Cheers
Spen