I just recovered my M3 boards :)

Well, with one board I had to rename the serial name from HiKoB FITECO M3 to IoT-LAB M3but once done, this PR worked as a charm.

@cladmi can you maybe add a link to the info for the change @rfuentess just did?

There should be no need to rename the FTDI description as we do not force to have the device_desc to M3.

If someone needs to rename the ftdi description it can be done with https://github.com/iot-lab/iot-lab-ftdi-utils

./ftdi-eeprom-config M3

@cladmi can you verify if there's nothing referencing M3 in the openocd configurations files? I have a gut feeling it should be something inside, since FTDI drivers can be quite generic, they should have a way to "accept" only some, and thus identify them somehow.

There is a link to the file in the openocd mirror in the PR description, you can see the content and check that it never changed during its history.

The selection is done on identifiers that cannot be changed ftdi_vid_pid 0x0403 0x6010

There is a link to the file in the openocd mirror in the PR description, you can see the content and check that it never changed during its history.

I don't think the verification of the FTDI device is there. Indeed, the VID and PID are there, but that's always the same since it's the FTDI chip which provide them. However, there might be a verification somewhere which checks for this "M3" on the device.

Yes it was done in the IoT-LAB file https://github.com/iot-lab/iot-lab-gateway/blob/2.4.1/gateway_code/static/iot-lab-m3.cfg#L6 But not here.

AFAIK, that's not the only place where you can declare those requirements. But still, the problem is that nodes flashed as "HiKOB" still don't work with this PR.

AFAIK, that's not the only place where you can declare those requirements. But still, the problem is that nodes flashed as "HiKOB" still don't work with this PR.

I just played with my M3 board

• Using ./ftdi-eeprom-config Nope
  throw the following error on all my attempts (more than 10):

### Flashing Target ###
Open On-Chip Debugger 0.10.0+dev-00403-g3737dd6 (2018-04-19-13:50)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_nogate trst_push_pull srst_open_drain connect_deassert_srst
cortex_m reset_config sysresetreq
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020 (STMicroelectronics), part: 0x6414, ver: 0x0)
Info : DAP transaction stalled (WAIT) - slowing down
Error: Debug regions are unpowered, an unexpected reset might have happened
Error: JTAG-DP STICKY ERROR
Info : DAP transaction stalled (WAIT) - slowing down
Error: Failed to write memory at 0xe000ee00
Info : DAP transaction stalled (WAIT) - slowing down
Info : DAP transaction stalled (WAIT) - slowing down
Info : DAP transaction stalled (WAIT) - slowing down
Info : DAP transaction stalled (WAIT) - slowing down
Error: Failed to enable the FPB
Polling target stm32f1x.cpu failed, trying to reexamine
Error: Could not find MEM-AP to control the core
Examination failed, GDB will be halted. Polling again in 100ms
Polling target stm32f1x.cpu failed, trying to reexamine
Error: Could not find MEM-AP to control the core
Examination failed, GDB will be halted. Polling again in 100ms
Info : Listening on port 45429 for gdb connections
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* stm32f1x.cpu       cortex_m   little stm32f1x.cpu       running
Polling target stm32f1x.cpu failed, trying to reexamine
Error: Could not find MEM-AP to control the core
Examination failed, GDB will be halted. Polling again in 100ms
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020 (STMicroelectronics), part: 0x6414, ver: 0x0)
Error: Could not find MEM-AP to control the core
Error: Failed to enable the FPB
TARGET: stm32f1x.cpu - Not halted
in procedure 'reset' 
in procedure 'ocd_bouncer'

• Using ./ftdi-eeprom-config "Nope M3"
  I got the same issue

• Using ./ftdi-eeprom-config M3
  Erh, I'm also unable to flash the board (more than 20 attempts). However, with the current master eventually I'm able to flash it. After this, I can use your PR for flashing.

• Modifying ftdi-eeprom-config for using "HiKoB FITECO" for eeprom.manufacturer and then ./ftdi-eeprom-config M3 (I'm assuming this was the original state of my M3 board) is the same behavior (unable to flash with this PR).

Maybe there is another issue not addressed by this PR?

Relevant info:

Ubuntu 16.04.4 LTS 64-bit
Openocd version 0.10.0+dev-00403-g3737dd6.
After each use of ftdi-eeprom-config the board was turn off for some seconds.

The following remain static on the boards:

  idVendor           0x0403 Future Technology Devices International, Ltd
  idProduct          0x6010 FT2232C Dual USB-UART/FIFO IC

ping @PeterKietzmann we should try to recover our m3 nodes with this PR tomorrow

For the ftdi-eeprom-config, I do not have the same problem as you have.
After re-programming the eeprom, it is a good idea to unplug and replug the device.

What I get however, is on the first flash after plugging the board, I have error messages like:

Polling target stm32f1x.cpu failed, trying to reexamine
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x230000e2, MEM_AP_TAR 0xe000ed04
Error: Failed to read memory at 0xe000ed04
Examination failed, GDB will be halted. Polling again in 300ms

and

Info : JTAG tap: stm32f1x.bs tap/device found: 0x06414041 (mfg: 0x020, part: 0x6414, ver: 0x0)
Warn : Timeout (1000ms) waiting for ACK=OK/FAULT in JTAG-DP transaction - aborting
Error: JTAG-DP OVERRUN - check clock, memaccess, or reduce jtag speed
Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x230000e2, MEM_AP_TAR 0xe0042008
Error: Failed to read memory and, additionally, failed to find out where
Error: mem2array: Read @ 0xe0042004, w=4, cnt=1, failed

but it still flashes at the end.

On the second run I do not get any error messages.

There could be missing some initial configuration somewhere.

For me it works whatever the name I put in ftdi-eeprom-config NAME. I only test after reconnecting the board or force reading with ftdi-devices-list -r.

I re-organized the configuration to be done AFTER including stm32f1x.cfg.

Adding connect_assert_srst removes the errors on first flash after connecting the board.

http://openocd.org/doc/html/Reset-Configuration.html

If I remove trst_and_srst it cannot flash:

none separate
cortex_m reset_config sysresetreq
none separate
Info : clock speed 1000 kHz
Error: BUG: can't assert SRST
in procedure 'init' 
in procedure 'ocd_bouncer'

I updated according to @aabadie feedback and now it looks more robust on my side.
Can you retry ?

As it is now using connect_assert_srst, and if I understand it correctly, it might even be possible to fix boards with broken code: http://openocd.org/doc/html/Reset-Configuration.html (see connect_assert_srst description).

it might even be possible to fix boards with broken code

This is the purpose of #8976 but for boards using stlink. This is the same problem there.

Otherwise, the changes there are valid to me. I need to retest though or maybe @cgundogan can give try ?

I do not really understand my changes and why they fix things, so sure, please re-test on you boards before ACKing.
I am currently only testing with the only node I have with me, I might be able to test more in Grenoble.

@miri64 and @bergzand it would be cool if you could try on some of your broken boards that I could not flash with the old iotlab configuration.

I tried just now with my broken boards and now they can be flashed without problems.

So I'd validate this PR as a fix and merge it asap.

Please squash.

I squashed the 3 commits and try to explain the last changes, please check the commit message if you find it clear enough.

the old 'ftdi2232' driver and not 'RIOT'

Actually the driver used in RIOT is the ftdi.

* Kee the 'configure -rtos' auto

s/kee/keep

I reworded the commit

the old 'ftdi2232' driver and not 'RIOT'

Actually the driver used in RIOT is the ftdi.

I reformulated to explain it was working with the ft2232 (fixed the name) and not the ftdi driver in riot.

• Kee the 'configure -rtos' auto

Fixed

Great! Let's go then.