Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32F042 board not identified after flashing #6783

Closed
gesinger opened this issue Sep 21, 2019 · 3 comments
Closed

STM32F042 board not identified after flashing #6783

gesinger opened this issue Sep 21, 2019 · 3 comments

Comments

@gesinger
Copy link
Contributor

Describe the Bug

I built a custom PCB, following similar schematics and layouts of STM32F042 boards, then largely reused the files from some of those other boards in QMK to build the firmware. The branch I am working on is available here: https://github.com/gesinger/qmk_firmware/tree/dragonwell/keyboards/dragonwell

The board is identified by my computer as STM32 BOOTLOADER (on MacOS in System Information) when put in bootloader mode, and I am able to flash the firmware:

*** STM32 device connected
*** Attempting to flash, please don't remove device
>>> dfu-util -a 0 -d 0482:df11 -s 0x8000000 -D /Users/gesinger/repos/qmk_firmware/dragonwell_default.bin
    dfu-util 0.9
    
    Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
    Copyright 2010-2016 Tormod Volden and Stefan Schmidt
    This program is Free Software and has ABSOLUTELY NO WARRANTY
    Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
    
    Deducing device DFU version from functional descriptor length
    Opening DFU capable USB device...
    ID 0483:df11
    Run-time device DFU version 011a
    Claiming USB DFU Interface...
    Setting Alternate Setting #0 ...
    Determining device status: state = dfuERROR, status = 10
    dfuERROR, clearing status
    Determining device status: state = dfuIDLE, status = 0
    dfuIDLE, continuing
    DFU mode device DFU version 011a
    Device returned transfer size 2048
    DfuSe interface name: "Internal Flash  "
    Downloading to address = 0x08000000, size = 21920
    
Download	[                         ]   0%            0 bytes
Download	[==                       ]   9%         2048 bytes
Download	[====                     ]  18%         4096 bytes
Download	[=======                  ]  28%         6144 bytes
Download	[=========                ]  37%         8192 bytes
Download	[===========              ]  46%        10240 bytes
Download	[==============           ]  56%        12288 bytes
Download	[================         ]  65%        14336 bytes
Download	[==================       ]  74%        16384 bytes
Download	[=====================    ]  84%        18432 bytes
Download	[=======================  ]  93%        20480 bytes
Download	[=========================] 100%        21920 bytes
    Download done.
    File downloaded successfully

However, afterwards, nothing happens. Disconnecting the USB cable and/or pressing the RESET switch shows *** STM32 device disconnected, but afterwards the board doesn't work, and is no longer identified in System Information under USB devices. It can be put into bootloader mode again to be recognized.

Differences from other STM32F042 boards

The only major difference from the other used boards is that I'm using the STM32F042F6P6, which should have a similar configuration to other STM32F042 boards (the reference documents show the same), but has fewer pins (TSSOP-20 package). I also use PB1 as GPIO, and have altered that in the following commit:
0121f54

System Information

I am running on MacOS, but I used vagrant to build the firmware (after building on my mac led to the same issue), then QMK Toolbox on MacOS to flash the bin to the device.

Additional Context

If it helps, here's a view of the schematic I used. It's always possible I messed something else up, or soldered poorly, but it seems OK. The only major difference is that due to availability, I used a 10uF capacitor for C2 instead of a 4.7uF capacitor.

Screen Shot 2019-09-21 at 6 19 09 AM

Thank you for all the help, and for the great firmware!

@drashna
Copy link
Member

drashna commented Sep 26, 2019

I'm not sure that we properly support the F042 chip, actually.

If it's not properly support, that may be why you're having issues. But ... this is not one of the areas that I'm familiar with.

@gesinger
Copy link
Contributor Author

Thanks for the response @drashna . I actually found a solution buried in an old issue: #1254

It turns out that for the TSSOP-20 package (STM32F042FxPx, where the second F denotes 20 pins and the P denotes the TSSOP package -- in my case the STM32F042F6P6), the USB pins need to be remapped. The keyboard was recognized and works with the addition of this commit: gesinger@e27bf06

I'd be happy to add documentation around this, but since I imagine the TSSOP-20 package is rarely used, maybe it's not relevant enough to keep in the primary repo and is best to just have it documented in this issue.

Either way, feel free to close this issue, and thanks again.

@noroadsleft
Copy link
Member

@gesinger Glad you got it figured out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants