Problems with Initial flash of Hw4:12

I've got the exact same problem ...

When I compile and flash the Firmware in Ubuntu 16.04 it seems to work:

openocd -f board/stm32f4discovery.cfg -c "reset_config trst_only combined" -c "program build/BLDC_4_ChibiOS.elf verify reset exit" # For openocd 0.9
Open On-Chip Debugger 0.9.0 (2018-01-24-01:05)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
trst_only combined trst_push_pull
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.270698
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800c000 msp: 0x20000800
** Programming Started **
auto erase enabled
Info : device id = 0x100f6413
Info : flash size = 1024kbytes
Info : Padding image section 0 with 48704 bytes
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x20000042 msp: 0x20000800
wrote 262144 bytes from file build/BLDC_4_ChibiOS.elf in 7.394640s (34.620 KiB/s)
** Programming Finished **
** Verify Started **
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20000800
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20000800
target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20000800
verified 154784 bytes in 1.583036s (95.485 KiB/s)
** Verified OK **
** Resetting Target **
shutdown command invoked

The only thing that's strange are the "target halted due to breakpoint, current mode: Thread" Parts, where it says "pc: 2000002e" which should be SRAM and not flash anymore. Am I right ?

Is this the problem why the firmware is not flashed maybe ? How can that be fixed ?
 

Any luck with this issue yet?

I also build a VESC from parts, didn't put the FETs on yet (wanted to make sure all is well before nuking ~25 money units worth of FETs ;-) )

- Checked all soldering onder the microscope, no bridges what so ever
- Programing looks fine, bootlader and/or merged firmware.
- Blue LED is on (powered directly or via USB or via drv chip)
- 8MHz oscillator is running
- Uart- TX pin goes high on power up, no data
- USB current draw is about 7mA, D+/D- voltage jump up&down by ~200mV

not working:
- USB not detected by either M$ mor AppleSoft
- No blinking LEDs

UPDATE 2018-05-07

Just managed to fix my issues,

- My red and green LED where the wrongway arround (the dot/marking at the bottom has to go to GND),
- I had to power the VESC from battery, then connect USB. updated the firmware from VESC tool and all was well (programming via SWD succeeded previously)

I might need some help anyway, I build two VESC 4.12 and both behave exactly the same

When powered the red LED is blinking 3 times, with intervals. VESC-tool shows DRV and ABS_OVER_CURRENT fault (when idle,) even without motor connected. I used all the parts as advertised (1mOhm shunt) 
motor calibration does not spin the motors

• All settings default
• Imotor:~8A
• Input voltage: 41v
• measured 5v rail: 5,9v
• measured resistance over the FETs ~32K

when motor connected, fault and current reading stays the same
when I spin the motor by hand the current graph spikes to ~60A

Double and triple check your soldering and parts placement. The 5 V rail should be 5 V (±0.1 V or something like that, I guess) - not 5.9 V.

Also, where did you source your components? If on Ebay, they are likely to be fake and/or broken.

Is there a way to measure if the groundpad is connected correctly (other than observing these kind of faults)

Ouch, even worse, I sourced the DRV from aliexpress , I'll heat up the DRV again but probably end up ordering some DRV's at Farnell.

update: Just replaced the chineese DRVs with proper ones from Farnell, both the VESCs work now

The removed drv8302 chips exposed pad looked like sh*t, no wonder it didn't work

Ok, i got it. thanks

cheap hoverboards

Following!

https://bitly.com/

I am sharing it with everyone.

https://en.gravatar.com/rajesharyaphotography20