XTW2 flasher support about stm32-vserprog

[Schuby]

I have the same XTW2 with the GD32F103 and I'm getting the same issues as you. From what I can find online about the GD32F103 I think this might be an issue with libopencm3 rather than vserprog.

On my board, the power LED is connected directly to the ASM1117 and doesn't need any code from the xtw100 to make it work.

I'm not really sure where to begin with debugging this on the GD32 but if anyone has any ideas, I'm happy to flash them to the XTW2 and test.

[neggles]

So the GD32F103 is a bit weird when it comes to clock setup, and neither the stock STM32 clock config nor the GD32F103 one that's present in the code in master actually works properly, as best I can tell. Have to set the clock to 96MHz and do some other weird stuff to make USB work 100% right & get the APB2 clock set to the correct speed.

I've patched that up a bit (based on reading the latest datasheet from here and staring at the example code, plus this helpful blog post and its associated github repo) and you'll find that in my fork over here

I fired up debugging via Cortex Debug and an ST-Link v2 clone adapter, and regardless of whether the legacy code or the DMA code gets used for SPI transfers, sends work fine but receives all hang waiting for the SPI_SR_RXNE bit to clear (or the DMA 'transfer complete' interrupt to fire)

I don't have enough of a clue about how this whole deal works to actually debug it, but if anyone's got ideas i'm all-ears. Apparently the code in the github repo I mentioned above works just fine for doing SPI transmits and receives - even at 54MHz SPI clock 😮 - so it must be something to do with the full-duplex-mode setup, possibly software slave control issues?

[neggles]

I take it back, I do apparently have some clue about how this whole deal works 😝

So the problem is twofold; clock configuration on one end, and the GD32F103 absolutely refusing to work with software slave select, at least with the way this firmware implements it. It throws a CONFERR no matter how I try to tweak things and just refuses to play ball.

If, however, I turn off software slave select, it works just fine, even at (what should be) 48MHz SPI clock.

Benchmark with the old CPU copying routine:

Detecting flash...
Generating test file...
Erasing...
Verifying... PASS
Writing...
Reading...
Comparing...PASS

Flash type: MX25L6406E/MX25L6408E
Flash size: 8192 KiB
SPI speed : 50000000 Hz (requested)
Probe     :   1.00s
Erase     : 170.66s
Write     : 207.30s
Read      :  83.53s

And with DMA enabled:

Detecting flash...
Generating test file...
Erasing...
Verifying... PASS
Writing...
Reading...
Comparing...PASS

Flash type: MX25L6406E/MX25L6408E
Flash size: 8192 KiB
SPI speed : 50000000 Hz (requested)
Probe     :   1.00s
Erase     : 101.66s
Write     :  60.43s
Read      :  10.78s

So that's nice. What's the downside of using hardware NSS control? Seems like it should be fine to me?

Anyway, I've pushed the functional (as far as I can tell) code to my fork over here - clone and make BOARD=xtw2 should do it. Will try to clean the commits up and maybe submit a PR soon :)