Closed KaanDemirkoparan closed 4 years ago
Hi looking at your log it says "No flash bank found". Is your cable properly connected to the STM32? You can check it with ST Link Utility if you are able to connect and read the memory. Is the first time I see this error.
Yes it is connected properly. I opened st link utility and I can see some numbers there.
I have 2 sideboards. I have tried both of them but result didn't change. I have also tried uploading firmware.bin file with stlink utility and it gave me (file size is bigger than flash memory size) error. Do have hex file of this firmware? What do those errors mean? My board has this chip. İs it competible with firmware?
Oh, it's another chip... my firmware expects an STM32F103C8T6 (same chip that is used in the well known BluePill board). Now I understand why do you have issues. And I cannot find the datasheet for your chip... strange. Maybe is the same as this: https://www.st.com/resource/en/datasheet/stm32f103c4.pdf I see 32 kB Flash. The peripherals and memory mapping should be checked in order to port the code to your chip.
Maybe you are lucky and is just a clone of the GD32 version :) You can try flashing the GD32 version but I don't guarantee.
I tried it with gd32 firmware and it uploaded successfully. And I have also flashed my motherboard with hovercar variant. I have connected sideboard to the uart 3 and 2 pots to adc inputs. I also made all the other connections. But it doesn't work. Buzzer beeps and gives me error. What should I do?
It flashed, but I am quite sure the sideboard is not working properly that's why the beeping.Do you get the sideboard Leds blinking when you power it? If not then is not working, meaning that is a different chip than the GD32. So the code needs to be ported to your chip.
If I can reduce the size of bin file I can flash stm firmware to my chip. For example I can delete some codes that I won't use (like codes that is related to gyro etc.). I will only use 5 leds. Do you have any suggestion which codes to remove? How can I reduce the size of bin file? I have one more question. The firmware for both chips stm and gd are same right? But their bin file sizes are different. GD's bin file is 28KB but STM's bin file is 35KB. Why are they different?
You can remove the complete MPU6050 code if you don't need the gyro. That should reduce the code significantly. This is a good idea, so I think I might include it in the next commit.
And related to different code size GD vs STM, is because for the STM version I use the HAL libraries to make the peripheral access easier while for the GD I mainly use bare metal coding (it is harder, but code is smaller).
I commented #define MPU_DMP_ENABLE
this line and successfully built it (except one warning in the pic). Eventually bin file's size reduced to 31KB and that was enough for me. Then I tried to upload and it was uploaded successfully. But when I connected my sideboard to mainboard via uart 3 it still gives me beeping error.
Every step gives success but it doesn't work. Do you have any thought what is wrong with it?
İs commenting that line wrong?
Do LEDs blink or light up when you give power the sideboard?
If they are not doing anything, then the code doesn't run. Even if it flashes successfully, and all ok with building, it can still not work. Because the peripherals for your chip are mapped differently.
In big words, the Drivers
folder needs to be completely different for your board to work.
Yes. Only LED5 lights up. How can I remap my chip?
And do the LEDs 1, 2, 3 do a short blinking demo like in my Hovercar video https://youtu.be/IgHCcj0NgWQ minute 2:40?
To remap, you need to redo the project in CubeMX, maybe you can open my project and change the chip, then regenerate the project and get the Driver files. Which you will replace and then try to build.
And do the LEDs 1, 2, 3 do a short blinking demo like in my Hovercar video https://youtu.be/IgHCcj0NgWQ minute 2:40?
No. İt doesn't
To remap, you need to redo the project in CubeMX, maybe you can open my project and change the chip, then regenerate the project and get the Driver files. Which you will replace and then try to build.
Good idea but I am not sure if chip can be changed. Otherwise I will look for your project's settings and copy them to a new project with my chip.
I managed to create this file. It is competible with STM32F103C6Tx type chips. The other settings are same with your's. What should I do next? Can you guide me?
I replaced your existing files with mine and created a new file. (Can you send your mail adress or whatsapp so I can send it. It doesn't fit here.) Then I built and uploaded it successfully. And it works. When I power it on it does blinking demo, when brake is activated back light turns on, photo receptors work and I can change modes with them. Every function works. But I have only one problem. Approximately every 5 seconds it gives me serial timeout error (yellow led lights and buzzer beeps) . After 1 or 2 seconds it disappear every thing works. But 5 secs later it does it again. Why it does that? I thing it detects a timeout and resets DMA. How can I solve it?
Awesome, nice that it works. You can send me on aerdronix@gmail.com or put it on Gdrive and send me a link. Regarding the timeout I have to check, because I am also getting timeout sporadically, but only from the sideboard, so only the Yellow led blinks sometimes and then it works again. Since it's only the sideboard I don't get the beeping. I thought a wire is not perfectly making contact in my case, but now that you have it too, I think is maybe something in the code.
Thinking out loud maybe is due to the different sending intervals of the sideboard vs mainboard. I hope I can find sometime to check.
I have sent files. I checked my wires and they are connected securely. There is no way them to get loose. I think it is about codes. Something is wrong with them so they detect an error and reset chip. I hope you can find the problem and solve it.
Hi @KaanDemirkoparan ,
I just did one commit to fix the Timeout issue (see the commit notes above). Also I added a #define MPU_SENSOR_ENABLE
to allow to enable/disable the MPU6050 sensor and save code size if the sensor is not needed.
The UART apparently is very unreliable (due to noise and interference) especially under motor load. I don't guarantee 100%, but maybe this commit will fix it. Give it a try. In my case, it fixed it.
EDIT: Please don't forget to take the latest FOC commit too.
Hi @EmanuelFeru, Thank you for your work. I changed my codes with the new ones and gave it a try. With that update it works much better. İn the past it was beeping almost every 5 seconds. Now it is not. İt still beeps but much rarer and shorter than previous. İt is acceptable. Orange LED's behaviour hasn't changed. İt still always blinks. I have also noticed something. İn the previous version I had to comment "define mpu dmp enable" line in the config.h file in order to reduce the flash size and be able to flash it to my chip. (Without commenting that line it was required more than 32 KB of flash memory) After this update I didn't comment any of these settings and suprisingly it only took 27 KB of flash size. Do you have any guess why the size reduced significantly? As I know we didn't removed that much of code. Thank you again.
I am happy to hear is better. I noticed that there is quite a lot of interference from the mainboard itself, that is why you get UART timeout. On my board it completely fixed it but maybe I have less interference. Maybe it helps wrap the wires around some ferrite. IF you try and it helps let me know.
Regarding the code, I don't know why the code size decreased.. if you use Platformio, that gets constant updates, so maybe they improved the HAL Drivers library and now it is more efficient. And I also added one calibratable https://github.com/EmanuelFeru/hoverboard-sideboard-hack-STM/blob/9edd22b6b77e927c98dec86e7070947fbae79ea0/Inc/config.h#L48
with which you can completely disable the MPU6050 code. If you disable it, the code size will decrease by another 80%.
Hmm, I managed to get timeout on my sideboard (the Yellow led blinking)... I have to change the strategy. So, the issue is not yet fixed.
I am happy to hear is better. I noticed that there is quite a lot of interference from the mainboard itself, that is why you get UART timeout. On my board it completely fixed it but maybe I have less interference. Maybe it helps wrap the wires around some ferrite. IF you try and it helps let me know.
Regarding the code, I don't know why the code size decreased.. if you use Platformio, that gets constant updates, so maybe they improved the HAL Drivers library and now it is more efficient. And I also added one calibratable
with which you can completely disable the MPU6050 code. If you disable it, the code size will decrease by another 80%.
I tried shortening the wires but it didn't help. Yes I noticed enable mpu code. İt is a great option to have.
Hmm, I managed to get timeout on my sideboard (the Yellow led blinking)... I have to change the strategy. So, the issue is not yet fixed.
Looking forward to your solution. Thank you.
The serial handling code under mpu_handle_input()
@ https://github.com/EmanuelFeru/hoverboard-sideboard-hack-STM/blob/master/Src/mpu6050.c#L3715 takes up a TON of space (over 5KB) from all the text. If you remove any references to this it will get optimised out and it'll fit on the C6. You need to do some other fiddling like fixing the linker script but I'm able to get gyro data out of it as needed.
Even under VARIANT_HOVERBOARD
it does a little secret mpu_handle_input("h")
@ https://github.com/EmanuelFeru/hoverboard-sideboard-hack-STM/blob/master/Src/main.c#L183 so if you remove this it'll fit with tons of space to spare.
You are right @Knifa and thanks for the suggestion. I will wrap the mpu_handle_input()
content around an #ifdef SERIAL_DEBUG
, Then I get what you have too:
Original:
RAM: [= ] 8.0% (used 1632 bytes from 20480 bytes)
Flash: [==== ] 42.3% (used 27744 bytes from 65536 bytes)
New:
RAM: [= ] 8.0% (used 1632 bytes from 20480 bytes)
Flash: [=== ] 33.7% (used 22112 bytes from 65536 bytes)
8.6%
size reduction for the VARIANT_HOVERBOARD
. I will add the change in the next commit. Thanks again!
@KaanDemirkoparan, the Serial communiation should be fixed now. Can you check? Use latest commits.
@KaanDemirkoparan merhaba sizinle nasıl iletişime geçebilirim
@EmanuelFeru, thank you for your work. I updated codes with new ones and checked. It works better. It still gives error and beeps. But rarer and shorter. Especially it is much much shorter. Orange LED's behaviour has changed and improved. It was always blinking before than the update. Now it only blinks when the buzzer beeps.
@bekirbostanci Merhaba. Email adresim ( kaandemirkoparaneee@gmail.com ). Buradan iletişime geçebiliriz.
Good to hear that is better. In my case I have no Timeouts at all now. I am only using one sideboard, the short cable. In your case if there is still some beeping, you can try increasing the Serial timeout parameter. Even though I think that shielding and using ferrites could work better. Apparently, there is a lot of interference in the Hoverboard electronics.
I didn't play with the BAUD rate to see if there is a better setting.
As I sad earlier now error is much much shorter. İt is definitely ignorable. I will try to increase serial timeout value. İs there any maximum limit for it? Yes definitely there are lots of interference. And I noticed that after uploading firmware and connecting it to mainboard, it doesn't give any error for a while. But whenever sideboard's voltage regulator gets hot and heats circuit board it starts to give error. I think temparature is a factor of the interference. I don't know what does baud rate do? Can you explain a little?
Yeah, probably when the circuits get hotter the behavior changes a bit, so more interferance. I also noticed the inference increases when motors are under load.
If you say the timeout is very short, and almost ignorable I am quite sure it can be fixed by just increasing the timeout. So if the main board beeps, increase the Timeout on the main board. If the sideboard Yellow light blinks increase the timeout on the sideboard. Main board is at 160 now. You can go to maybe 250. For the sideboard is at 500 now, increase it to 800.
The baud rate is the speed of the Serial communication, faster means more data can be send in a shorter time.
Okay I will play with them. Thank you.
Hi. While I am uploading firmware I get a error. Why does it happen?
Processing VARIANT_HOVERBOARD (platform: ststm32; framework: stm32cube; board: genericSTM32F103C8)
Verbose mode can be enabled via
-v, --verbose
option CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F103C8.html PLATFORM: ST STM32 6.1.0 > STM32F103C8 (20k RAM. 64k Flash) HARDWARE: STM32F103C8T6 72MHz, 20KB RAM, 64KB Flash DEBUG: Current (stlink) External (blackmagic, jlink, stlink) PACKAGES:hla_swd target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc Programming Started Warn : no flash bank found for address 0x08008000 Warn : no flash bank found for address 0x08008674 Programming Finished Verify Started Error: timed out while waiting for target halted Error: error executing cortex_m crc algorithm embedded:startup.tcl:449: Error: Verify Failed in procedure 'program' in procedure 'program_error' called at file "embedded:startup.tcl", line 494 at file "embedded:startup.tcl", line 449 *** [upload] Error 1 ========================================================== [FAILED] Took 29.03 seconds ==========================================================
Environment Status Duration
VARIANT_DEBUG IGNORED VARIANT_HOVERBOARD FAILED 00:00:29.032 ===================================================== 1 failed, 0 succeeded in 00:00:29.032 ===================================================== The terminal process terminated with exit code: 1
Terminal will be reused by tasks, press any key to close it.