GDB hangs with "Ignoring packet error, continuing..."

[japaric]

STR

• Uncomment the first monitor tpiu line in .gdbinit.

 # # send captured ITM to the file itm.fifo
 # # (the microcontroller SWO pin must be connected to the programmer SWO pin)
 # # 8000000 must match the core clock frequency
-# monitor tpiu config internal itm.fifo uart off 8000000
+monitor tpiu config internal itm.fifo uart off 8000000

 # # OR: make the microcontroller SWO pin output compatible with UART (8N1)
 # # 2000000 is the frequency of the SWO pin

• Create a named piped named itm.fifo in the directory where OpenOCD is invoked

$ cd ~/tmp
$ openocd (..)

$ # on another terminal
$ cd ~/tmp
$ mkfifo itm.fifo

• Launch GDB using xargo run

$ xargo run
Reading symbols from target/thumbv7em-none-eabihf/debug/cortex-m-quickstart...done.
cortex_m_rt::reset_handler ()
    at /home/japaric/.cargo/registry/src/github.1485827954.workers.dev-1ecc6299db9ec823/cortex-m-rt-0.3.12/src/lib.rs:330
330     unsafe extern "C" fn reset_handler() -> ! {
semihosting is enabled
Ignoring packet error, continuing...
Ignoring packet error, continuing...

Note that when you reach this point OpenOCD will become unresponsive and you'll have to kill it and start a new OpenOCD process before you can invoke xargo run / start GDB.

Cause

The monitor tpiu config internal itm.fifo uart off 8000000 line hangs because the named pipe is not open (I assume).

Workaround

Open the itm.fifo file before calling xargo run.

$ itmdump -f itm.fifo

$ # on another terminal
$ xargo run

Note that itmdump v0.2.0 sometimes ends when you terminate the GDB session. In that case you'll have to re-run the itmdump command before the next time you call xargo run / start GDB.

The other alternative is used a plain text file instead of a named pipe. This problem only occurs with named pipes. If you use a plain text file you can use itmdump's follow mode (-F) to get a named pipe like behavior.

---

I can't think of a way to avoid this problem or improve the error message from our side so at least I'm documenting the problem here. I'll add it to the troubleshooting guide as well.

[ssendev]

I avoided this problem by using /tmp/itm insteead of itm.fifo as file where /tmp is a tmpfs which means it won't cause wear on my SDD. Potential downside is that it might use up the RAM but even at theoretical max output it would eat less than a GB per hour and it's always possible to just run rm /tmp/itm; cargo run to reduce the problem