Electronics > Microcontrollers
STMCubeProgrammer problems after uploading program to STM32F103 with Arduino IDE
(1/1)
MathWizard:
I have a STM32F103C8T6 blue pill PCB, I got it from Amazon 3yrs ago, and the ad link no longer works, so IDK what anyone else did with these.
When I 1st hooked it up over USB, windows called it "Maple" , I think on a COM port tho. This PCB has the correct 1.5k resistor for the USB enumeration. And it has the 2 boot jumpers like the one in the pic below.
There was a program already in it, flashing the green LED.
I couldn't get Arduino IDE to work with it over USB. I followed guides and had the required add-ons to the IDE, like the STM32 files under Boards Manager. I also have the zadig program to try and get USB working (which I sort of did only today, now it can show up as a USB device).
I installed STMCubeProgrammer to a custom location, and had problems, so reinstalled it to the default location. Then using a Bus Pirate and the serial terminal Putty, I set up UART for pins A9,10 of the STM32, and exit Putty.
Then in Arduino IDE, I wrote my own LED blink sequence code for the LED on PC13, and it FINALLY uploaded successfully. Then I noticed that the LED blinking was inverted, so I changed all the digitalWrite LOW/HIGH's. And uploaded that code too, and it worked.
But since that time yesterday, and I unhooked it, I can't upload to it anymore. I've tried moving the BOOT0 pin, it's not that. The program is still in there running fine tho.
Yesterday I could see there was about 20kB of used up flash memory, using STMCubeProg. Now I can't get STMCubeProg to connect over UART anymore. And in Arduino IDE, I get a similar message, as it tries to use the STMCubeProg drivers or what ever it does.
--- Quote ---Sketch uses 34044 bytes (51%) of program storage space. Maximum is 65536 bytes.
Global variables use 4544 bytes (22%) of dynamic memory, leaving 15936 bytes for local variables. Maximum is 20480 bytes.
-------------------------------------------------------------------
STM32CubeProgrammer v2.16.0
-------------------------------------------------------------------
Serial Port COM4 is successfully opened.
Port configuration: parity = even, baudrate = 115200, data-bit = 8,
stop-bit = 1.0, flow-control = off
Timeout error occured while waiting for acknowledgement.
Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again...
Failed uploading: uploading error: exit status 1
--- End quote ---
--- Quote ---20:28:43 : STM32CubeProgrammer API v2.16.0 | Windows-64Bits
20:28:53 : UR connection mode is defined with the HWrst reset mode
20:28:53 : RTS low
20:28:53 : DTR low
20:28:53 : Serial Port COM4 is successfully opened.
20:28:53 : Port configuration: parity = even, baudrate = 115200, data-bit = 8, stop-bit = 1.0, flow-control = off
20:28:53 : Timeout error occured while waiting for acknowledgement.
20:28:53 : Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again...
--- End quote ---
So all that extra stuff that gets uploaded, did that mess something up ?? I'm still using the same board and COM port settings, uploading with "STM32CubeProgrammer(Serial)" in the Ard.IDE.
I ran a program called AccessPort (no install was done). I was following this guide, trying to find out more stuff about the bootloader. Actually that gave me a problem with Putty tho afterwards, and rebooting didn't fix it and I had to reinstall Putty just to get UART working from the BusPirate again.
https://community.st.com/t5/stm32-mcus/how-to-utilize-stm32-system-rom-bootloader-commands/ta-p/605286
So in AccessPort, if I type and send "00 FF", which if I understand it, is some GET command, 00 is the command to list all other commands, and the FF is extra for a checksum. And in the guide, with some 48 or 64 pin STM32 chip, they get ACK's that should be 0x79
--- Quote -------------------------------------
AccessPort terminal screen:
----------------------------------
Send:
00 FF /* Comment: command; checksum: 1’s complement of the command code = FF */
Output:
79 0A 40 00 01 02 11 21 31 44 50 63 73 79
--- End quote ---
When I go into AccessPort and choose the COM that the Bus Pirate is on, connected via UART to the STM32F103C8, and type "00 FF", I get
83 F2 EF F2 DC EC F2 72 CC 21 4E 8C 89 D8 00
So what does that mean ?? Why is there no 79's there for ACK, and ?? I don't see these listed in the Table 2. USART bootloader commands
If I try to ask what UART protocol version it uses, with "01 FE", I get F0. Actually now running AccessPort, "00 FF" only returned "0E", and so did "01 FE". Now I get "01". So that program is old, and just trying to copy the HEX output text, by clicking like normal with a mouse, causes the program to crash and exit.
I wanted to try STMFlasher, it's already built into CubeProg, and now not working, but I tried the old STMFlasher, and also can't connect over UART.
Later this week I should have a ST-Link, but other than reinstalling STMCubeProg, IDK what has gone wrong, besides letting Arduino IDE upload my blink code that still works.
radiolistener:
Programming STM32 through serial port bootloader is torturing yourself.
Use some cheap USB-SWD adapter like ST-LINKv2 with ST-Link Utility to read/write the code or just use debugger to upload it.
--- Code: ---$ st-info --probe
Found 1 stlink programmers
version: V2J37S7
serial: 54FF6806****************
flash: 131072 (pagesize: 2048)
sram: 32768
chipid: 0x0468
descr: G4 Category-2
--- End code ---
stj:
i put this on mine.
https://github.com/Serasidis/STM32_HID_Bootloader
then it worked well
MathWizard:
2 more days till the ST-Link gets here, and 5 more Blue Pills, but even on another PC, with a fresh windows install, and just the FDTI RS232 drivers for the Bus Pirate, and STMCubeProg installed, I cannot access the chip. I'm sure I have the correct COM port settings for setting up the BusP, and then the correct ones for the STM32.
I've read through all kinds of posts, all over the place, and IDK if it's a driver thing, and USB/UART thing, or an electrical issue on the chip, or something that the IDE wrote to the chip. I had a look at the RX/TX pins on a scope, and they are doing some stuff that looked normal, but IDK the protocol. I could try logging it with my little logic analyzer.
I did try the other UART pins without luck. I have some blank chips here, of the exact same type, and I have 1 working 1, on a DSO138.
So I should try one of them on the Blue Pill. There's also Phython programs that will do the SingleWireDebug that the ST-link does, using the Bus Pirate. But again, I barely know any C++, and I'm not very good with BusP, or serial terminals either.
What courses are people expected to know, just to do MCU's anyways ?? Surely they shouldn't have to know Windows and Linux inside out already, and all the programming behind them.
MathWizard:
Ok I was setting the UART wrong, or different, like the receive polarity, in Bus Pirate. After playing around with the terminal "Realterm", I could see parity errors when trying to get an ACK response or the GET response. Like 0x79 at the start and end of a GET response, gets turned into 0x43.
So on my v3.6 BP, when it connects, it uses 8, none, 1 stop bit. Then when the BP connects to the STM32, I used 8,even, 1 stop bit, but there's a receive polarity that I wasn't setting to default.
Now STM32CubeP works again, and Arduino can upload again. My official STM ST-Link V2 from Digikey won't be here till tomorrow, oh well. I had also ordered 2 clones, but they are shipping too slow.
Of the new and old STM32F103C8 's I've checked so far, they all seem to be working, and have the 128kB flash.
I even put one on a protoboard and breakout board combo I made yesterday, and it works. IDK if the 2 crystals I have on that board will work tho, so now to try and get them to start.
Navigation
[0] Message Index
Go to full version