Closed jernejp21 closed 2 years ago
I got USB running again. But it's very frustrating that you can't use USB and debugger at the same time. For next board revision, please remove MOSFET and make direct connections between MCU pins and D+, D- pins. Don't connect anything else on debug pins. If needed, use bigger STM32F103 package with more pins.
@jernejp21 How did you get USB running again? I think I have the same problem. I can not use the ST-LINK utility on the SKR MINI E3 V2.0 board. Is it really because the MOSFET is present? How do I fix my board so I can use the debugger for a little while? Can you provide a wiring diagram? I only need it long enough to get the bootloader for the SKR MINI E3 V2.0 backed up. Once I have the bootloader backed up I want the USB port back. Can you provide a diagram showing me how to get the USB working without a debugger? In your fix did you have the ability to use both the ST-LINK and the USB port?
@GadgetAngel Connect your debugger to debug pins. After you are done, unplug debugger and USB will work. You cannot use USB if debugger is connected. I'm using iSystem IC5000.
@jernejp21 I am using a brand new SKR E3 V2.0 board. I just got it, (this is my second one). The first board, I tried to use the BOOT pin to access flash memory but I ended up hacking at the board so bad that it became un-usable.
I have done a lot of reading about STM32 processor and boot modes. Some boards require you to use UART and change the boot pins to access the flash memory. Others only require the use of ST-LINK-V2 clone like this one with ST-LINK Utility: https://www.amazon.com/gp/product/B00RYVLN4U/
I have this repository that I have created to help other users of BIGTREETECH boards located at : https://github.com/GadgetAngel/BTT_SKR_13_14_14T_SD-DFU-Bootloader. All the boards that are on the repository I own. I bought boards to test out Temperature readings for Marlin, so since I already owned the boards (most of them) I decided to help people who are missing their bootloader.
Well in my journey, only ONE board has given me a problem: SKR MINI E3 V2.0 board. I have tried UART connecting to it. I have tried the SWD connector but because of the SWCLK being used for USB-CONN PIN the ST-LINK Utility keeps giving me "CAN NOT connect" errors (on Windows 10 machine). I tried using openocd and it will not connect. I am getting ready to pull out my LINUX MINT laptop and try some Linux utility like dfu to see if I can talk to it that way.
Here is the problem, I agree with you, BTT reused the SWCLK clock for other things. If you compare the schematics from SKR MINI E3 V1.2 to the schematic from SKR MINI E3 V2.0 you will see that one of the differences is that on SKR MINI E3 V2.0, Bigtreetech decide to reuse or repurpose the SWCLK pin to drive the USB D+ PIN., (which STOPS the ST-LINK Utility dead in its tracks). On the SKR MINI E3 V1.2 board the USB D+ PIN is driven by USB-CONN PIN. The SWCLK PIN on the SKR MINI E3 V1.2 board is not repurposed and the ST-LINK Utility works as it suppose to.
This is the current SKR MINI E3 V2.0 schematic:
This is the current hardware connections and current Marlin Firmware setup:
This is my purposed Solution, I know I will lose the PS-ON connector but I will be able to use the debugger with the USB port at the same time:
I am going to try this and let you know if it works.
@jernejp21 You state the following:
Make changes in Marlin so you don't disable debug pins and flash new FW.
What specifically did you change in Marlin that did not disable the debug pins?
@jernejp21 I am trying again with my new SKR MINI E3 V2.0 board without the hardware modification:
I thought you said all I needed to get it to work was to hook up the debugger to the SWD connector, I have connected up the debugger to the SWD connector and ensured that my USB cable is not plugged into the board. The board is powered by the ST-LINK debugger. I do not have power on the board via the 24DC power supply.
What am I missing here?
I found the following:
in pins_BTT_SKR_MINI_E3_V2_0.h:
// Release PA13/PA14 (led, usb control) from SWD pins
//#define DISABLE_DEBUG
in pins_BTT_SKR_MINI_E3_common.h:
// Release PB3/PB4 (E0 STP/DIR) from JTAG pins
//#define DISABLE_JTAG
#ifdef SKR_MINI_E3_V2
//#define USB_CONNECT_PIN PA14 //was PA14 which is SWCLK line for SWD connector
#else
#define USB_CONNECT_PIN PC13
#endif
//#define USB_CONNECT_INVERTING false
in configuration.h:
#define SERIAL_PORT 2
/**
* SD CARD
*
* SD Card support is disabled by default. If your controller has an SD slot,
* you must uncomment the following option or it won't work.
*/
//#define SDSUPPORT
I am not using SERIAL_PORT -1 which is the USB port. But how do I ensure that Marlin is not trying to use the SERIAL connection to the USB Port. I commented out the DISABLE_DEBUG and DISABLE_JTAG so the pins should be freed up to use for debugging.
Have a forgotten something?
@jernejp21 I just tried it with the 24VDC PSU and took of the 3.3VDC pin from the SWD connector since the PSU is suppling the POWER and it still does not let me connect. I really do not want to hack into this new board.
how does ST-LINK work with VS code if I can not get ST-LINK utility to work?
I'm not using ST-Link utility. I'm using winIDEA. 3.3VDC pin is not a power supply, but voltage reference for debugger, Debugger needs to know if logical levels are 0, 5V or 0, 3.3V. Connect all 5 pins to ST-Link! 3.3VDC, GND, RESET, SDW, SWCLK. You need external power supply. 24V or 12V.
In Marlin change only //#define DISABLE_JTAG
, if you want to debug the application. For storing flash code into binary file, you don't have to change this.
Install winIDEA and install demos. There should be also demo called STM32F103ZE_Simple_Demo\winIDEA\ST-Link.xjrf. This project is configured for ST-Link. Use Debug -> Run Control -> CPU Reset. It should connect. DO NOT DOWLOAD DEMO CODE! Just perform CPU reset.
This is what I get:
Here is my hook up:
Any other suggestions, I really want this to work, any ideas?
Is your ST-Link working properly? I currently cannot test, because I'm moving. I will test this and let you know as soon as possible.
I used another one and I can reset the board via WinIDEA. How can I use WinIDEA to save flash memory. I tried it with ST-LINK utility and I am still getting not connect. Same device, but WINIDEA will initialize.
Same device with ST-LINK utility:
How can I use WinIDEA to save flash memory?
Alt + 6 is shortcut to open Memory window. Enter address 0x08000000 and confirm.
Right click in Memory window -> Save.
Enter address (start address) and enter size. Select or create new file where you want to save data.
In ST-Link utility, did you try to select Connect Under Reset as the utility advices?
In ST-Link utility, did you try to select Connect Under Reset as the utility advices?
Yes, I tried to "Connect under Reset", and it will not work
Alt + 6 is shortcut to open Memory window. Enter address 0x08000000 and confirm.
Right click in Memory window -> Save.
Enter address (start address) and enter size. Select or create new file where you want to save data.
I can not thank you enough. Thank you soooooo much. Your solution worked and I did not have to hack at the SKR MINI E3 V2.0 board.
How do I use winIDEA to restore the bootloader-and-firmware file I saved in .hex format? If I ever discard static electricity these boards have been known to loose their bootloaders. So how do I download the bootloader.hex file, I just saved, into the SKR MINI E3 V2.0 board flash memory?
In winIDEA go to Debug -> Files For Download. Delete existing files and add your file. Make sure that hex file has the correct address in it. If it starts with address 0, you can double click on added file and set code offset.
I think that Demo mode also works with ST-Link. Connect ST-Link to PC, but disconnect it from MCU, just in case. In winIDEA go to Tools -> Demo Mode and perform download.
You can then check if code was downloaded to the correct address.
BTW, you can use winIDEA also with Segger J-Link and a big spectre of Cortex-M devices.
@jernejp21 I just found a problem.
winIDEA does not save the bin file in the correct format to flash back the device. I tried Debug-> Files for Download, I got an error message when writing to 0x08000000 and it was winIDEA that wrote the file out.
So something is not working correctly.
I ended up using winIDEA to erase the whole chip because I accidentally overwrote my bootloader messing around with winIDEA.
Then I had to use my LINUX MINT laptop to use the st-flash utility to write the bootloader I found on the web. I also was able to save the bootloader-and-firmware file with stlink-gui on Linux. Right now I am checking out the openocd on linux. I might be able to do all of it with this utility on LINUX MINT.
By the way my device is not bricked. I was able to get the bootloader and firmware installed on it.
Apparently the STLINK (open source version) on LINUX can read and write to the SKR MINI E3 V2.0 board. Now the firmware I am running has the SWD pins enabled for debugging and I am not connected via the USB port. I have not tried to see if I can do both at the same time yet, I will let you know.
What kind of error did you get? Maybe the device was locked and you just needed to unlock it. With mass erase you also unlock the device.
winIDEA is a professional tool, ST-Link is hobby tool. If you want more details on how to use winIDEA, iSystem has great online help.
The error message was a CMD_xxx or something. I can not remember now. It occurred on the first byte of 0x08000000 address. It only happened when I tried to save the file back into flash memory.
I hear you but most users of 3D printers are hobbyist. So they want to be able to use a hobby tool.
If you can figure out out to get winIDEA to save the files in the correct format (2Kib per page and the right number of pages) [The system architecture lays out the format.] I will use it. But when I erased my flash memory and went back to flash the file from the file that winIDEA saved the ST-LINK would not flash the file because it was not laid out correctly. That is why I had to go find one that was. I tried saving it back with winIDEA but remember it kept giving me an error. Maybe the error was due to the fact that the memory was locked when I saved the file. Then when I erased the memory became unlocked and a bit changed??? I do not know. All I know is it did not work. So I had to find a method that will work.
I need some rest now. I got openocd to save both the full flash and the bootloader only file but I had to do it from a Linux machine. Next I will try to reenable the DISABLE DEBUG commands in Marlin and enable the USB port. Upload this change so that is the firmware running on the board and see if I can still rip the bootloader and firmware from the board using openocd and linux. If I can do that then I will let you know. But at this point I need sleep so I will be off for the next 8 hours. I suspect that my next test will run without a problem. I have always wondered how people got the bootloader off this board and I only see it in .bin format not .hex. Well openocd will only save the file in .bin format! But I am still going to do the test. The last step will be to erase memory again and upload again but this time using openocd and linux not st-flash on linux.
@jernejp21 I know you already know this but I double check it anyways. You are right if you are using the SWD connector the USB port disappears and if you use the USB port the SWD connection is disabled.
I ruined 2 ST-LINK-V2 clones on the SKR MINI E3 V2.0 board, but I finally got the bootloader off the device.
After trying out a lot of combinations I finally gave up on using the ST-LINK-V2 clones and pulled out my official ST-LINK-V2 debugging probe. What is really interesting is that the official ST-LINK-V2 debugging probe from STelectronics had no trouble connecting to the SKR MINI E3 V2.0 board even if the DISABLE_DEBUG was enabled in the firmware. I tested the board with the official ST-LINK-V2 under Windows using ST-Utility and under Linux using the stlink and eblink utilities. I also tested it with openocd. As long as I was using the official ST-LINK-V2 device I had no problems talking to the board via the SWD connector.
So again, you were right. It was my ST-LINK-V2 Clone that was the problem all along.
Thanks again for all your help.
Got the ST-Link-V2 clone working too.
flashed your firmware via SD-Card (FW File needed to turn ON SWD connector.zip), used winIDEA to reset, closed winIDEA and connected the ST-Link Utility with 1.8MHz.
Can any one explain why this FET is in first place ? It's PNP driven by micro. I just don't get it why you want to drive D+ line with 3.3V ? It's either 5V or 0V. Mind blown.
Can any one explain why this FET is in first place ? It's PNP driven by micro. I just don't get it why you want to drive D+ line with 3.3V ? It's either 5V or 0V. Mind blown.
Me stupido. It's for indicating that STM32 will work in full speed mode. However there is a problem. There is no VBUS (USB 5V) sensing. STM32 can't tell if USB cable is connected or not.
@luqasz it doesn't need sensing. If debug mode is on, Marlin will output data regardless of USB cable being connected or not. And when you want to send data to Marlin, Marlin will get interrupt triggered from USB registers when data is in RX register.
What BTT should do is to remove FET and remove +5V supply from USB cable. That way you have only communication pins and GND connected to PC, which is what you want. 5V from PC is not enough to move motor drivers, so you don't actually need power supply from USB.
According to USB specs and stm AN4879 app note, it should sense VBUS. Pulling D+ high when USB cable is not connected, violates USB specs.
Any way, now I know what's going on on the board.
I had exactly the same issue with SKR mini E3 v2.0 after flashing firmware, bootloader got stuck after restart and ST link will not connect via SWD pins. Thanks to maker of the files and [jesseklm]for posting zip file as i managed to connect board to st link v2 and upload original btt bootloader for SKR mini e3v2.0. Now board is working
Looks like this is fixed on V3.0
Looks like this is fixed on V3.0
@jernejp21 Do you have some schematics for v3.0 board ? found it in this repo.
I finally found a solution. D+ pin must be connected to 3.3 V via 1,5 kΩ pull-up resistor according to application notes. To do this, remove mosfet U7 and connect S and D pins. This will remove unneeded mosfet, USB will work and SWD debug will work.
Yee 👍 Thanks..
I finally found a solution. D+ pin must be connected to 3.3 V via 1,5 kΩ pull-up resistor according to application notes. To do this, remove mosfet U7 and connect S and D pins. This will remove unneeded mosfet, USB will work and SWD debug will work.
slika.png (view on web)https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/assets/61543115/35a47454-e114-4cc0-a962-26261119d544 slika.png (view on web)https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/assets/61543115/08ac8b84-1edc-4ebc-bdfb-e90ec1d7a5f3
— Reply to this email directly, view it on GitHubhttps://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/issues/431#issuecomment-1912052732, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AR5SWIGO6G67TB6FHN6WCBDYQOUBLAVCNFSM4SXJJZUKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJRGIYDKMRXGMZA. You are receiving this because you commented.Message ID: @.***>
I finally found a solution. D+ pin must be connected to 3.3 V via 1,5 kΩ pull-up resistor according to application notes. To do this, remove mosfet U7 and connect S and D pins. This will remove unneeded mosfet, USB will work and SWD debug will work.
![]()
Hi,
Do you have any other suggestions on how to fix this error? I followed your instructions exactly, but it didn't help. My SKR Mini E3 V2.0 was damaged after a short circuit. I had to replace some parts, including the STM32 controller.
I tried to upload new firmware using an SD card, but it didn't work. I then realized it needs a bootloader. So, I ordered an ST-LINK V2, connected everything to the SWD on the board, and for the first time, when I pressed the connection button in the STM32 ST-LINK Utility, I got a connection.
However, when I tried to upload the bootloader, I encountered an error. I decided to try again, but now when I try to connect to my board, I get the error "Cannot connect to target!"
Do you have any ideas on what I can do next or try?
Thanks.
Additionally, I have attached a photo showing my successful first-time connection to the board.
@EugenGavrisciuc Did you try "Connect Under Reset"? Also, are you using original ST-Link or Chinese clone? There have been problems with Chinese clones. You can also use ST-Link from any Nucleo64 or Nucleo144 board.
@EugenGavrisciuc Did you try "Connect Under Reset"? Also, are you using original ST-Link or Chinese clone? There have been problems with Chinese clones. You can also use ST-Link from any Nucleo64 or Nucleo144 board.
It's a CN version of ST-Link. The fact that for the first time, it was a connection, but then it stopped working. Also, "Connect Under Reset" didn't help. I got another error from this mode.
@EugenGavrisciuc Try original. Chinese copies are faulty.
@EugenGavrisciuc Try original. Chinese copies are faulty.
Hi. I bought another ST-LINK/V2 programmer. Then, I downloaded the SKR-MINI-E3-V2.0 bootloader and firmware hex file and uploaded it. It says that the programming process was successfully done, but after showing the result in the console, it automatically disconnects the device. I can still connect to the board via the programmer, but when I try to connect the board via USB, I get 'Unknown USB Device (Device Descriptor Request Failed).'"
Description
USB initially not working when debugger is connected, after some time, USB module dies. Not sure if MCU got fried or some components. I think that bad HW design lead to this.
Steps to reproduce
What is the problem?
I think the problem is there is MOSFET connecting SWCLK pin and USB D+ pin. So the clock is always opening and closing MOSFET while debugging.
After USB stopped working, I did some HW debugging: