XTW2 flasher support

[romanstingler]

I ghink the issue is that different chips are used xtw100 has stm32f103 xtw2 has gd32f103 chip.

I have a XTW100 and one XTW2. Unlocked both via SWD and flashed the XTW100 board code.

The XTW100 works perfect but the XTW2 doesn't. one difference is xtw100 has stm32f103 xtw2 has gd32f103 chip.

As far as I can tell the PA2 and PA3 are still the same for WP / HOLD. VCC is connected to the AMS1117. Ground is much better and connected to the board ground. CS -> PA4 DO -> PA6 GND -> VSS DI -> PA7 / PB0 CLK -> PA5

I have removed the lines

  gpio_set_mode(GPIOB, GPIO_MODE_OUTPUT_50_MHZ, GPIO_CNF_OUTPUT_PUSHPULL, GPIO1|GPIO2);
  gpio_clear(GPIOB, GPIO1|GPIO2);

but this doesn't work either.

I can build it, flash it. But in flashrom I only get to the point where it probes for the first chip and than it just hangs.

blackout@Workstation ~ % sudo flashrom -p serprog:dev=/dev/ttyACM0:400000 -r h.bin -VVV 
flashrom v1.2-85-gf4eeefd8 on Linux 5.10.15-arch1-1 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

flashrom was built with libpci 3.7.0, GCC 10.1.0, little endian
Command line (5 args): flashrom -p serprog:dev=/dev/ttyACM0:400000 -r h.bin -VVV
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Initializing serprog programmer
Using custom baud rate.
serprog: connected - attempting to synchronize
writecnt 8 wr_bytes 0
wrote 8 bytes
write successful
writecnt 1 wr_bytes 0
wrote 1 bytes
write successful
.readcnt 1 rd_bytes 0
read -1 bytes
readcnt 1 rd_bytes 0
read 1 bytes
readcnt 1 rd_bytes 0
read 1 bytes
writecnt 1 wr_bytes 0
wrote 1 bytes
write successful
readcnt 1 rd_bytes 0
read -1 bytes
readcnt 1 rd_bytes 0
read 1 bytes
readcnt 1 rd_bytes 0
read 1 bytes

serprog: Synchronized
serprog: Interface version ok.
serprog: Bus support: parallel=off, LPC=off, FWH=off, SPI=on
Warning: Automatic command availability check failed for cmd 0x08 - won't execute cmd
Warning: Automatic command availability check failed for cmd 0x11 - won't execute cmd
serprog: Programmer name is "stm32-vserprog"
serprog: Serial buffer size is 65535
serprog: Output drivers enabled
The following protocols are supported: SPI.
Probing for AMIC A25L010, 128 kB: programmer_map_flash_region: mapping A25L010 from 0x00000000fffe0000 to 0x00000000fffe0000
serprog_spi_send_command, writecnt=1, readcnt=3

I would be thankful for any hints.

Thanks in advance

[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 :)