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

Images, successes and failures #6

Open
GrantMTG opened this issue Oct 20, 2020 · 1 comment
Open

Images, successes and failures #6

GrantMTG opened this issue Oct 20, 2020 · 1 comment

Comments

@GrantMTG
Copy link

Hi all, I'm new to a lot of things in this project (STM32, its toolchain, github), but do have experience with 8-bit embedded including USB and MIDI. I own one of those heathen MIDI adapter cables so I ordered some of the PCBs and started my learning curve.

Hardware: pretty much done and tested: MIDI side works with simple test programs I wrote. USB starts enumeration and gets part way, so I think all hardware is OK or nearly so. Usual power supply, clock and IO tests all OK.

MidiUsbTop
MidiUsbBottom

Tools: I installed GNU Arm Embedded Toolchain on my Win8 machine as well as STM32CubeIDE and MX. STM tools will build the Debug configuration but on downloading via STM32 ST-LINK Utility, no joy. I don't know how to step, set breakpoints, etc yet. I had more luck with GCC and the Makefile. Originally there was a problem with the build and I had to remove -nostartfiles from the make. After that build was OK and some joy when I programmed midiusb.bin again using STlink utility.

Firmware: The enumeration is stopping when the host requests "GetDescriptor (String iProduct)". It does get the language info and the (default) serial number string. So I guess there is some disconnect here in the firmware or build where String iProduct is choking. This is part of the aftermarket personalization you guys added I think. Anyway, that's where I am at, so any help appreciated. Also, if there is a better way to communicate, let me know.

UsbErrorAnalysis

@GrantMTG
Copy link
Author

Well I have a workaround. For now. It looks like appInitialization() in appMain.c is not picking up the "flag" correctly. Perhaps once I "SysexGen" it, it will, but the uninitialized (first time) is failure. I just commented out the

if(flag == 0)

case and it works!

I do have some hardware comments, minor ones. I will run tests, but my gut is telling me that the pull-up on the opto's open collector output is unnecessarily strong. I changed R11 from 330R to 4k7. I will probably also reduce the current in the CONNECT_LED by changing R6 to 1k. I prefer to use efficient (modern) LEDs that draw less current and hence the MCU has less to sink.

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

1 participant