2024-09-02 03:26 AM
Hello. Please forgive a 'newbie' question. Whilst I am new to STM32 chips I have been programming MCUs for many years which makes this problem even more frustrating.
I wrote a program which I then uploaded onto a Bluepill (genuine processor) using CubeIDE v1.16.0 (and later Cube Prog v2.17 as a standalone) and the STLink V2 interface with the most up to date firmware. The program didn't run so I assumed that it was something that I was doing wrong (it probably still is). I went back to basics and viewed several 'tutorials' on YouTube. I then set up a minimal program to flash the onboard LED at PC13. I left all the settings of the IDE as they came when the IDE was installed. I set PC13 as a GPIO output and left all the rest of the GPIO settings as they were. I used HAL_GPIO_WritePin to write directly to the pin with HAL_Delay as the delay mechanism. So four lines of code in total all placed after the /* Infinite loop */ /* USER CODE BEGIN WHILE */ while (1) { construct. The programmed compiled without error and appeared to upload without problem.
Resetting the board did absolutely nothing.. no LED flash or anything. I repeated the exercise by toggling a different GPIO pin and an external LED. Again nothing.
I tried setting the BOOT_0 jumper prior to powering the board and then uploading. Moving the BOOT_0 jumper back and repowering the board.
Again - nothing. I started to think that the board was faulty. I tried a totally different Bluepill board with no success.
I then had a thought. I had read that you could use ArduinoIDE to program these boards. I set up ArduinoIDE and wrote a simple LED flash program and uploaded it to the board using STLink.
To my surprise the program ran with the onboard LED flashing.
To my logic this proves that both the board and STLink are working as they should and the problem is with Cube.
I repeated the process on two other PCs - one running Windows 11 (like the original PC) and the other Ubuntu 24.04. I had exactly the same results in that the programs uploaded via Cube didn't appear to run.
Sorry for the rambling post. Have any of you any suggestions about what I'm doing wrong? Do you need to put the board into BOOT_0 when using STLink since there appears to be conflicting information on the net?
Thanks in anticipation.
Regards Nev
2024-09-02 03:58 AM
Update... I have used the debugger and the LED lights when I step to that line of code which suggests that the code has loaded correctly however it still doesn't run 'standalone'. I'll try using a release version of the code in case the program is waiting for some form of response from a debugger.
2024-09-02 04:02 AM - edited 2024-09-02 04:07 AM
Hello @alphanov and welcome to the community.
How do you know if it's a genuine processor? See: https://hackaday.com/2020/10/22/stm32-clones-the-good-the-bad-and-the-ugly/
You didn't mention which MCU part number.
What about the clock config? did you use CubeMx to generate code?
2024-09-02 04:10 AM
Sorry... the part number is STM32F103C8T6. I've done my 'due diligence' and compared the markings with images on the net.
Yes I used MX to generate the code.
I've just tried using the debugger and, stepping through the code, the LED lights up on the GPIO_WRITE_PIN line thus suggesting that the code is uploaded correctly from CUBE. It's probably 'finger trouble' (or old age) with me that's causing the problem.
2024-09-02 04:12 AM - edited 2024-09-02 07:26 AM
What is the clock source selected for System clock? The flash wait state vs system clock? Could you share your ioc file?
2024-09-02 07:17 AM
Make sure to set BOOT0 jumper to 0.
2024-09-02 03:52 PM
2024-09-02 03:55 PM
Hello. Thanks for that. I'll do some further tests and see what happens.
As I said it's probably finger trouble and old age that's causing it.
Regards
Nev
2024-09-03 06:27 AM
I don't see issues in your Clock config.
So check boot pin. Is it connected to GND?
2024-09-03 02:31 PM
Hi. I have just checked the levels on the BOOT0 pins. There is 3V3 on one outer pin and 0V on the other outer pin. With the header link in the program setting the appropriate voltage (3V3 is present on the centre pin. This seems to agree with the schematic so I assume that this is correct.
The Bluepill boards were sold as 'genuine STM32F103C8' chips and the markings are consistent with the info on the Net. (photo attached of MCU) so everything should be OK. I plan on getting a Nucleo board, from Mouser or RS, in the next week or so and it will be interesting to see if that behaves as it should. I've also got a couple of Blackpill boards coming later this week so it will be interesting to see what happens with them.
Thanks for all your assistance with this so far.
Regards
Nev