rusefi.com

Hello all,

As the title says, I pulled a derp.

I downloaded the F7 bundle by accident off the build server (inattentive, didn't catch it), and did an auto DFU with the included console application over USB.
No connectivity on USB anymore.
The ECU was communicating fine with tuner studio before this, so I know where I went wrong.

The processors are different between the revisions, so I'm rather surprised that the DFU went through at all.

I have an STX-RLINK programmer, but it's not detecting the processor in rflasher7. Admittedly I haven't used any STM32 stuff before this.

Did I by chance cause an actual hard-brick that I won't be able to get out of?
Worst case I can replace the processor, but I'm hoping I can avoid the SMD rework.

I have an st-link V2 dongle with the alternate 10 pin connector pinout on order, scheduled for Saturday delivery.

This is going into a 79 TR7 with a set of Yamaha YZF R1 drive-by-wire throttlebodies, since the SU carbs currently on it are totally knackered.

Quite embarrassed that this is the first post, but that seems to be 2020 in a nutshell.

Thanks in advance for any and all help.

Welcome to rusEFI! Sounds like we will get this resolved one way or another

Can you power your microRusEFI while holding "program" button? Would it appear as "DFU device" in Device Manager? Would you be able to use "manual DFU" option in console once your MRE is in DFU mode?

See also https://github.com/rusefi/rusefi/wiki/HOWTO_DFU

As Andrey mentioned, you should be able to recover if you connect USB while holding the button on the ECU. That will put you in the same DFU mode that we do automatically from software during a firmware update.

300d50 wrote: ↑

Wed May 06, 2020 2:40 am

The processors are different between the revisions, so I'm rather surprised that the DFU went through at all.

The F4 and F7 are actually largely the same - most of the peripherals are identical. The only differences are the CPU core itself and bus architecture, which are largely transparent to the software running. Their bootloaders also use the same DFU protocol, so it's unfortunately possible to seamlessly flash the wrong firmware to the MCU.

300d50 wrote: ↑

Wed May 06, 2020 2:40 am

Did I by chance cause an actual hard-brick that I won't be able to get out of?
Worst case I can replace the processor, but I'm hoping I can avoid the SMD rework.

The whole STM32 series is very nearly unbrickable - the DFU bootloader is stored in hard-wired ROM on the device (not flash), so if the bootloader button can be pressed, it will always work.

300d50 wrote: ↑

Wed May 06, 2020 2:40 am

Quite embarrassed that this is the first post, but that seems to be 2020 in a nutshell.

We have life!

I held program down, connected USB, waited for DFU enumeration to show in device manager, then ran manual DFU while holding program.

The 5-ish second enumeration delay in the console made me think I had an issue when I first tried that night.

Most of the other platforms I'm used to (PSoC, PIC, SuperH derivatives, QCom embedded stuff) are NOT happy campers when you overwrite the bootloader code, so I had a slight panic.
The other thing I was worried about was an option bit for crystal frequency or such being tickled the wrong way, been there, dealt with that before.

Thank you both for your help!

I've been following the project since ~2016, and must say, I like how things are turning out.
No DC37 connector is just the icing on the cake.

300d50 wrote: ↑

Thu May 07, 2020 10:58 pm

ran manual DFU while holding program.

once you see it in DFU mode you can let go

300d50 wrote: ↑

Thu May 07, 2020 10:58 pm

Most of the other platforms I'm used to (PSoC, PIC, SuperH derivatives, QCom embedded stuff) are NOT happy campers when you overwrite the bootloader code, so I had a slight panic.

Not possible to overwrite the factory-provided bootloader on the STM32, it's in mask ROM