…correctly and the pins are driven suitably hard

…ead machinary

…the on-board Flash

…e for SWD in

…ng the dual target serial interfaces up to the second host serial interface

…oesn't get upset by them

…fer and more reasonable

…n steering macros weren't available when they should be

… mechanism using the EXTI

…le UART mechanism using the EXTI

… second UART

… the UART needs to be switched by toggling the direction signal on the level translation once every 10ms

…RT appropriately based on state changes

…signed values

…he DfuSe interface strings

…32U5 as the old method was making erase fail to execute correctly on these devices

… noticable ill effects

This needs properly documenting and that documentation must be written before this is PR'd. The flag does not cause data corruption and appears to work the correct way, however it's unknown if it's acting like DMA or micro-halting the core. We suspect the latter.

…ut string with its value from getting compiled out when assertions are off

…ut string with its value from getting compiled out when assertions are off

…Mv8-M fault handling in cortexm_halt_poll()

…unks

…ion so we avoid map truncation problems and buffer overflows for particularly large maps

…lock_flash_erase`

…ommand

This was found by looking at the JTAG traffic the lattice diamond programmer generated when programming the ispCLOCK device, and the name was extracted from a JED for the ispCLOCK being converted to an svf file, as the name for this command was included in a comment in the resulting file.

…_done`

These now properly handle the setup and exit for programming ispCLOCK devices

…e attached ispCLOCK device.

After much mucking about and trying to figure out what the lattice programmer was doing and how much of it is required, the method for properly programming the ispCLOCK devices was figured out, which does include wiggling TCK, for some reason....

This is used so we can verify the contents of the the ispCLOCK device and ensure that the correct configuration for it was written

* Extract the memory write into a dedicated helper function
* Wrap it into TRY-CATCH macros
* Drop the extraneous 10ms delay introduced back in PR2072

…sfers

if we use the stock bootloader, we need to PULL PA12 to GND

The main idea is that if we disable the NXP, RP, EFM and/or NRF
support, there is no need to do a DP rescue and probe for these targets