Looking for some details regarding troubleshooting an MCU - I suspect based on the information I’ve found throughout the forums that essentially if the MCU is not responding to an ST-Link connection its pretty much hosed.
If that isn’t the case, I’m more than happy to try anything I can to determine what may be causing my problems here in the first place. Provided the troubleshooting isn’t invasive as I dont plan on doing a direct MCU Swap until after the seller has confirmed that they dont want the broken controller back. But I do want to test as much as I possibly can to try and resolve the problems I’m seeing without having to have the seller send me a new unit.
Problem/scenario:
Pre-Powered the ESC on a Bench PSU (gradually going from 6v to 51v with no issues)
Powered the ESC using my battery (as I expected to do motor detection shortly after FW Flash) current charge was 48.5v
Plugged in ESC to USB and flashed FW from 3.5X (cant remember tbh) to 5.01. This appeared to have worked.
Waited probably 60 seconds to reboot the ESC. After that it wouldn’t connect via USB.
Connected ST Link to it and flashed boot loader for V6 HW. (USB Still fails to connect)
Tried to Program using SWD from a known good (Identical ESC) it couldn’t connect to the MCU.
Retried ST Link It will no longer connect to the MCU.
Checked ST Link on a different controller as a sanity check, and it read the boot loader and firmware with no issues.
updated ST Link Firmware, checked again on the problem ESC, still no dice.
There have been discussions throughout the forums with regards to the MCU causing problems for the Controller (It is the brain after all) such as a short to ground on the 3.3vcc rail. I haven’t tested this yet, but before I go through and setup my bench for further troubleshooting I was wondering if there was a list of things to check before considering lifting the MCU is a viable strategy?
MCU didnt show signs of a short from what I could tell - ST-Link still failed to connect on this one. Got word back from the vendor that they’d be sending out another one because of these issues and that they dont need/want the broken one back.
After getting that message, I decided to move forward with swapping the MCU out with one of my brand new ones. I was able to get the MCU to connect sorta. It will connect then throw a “Unknown Error” and disconnect. It seems that the core gets halted before I can do anything. I got lucky once and was able to push (presumably) some of the firmware for the MCU but i cant say for sure if it worked since it still wont connect over USB, Nor ST-Link, or SWD (VESC to VESC) with any level of reliability. Because of that it leads me to think that maybe the regulator may be the problem?
No clue either way.
Voltage shouldnt have changed to something below 12v since the pack was 48.5v when plugged in, and its a discharge bypass BMS so nothing should have been capable of messing with the v-out.
Manufacturer/Model - I know this may be necessary to know for some closer details but I’m going to leave the Vendor and by extension the finer details of the make/model out of this topic unless they have no desire to remain anonymous, the controllers are presumably made from the same company as MakerX not sure if that’s true or not but its the info I have.
So right know, my problem is that the MCU is unstable and im not getting a connection to persist long enough to program and even if I did, I assume the instability would cause functional issues anyways. Ill try and reflow the MCU again tomorrow and recheck the pads…
Saying that, I think the pad for PC13 fell off, but dont believe that to be an issue since the diagram for the VESC 6 hardware doesnt indicate any use for PC13 and further more, there was no VIA, or trace near the pad. Maybe that has something to do with it, idk.
I found this searching for a similar issue im having with my vesc6 not connecting to usb,vesc-vesc, or st-link for reflashing after it shut off.It is showing option bytes on vesc tool as 0x0000000 if anyone knows what that could mean?
So, I’ve spent another few minutes looking into this further and really without proper testing and troubleshooting equipment I’m probably not going to get much further.
Checking the schematics again I found the pins that should be for Voltage - these pins all read out at 3.3 volts which according to the STM32F405 datasheet the range is 1.8-3.6, so we’re good here. What is unfortunate is that I don’t have and likely will not get an Oscilloscope any time soon as I’d plan to buy one that I’ll likely never have to replace.
I have my money hedged that the Board itself is the problem and not the MCU - the reason I say this is that the MCU appears to be getting stuck at some point and I would be surprised to see both the MCU that came with this unit as well as the one I swapped in were both faulty. One possible thought occurs which is to pick up an ADAFruit STM-Python module which uses the same STM32F405 and yank the firmware off of that, swap the MCU and push the firmware to the “swapped” MCU and see what happens. If that works and the MCU boots with no problems then we have a verdict on the cause. But then its a matter of trying to figure out what on the ESC is causing the problem.
Between then and know I suppose I can check for a short to ground on any of the IO pins especially the boot pins but alas that would be the end of what I can dig up through the datasheet or the schematic for v6 hardware.
As always if anyone passing by has any insights - I’m all ears!
check for shorts first - if ok - > sounds like bad connection, SWD stuff goes directly to the microcontroller, check your solder connections, check wires of the st link. Is your 3,3v circuit working?
In very raw cases you have fucked up traces from the jst pins to the mcu. Dont heat up the mcu to long.
Using the same settings I’m able to pull firmware off of other STM32F405’s.
Checked continuity between the jump cables (direct soldered to the back of the JST port) and PA13, PA14 and VSS(ground). As described by Vedder - if you externally power the MCU, 3.3v is not needed and not suggested.
Checked shorts to ground on the SWD Ports as well - none of them occurred. Checked for shorts to each other, also nothing.
found an in depth datasheet on boot and reboot characteristics of the STM32, ill see if that has any further info, otherwise i may just build a CheapFOCer1 out of the spare parts i have and use that as an STM Tester.