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

Use with NucleoF103RB board #14

Open
TuanRatp opened this issue Oct 14, 2022 · 6 comments
Open

Use with NucleoF103RB board #14

TuanRatp opened this issue Oct 14, 2022 · 6 comments

Comments

@TuanRatp
Copy link

Hi,

I am interested in your app and I would like to use it with my Nucleo F103RB board. Does it work as-is, without any hustle to resolve ?
As far as I know, the Nucleo board and the BluePill share the shame µC.
Thanks in advance,
Tuan

@thanks4opensource
Copy link
Owner

I have no direct experience with that ST Nucleo board, but assuming it connects all STM32F103 pins directly to on-board access points without any intervening circuitry as per the Blue Pill boards, I don't see why it wouldn't work. Online research seems to indicate that the Nucleo is available for either the 48 or 64 pin version of the F103 MCU -- if 64, "buck50" would not use the 16 extra I/O pins, although again that probably would not cause problems. All of this is of course speculation, not a guarantee. Please read and understand the LICENSE.txt file and the WARNING! in Hardware Connections. Any and all use of this repository is strictly at your own risk.

@TuanRatp
Copy link
Author

That's fair and all I need to know.
I flashed the firmware using stlink-tools and it seems OK. However, when launching buck50.py, I'm stucked at the connection phase, at which I've to press Ctrl+C to abort. I'm using Debian and the board is recognized as /dev/ttyACM0 device.
Connecting to buck50 device (press CTRL-C to abort ... ) Timeout waiting 1 second for 4 bytes from USB CDC-ACM pipe Will retry sending signature data in 1 second Connecting to buck50 device (press CTRL-C to abort ... ) Timeout waiting 1 second for 4 bytes from USB CDC-ACM pipe Will retry sending signature data in 1 second ^CTraceback (most recent call last): File "/home/tuan/Bureau/Buck50/buck50.py", line 6782, in <module> main(args.quiet, args.acm, args.no_auto_viewer, args.file, args.halt) File "/home/tuan/Bureau/Buck50/buck50.py", line 6641, in main firmware_connect(quiet) File "/home/tuan/Bureau/Buck50/buck50.py", line 212, in firmware_connect time.sleep(1) KeyboardInterrupt
Can you give me some pointers where to resolve ? Thanks

@thanks4opensource
Copy link
Owner

Does your Nucleo board have a 64 or a 48 pin STM32F103? If the former, check the datasheet for any incompatibilities in the pin assignments between the two variants, particularly the USB+ and USB- pins. I hope that there aren't any register-level differences between the internal USB peripherals but anything's possible, either because ST rev'd the chip or buck50 was written (unknowingly) on clones. Did you compile buck50 from source or just flash the provided binary? Maybe there's some difference in the memory map and the peripheral base address due to increased memory between the versions (there shouldn't be, but ...).

You could also try building and running the examples in Papoon USB which is what buck50 uses. Be aware that they're nowhere near as polished as buck50. Enumeration is the hardest part of the USB protocol, and that's what seems to be failing here. If you do find (and fix) any problems in the code please consider submitting a pull request with your findings.

@TuanRatp
Copy link
Author

I think I know where the problem is. On the Bluepill, the MCU is connected to the D+/D- signals of micro-USB port at pins PA12/PA11 respectively. Whereas on the Nucleo board, the MCU is connected to a Virtual COM Port (which in turn is routed to a mini-USB to communicate with a host) at PA2/PA3 as an USART peripheral. As I see it, the pins are not compatible...

I've just ordered some cheap Bluepill board on Aliexpress which contains highly likely a clone MCU. I'll see where it take. Thank anyway for your answers.

@thanks4opensource
Copy link
Owner

Yes, good call. I didn't think of it, partly because I have a different Nucleo board (not F103) which has both the ST-Link USB port on the snap-off auxiliary board and a second one for real USB use by the MCU. I just downloaded UM1724 and now see that the F103RB has only the single ST-Link USB connector.

UM1724 is ST's usual obfuscated attempt at documentation, but it looks like the CN2 jumpers merely disconnect the ST-Link USB from the CN4 SWD header and thus the main board. I guess that's so one could use an external ST-Link although the point of doing so escapes me. If the ST-Link section was prematurely broken off but afterwards again needed it would still require having the CN2 jumpers installed and then connecting the the CN4 pins to the main board's 3V3, GND, PA13/SWDIO and PA14 SWCLK.

In any case there doesn't seem to be any way to connect PA11/USB- and PA12/USB+ to the miniUSB port, even if it's disconnected from CN4/SWD. You could wire a mini/micro/normal USB-B jack to PA11/12/etc, but your path of getting a cheap Blue Pill board (the inspiration for buck50 in the first place) and saving the expensive Nucleo for something else is probably the better idea (mis-wiring the USB could easily destroy the ST board).

@TuanRatp
Copy link
Author

I think I should stop by and give some follow-up. I received an BluePill board from AliExpress and flashed it asap. The whole thing works!

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

No branches or pull requests

2 participants