Add support for stm32f072cb as new HIC

[shiva-pandit]

Here is an attempt to add support for stm32f072cb as new HIC. Please review and let me know if I missed anything.

Tested all basic HIC operations on our custom board. Binaries were built using gcc toolchain - gnu-arm-embedded/gcc-arm-none-eabi-9-2020-q2-update. Have not tested any other toolchain.

• STM32F072CB comes up in DFU mode by default. I was able to flash the daplink_if firmware using the dfu-util.
• Using STM32L452 as the target processor, was able to flash and debug an application on target mcu using openocd/gdb combo.
• Verified the serial output from the target mcu on ACM interface of the HIC.

Some of this work is based off of this old PR: #674

[mbrossard]

Excellent. I was able to compile this on gcc, armclang and armcc.

I was looking at #674 from @dotnfc and I noticed your version has a different IO configuration. Are you using standard board (like NUCLEO-F072RB, 32F072BDISCOVERY) or your own design?

[shiva-pandit]

Excellent. I was able to compile this on gcc, armclang and armcc.

I was looking at #674 from @dotnfc and I noticed your version has a different IO configuration. Are you using standard board (like NUCLEO-F072RB, 32F072BDISCOVERY) or your own design?

This is our own design. Unfortunately, I don't have access to any other F072 based boards...

I can share the relevant schematic page, if it makes sense.

[tarokajya]

@mbrossard :It seems that IO configuration #674 from @dotnfc is based on JLINK OB stm32f072.

[dotnfc]

Yes, sure. the IO configuration from #674 is based on the JLINK-OB F072.

[symovs]

hi @shiva-pandit, we (@BibyThm, @Ashleyvk and me) were trying to add a new HIC which uses STM32F373CC. While we had followed mostly the #257 for our work we have not been able to connect the HIC PCB we have to our WIN 10 PC and get it enumerated yet as we noted here - #768. After trying out few things which are listed below

1. We are testing on DAPLINK customized for STM32F373CC based HIC.  The STM32F373CC has external pull up resistor to 3.3V and the device is bus-powered. We have tested the hardware with a libusb based CDC device firmware generated from STM32 Cube IDE. So hardware seems alright.
2. We are testing on Windows 10 and so DAPLINK should work with native windows inbox USB drivers. So doesn't seem to be a driver issue.
3. We have compiled our code using KEIL and GCC and seeing the same issue with both. So definitely not a compiler issue.
4. As some boards were using custom bootloader firmware to load DAPLINK we checked whether loading with STCubeprogrammer over ST DFU will cause an issue. After some thought, we think we are doing this right by programming the device starting from the address 0x0800000 in the STM32CubeProgrammer
5. Out of the four output files produced by the KEIL compiler - *_if.bin, *_if_crc.bin, *_if_crc_legacy_0x5000.bin, *_if_crc_legacy_0x8000.bin verified that we think we are using the correct file for programming which is the  - *_if.bin / 

Now we are thinking we may have got it wrong with the usbd_STM32F373.c we created. It would be very helpful if you can let us know how the file is generated like in your case this one - source/hic_hal/stm32/stm32f072cb/usbd_STM32F072.c. We are not able to see such a file name in our STM32Cube IDE or MX generated files. We merely copied over the https://github.com/ARMmbed/DAPLink/blob/master/source/hic_hal/stm32/stm32f103xb/usbd_STM32F103.c to our new stm32f373xc folder and renamed the file to usbd_STM32F373.c

@brianesquilona @flit @mbrossard @dotnfc your inputs if any would also be greatly appreciated.

[mathias-arm]

@shiva-pandit: it seems the I/O configuration suggested by @dotnfc is popular so I think it would be better to have it as the default. Could you update IO_Config.h to match that configuration (see #674 and the document linked above). You should be able to easily use the IO_CONFIG_OVERRIDE mechanism for your board.

I am getting a 32F072BDISCOVERY to test this.

[mathias-arm]

I looked at the different pinouts and the situation is a little bit more complicated because this version uses two pins for SWDIO. If you are still interested in this work, I can work with you (in mbrossard/DAPLink:feature/stm32f072cb_hic) on modifying IO_Config.h and DAP_config.h so both setups can be supported, otherwise we can simply close this PR.

[shiva-pandit]

@mathias-arm we can close this PR. support for discovery board should be good enough. thanks.

[mathias-arm]

Thank you.