SPI/ITM fixes

[bcantrill]

This work fixes the following:

• Spi.exchange() hangs if RX bytes exceeds TX bytes (Spi.exchange() hangs if RX bytes exceeds TX bytes #341)
• ITM broken on Nucleo H743/H753 boards (ITM broken on Nucleo H743/H753 boards #346)
• SPI overruns are not handled, resulting in infinite loop (STM32H7 SPI overruns are not handled, resulting in infinite loop #349)
• SPI can suffer from overruns due to TX/RX asymmetry (SPI can suffer from overruns due to TX/RX asymmetry #350)

In addition to fixing these bugs, this work removes the Gimlet hostflash
task from the H743/H753 boards -- and replaces it with the venerable ping.

This has been tested on both Nucleo-144 boards (H743 and H753) with
attached SPI flash, as well as Gimlet.

[cbiffle]

So, the SPI parts look reasonable -- what's with the task-ping stuff?

[jeffallen]

This has not solved my problems getting my h753 to do ITM.

First, enabling cannot find the clock scaler:

$ ./target/debug/humility itm -e
humility: attached via OpenOCD
humility: core halted
humility: itm failed: clock couldn't be determined; set clock scaler explicitly

If I give it an archive to look at, then it knows the clock and -e works. Then -a never shows anything, but OpenOCD complains:

Info : DEPRECATED 'tpiu config' command: Using stm32h7x.cpu0.tpiu
Info : DEPRECATED 'tpiu config' command: Running: 'stm32h7x.cpu0.tpiu disable'
Info : DEPRECATED 'tpiu config' command: Using stm32h7x.cpu0.tpiu
Info : DEPRECATED 'tpiu config' command: Running: 'stm32h7x.cpu0.tpiu configure -protocol uart -traceclk 16000000 -output - -formatter on'
Info : DEPRECATED 'tpiu config' command: Running: 'stm32h7x.cpu0.tpiu enable'
Error: SWO pin frequency not set


Info : Target trace output  is enabled

I have used gdb disassemble to confirm that sys_log!() macros are converted into ITM writes.

I would love to help confirm this patch works, but I don't understand how to make ITM work as designed. (I will happily contribute docs for the humility itm command, once I know how it works.)

[bcantrill]

This has not solved my problems getting my h753 to do ITM.

First, enabling cannot find the clock scaler:

$ ./target/debug/humility itm -e
humility: attached via OpenOCD
humility: core halted
humility: itm failed: clock couldn't be determined; set clock scaler explicitly

If I give it an archive to look at, then it knows the clock and -e works. Then -a never shows anything, but OpenOCD complains:

Info : DEPRECATED 'tpiu config' command: Using stm32h7x.cpu0.tpiu
Info : DEPRECATED 'tpiu config' command: Running: 'stm32h7x.cpu0.tpiu disable'
Info : DEPRECATED 'tpiu config' command: Using stm32h7x.cpu0.tpiu
Info : DEPRECATED 'tpiu config' command: Running: 'stm32h7x.cpu0.tpiu configure -protocol uart -traceclk 16000000 -output - -formatter on'
Info : DEPRECATED 'tpiu config' command: Running: 'stm32h7x.cpu0.tpiu enable'
Error: SWO pin frequency not set


Info : Target trace output  is enabled

I have used gdb disassemble to confirm that sys_log!() macros are converted into ITM writes.

I would love to help confirm this patch works, but I don't understand how to make ITM work as designed. (I will happily contribute docs for the humility itm command, once I know how it works.)

For ITM, it can be helpful to get OpenOCD out of the picture entirely (that is, don't run it); Humility will attach directly to the STLink itself and ITM should work. (I would like to not support ITM over OpenOCD at all because it is error prone; I'll file a separate Humility issue on that.)

[jeffallen]

Yes! Taking OpenOCD out of the loop worked, I finally have ITM logs on my h753.

Is it OK if I send a couple of PRs in for docs on "humility itm" and an update to the Hubris README to indicate when OpenOCD is a good choice (for use with gdb?) and when it's not?

[bcantrill]

Yes! Taking OpenOCD out of the loop worked, I finally have ITM logs on my h753.

Is it OK if I send a couple of PRs in for docs on "humility itm" and an update to the Hubris README to indicate when OpenOCD is a good choice (for use with gdb?) and when it's not?

Definitely -- and thank you!