-
Notifications
You must be signed in to change notification settings - Fork 16
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
Get blinky running again and update xpcc. #2
base: master
Are you sure you want to change the base?
Conversation
So… not sure how you feel about the ST USB stack, but it may be interesting to look at kevinmehall/usb for a OSS USB implementation. ST recently released a lower-level HAL than STCube, maybe that could be of use to port this. To be clear, I've used neither of these, so can make no call on the quality or ease-of-use, so feel free to ignore me (but please report back your experiences ;-) |
Just FYI, as far as I know, the 48MHz clock is the only one that can be calibrated via the USB clock. |
@ekiwi Thanks for pointing out that detail. At the moment the device does not start after flashing with DFU in one of about ten tries. This is hard to reproduce and hard to debug. Any suggestions? |
82edd2a
to
ca2ee1b
Compare
- Test 8 MHz clock with PLL. - Got hard faults when switching to 48 MHz clock because flash latency was not set at all - HSI48MHz clock is working reliably - Use common SConstruct from xpcc - Add Logger to board file - Add xpcc_abandon handler - Move board file to separate directory - Add OpenOCD config for SWD (without reset line) - Successfully programmed the board with SWD and DFU - Blinky and Button and USART TX works.
ca2ee1b
to
43ddb82
Compare
Ok, found it. Kevin's version did not set the flash latency at all. So running at 48 MHz with zero wait states is out of spec and pure luck. It is important to set the wait states before switching the clock. I was not able to figure out why the reset after DFU programming does not work reliably. Pressing reset or just unplugging the device is a workaround. You you please review? I will take care about CAN and USB in later PRs (and feature branches of course). @salkinium Thanks for pointing at the USB stack. I probably won't try it now because someone Daniel knows has a running binary for the hardware. Will look into what is more convenient. |
DFU method was removed but it will be added to xpcc. See roboterclubaachen/xpcc#285.