Closed sparksterz closed 5 years ago
Hello!
This is an annoying issue, but is pretty easy to fix. PlatformIO is using a newer version of the libmaple libraries, and unfortunately, doing so breaks everything. Fortunately, you can instruct platformIO to use the correct version of the libraries by:
1) Going into the platformio.ini file
2) Adding platform = ststm32@~4.5.0
to the bottom of the command list
3) Save & compile.
That should force PlatformIO to use the correct version of the maplelib libraries. If you have the latest version of the codebase, you should already see these changes made here: https://github.com/AidanHockey5/STM32_VGM_Player_YM2612_SN76489/blob/master/platformio.ini
I actually got around this by removing the duplicated platform
entry. There's one for both ststm32 and one for ststm32@~4.5.0
I deleted the one referencing a specific version, but was able to compile and push. Though my board doesn't work...I'll try referencing 4.5.0
yeah, my build is broken with 4.5.0. In fact any specific version from 4.5.0 up doesn't build. I was able to build and push using this as my platform:
https://github.com/platformio/platform-ststm32.git
I got that idea from this link: https://community.platformio.org/t/stm32f1-build-failing-with-duplicate-inline-errors/6757/5
My stm32 just pulses a blue led though after it's pushed and I see no other activity.
Go ahead and delete your repo folder and re-clone. I've changed the u8g2 library to the "pio" version so it will compile without an external dependency and have also removed the extra STM32 platform command. I can confirm on a fresh clone that the code now compiles without errors.
If that still doesn't work, I've attached a precompiled bin down below so you can at least test to see if your hardware works. By the way, are you using the new x64 version of VS code? I'm using the old 32-bit version. I don't see why that would make a difference, but it might be worth a shot.
I am using x64 VS Code, but can't build with 4.5.0. Your changes did resolve my u8g2 problems though. I still needed to use platform = https://github.com/platformio/platform-ststm32.git
I'll see if I can manually load that pre-compiled firmware, but I'm suspecting a hardware issue on my side at this rate. I get no audio, no video, and just a pulsing light on my STM32.
I also can't seem to find a way to push your provided firmware to my device. Platform IO always wants to rebuild it.
Let me try completely uninstalling and reinstalling VSCode+PIO and see if that affects compilation. I'll report back with the results in just a bit.
Hm, nope. Even with a fresh install of VSCode and PIO, my code compiles fine. If you replace the platform
command with platform = ststm32@~4.5.0
, does it still give you those weird static inline __
errors, or is it different now?
I still get errors using any tagged release (4.5.0, 4.6.0, 5.0.0 and 5.1.0). 4.5.0 does give me the static inline ones. I can't remember if the errors were the same for every other version as well.
When I replace the platform with the link to the repo this is the behavior I end up with: https://youtu.be/dB5RmhSa9gU
Also, while I appreciate the quick response, I will be busy in about one hour for the rest of the day, so don't side track your whole day or anything.
First thing I noticed is that your STM32 'bluepill' board isn't a 'bluepill.' If the MCU and pinout is the same, it should work fine, but I'm wondering if the bootloader is different. Could you link me where you bought your STM32 board from?
Sure, I was wondering if that was the issue potentially as well, but for everything I could find they appear to be the same. https://robotdyn.com/stm32-arm-arduino-mini-system-dev-board-blue-pill-with-arduino-bootloader.html
So I checked the pinout and MCU, both match up with the original bluepill board, so that MCU should work fine. Attached is a zip file containing a STM32flash-based uploader that you can use to manually apply the firmware to your board without compiling with PIO. I'm still stumped, but this should at least let you test your hardware.
After unzipping,
1) Simply connect your board and reset it with the programming pin set like normal.
2) Double-click UPLOAD.bat
3) It will ask you for a COM port to target. For example, my MegaBlaster is on COM24, so I'll just type in COM24
. Make sure COM is in all caps and that there are no spaces.
4) The tool should manually begin to upload the precompiled firmware.
Aidan...YOU'RE THE GOD DAMN BEST!
I forked the repo, and I'm going to see if I can figure out or resolve the issues I have building. I noticed the file size of mine came out to be 61kb versus your provided one which was 59kb...so, something is definitely different. I guess I'll have to try and dig into why ststm32 4.5.0 doesn't work on my box. I'm not sure what you want to do with this bug, feel free to close it if you'd like. If someone else comes along with a similar issue maybe it would be worth reopening then.
Yeah!! Awesome, glad to see that your hardware is working and that you were able to get a successful flash.
This compile bug is weird to me. I'm not entirely satisfied and I wish I knew what was wrong with your copy of the code. If another person comes along and has the same issue, I'll be willing to drop in again and lend a hand. If I make any significant changes to the firmware in the future and you're still having compile issues, I'll post an updated version of the precompiled bin.
Alright, so once you're all flashed up, make sure you set the programming jumper back to 0 so the code stays on the device. Also, it looks like your PSG switch is set to 0, switch it up to 1 to enable it.
Feel free to drop by any time if you have any more issues!
On Mon, Mar 4, 2019, 6:12 AM Brian King notifications@github.com wrote:
Aidan...YOU'RE THE GOD DAMN BEST!
[image: board] https://user-images.githubusercontent.com/1699679/53738351-f9c71d00-3e5c-11e9-862b-12c22d0803ae.jpg
I forked the repo, and I'm going to see if I can figure out or resolve the issues I have building. I noticed the file size of mine came out to be 61kb versus your provided one which was 59kb...so, something is definitely different. I guess I'll have to try and dig into why ststm32 4.5.0 doesn't work on my box. I'm not sure what you want to do with this bug, feel free to close it if you'd like. If someone else comes along with a similar issue maybe it would be worth reopening then.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AidanHockey5/STM32_VGM_Player_YM2612_SN76489/issues/4#issuecomment-469266380, or mute the thread https://github.com/notifications/unsubscribe-auth/AI3xb_MfZC0VFEoH0-jW9vosX1rOHCJhks5vTSnDgaJpZM4bbJ1B .
Oh, good to know on the PSG. I didn't have a chance to really listen to much this morning before leaving for work. Because the interactive guide labeled it as "Mute PSG" I assumed 0 was not muted.
Yeah - I tried digging into this for about 3 hours today while being significantly out of my element in terms of dev environment, but anything that I found would either compile and then not run - or I'd find the ever helpful advice of "Point the platform version at the latest in git" followed by "Yep, that worked" which, does not in this case.
I think my problem could be 2 fold. A problem with platform io, and also a problem with the libraries in ststm32...but I'm more just thoroughly confused than anything else right now. I somehow managed to mess up my environment enough that my include paths are entirely bogus and nothing can be found. Maybe I'll try this in an Ubuntu VM and see if I can avoid a headache that way now that I know if I can build it, I still push from Windows if I needed to.
These were interesting sources...I'm still not sure if they have relevance (adding them for my reference): https://community.platformio.org/t/stm32f1-blue-pill-stuck-in-dfu-mode-after-upload/6853/5 https://community.platformio.org/t/pio-arduino-stm32f103cbt6-remap/6786/10
So I decided to bring out an old computer of mine that was running Windows 10 x64 and has never had VS Code or PlatformIO installed on it before.
I installed both and cloned the repo. Sure enough, once I opened the project and compiled, I was met with the same wall of inline
errors.
After playing around with the versions a little, I determined that version ststm32@~3.8.0
was the highest version that would compile without errors. I uploaded the code to my MegaBlaster and sure enough, it worked like a charm.
Why does my desktop with version 4.5.0 compile fine and this old computer only compile with version 3.8.0? I frankly have no idea. It seems super odd to me.
Anyways, I've pushed the change to 3.8.0 to master. Go ahead and give it a shot and let me know if anything changes!
Yep @AidanHockey5 you've done it again! I can now build and deploy from my machine. Awesome stuff. Now I can actually tinker around a bit with the code and maybe debug some interesting issues I've noticed over the serial port. I'm excited! Hands on learning is my favorite :)
I've learned a few things as well, turns out not all SN76489AN chips are made equal. I put 3 different chips in the socket before finding one that had what I felt the proper pitch and volume levels. Good call on adding sockets for those chips!
Great! Glad to hear it's finally working for you. Have fun and happy hacking!
I've recently assembled my board but am unable to build/upload the project. I have the latest VS Code and recently installed Platform IO. I've made/logged in with my account, but when trying to run a build or upload I am having issues.
The first of which was that
U8g2lib.h
was not recognized. Within platform io I downloaded u8g2 and that seems to have resolved that issue. The other however I'm unsure of. They all seem related but I don't understand what the errors mean.Here's the error console