Managed to brick a CM3 during software upload!

[John Westlake]

I seem to have managed to brick a CM3 module while uploaidng software to it - how is this possible?

While I was programming a CM3 module - at about 10% I touched a "doggy" USB hub connector that interrupted the USB connection and the upload failed.

I tried to reload the software but now the module is not seen by the PC, it does not even appear in device manger - how is it possible to brick the module?

This is potentially a very serious issue (as I suspect it will be to other CM3 users) as we plan to offer future OTA software updates to customers - but if the unit can be bricked then this is an extreme concern.

There is nothing in the CM3 manual that suggests this is possible - just that the module should default to boot loader mode:-

"When initially powered on, or after the RUN pin has been held low and then released, the BCM2837
will try to access the primary SD/eMMC interface. It will then look for a file called bootcode.bin on the
primary partition (which must be FAT) to start booting the system. If it cannot access the SD/eMMC
device or the boot code cannot be found, it will fall back to waiting for boot code to be written to it over
USB; in other words, its USB port is in slave mode waiting to accept boot code from a suitable host."

How can we recover this module?

[gsh]

When you first plug it in and run rpiboot, does it just sit at 'Waiting for BCM2835/6/7' or does it get any further?

I assume you are programming on a CMIO board? Are you sure you've got the USB boot jumper in the EN position?

Finally can you try using a high quality USB cable? We've noticed some problems with lower quality cables with the USB in device mode.

Gordon

[John Westlake]

Gordon,

The CM3 is not even seen in the Device Manager - all other CM3's work, only this unit is no visible after interrupting software download to it at about 10%.

So somehow I have managed to Brick a s CM3 - which I though was impossible?

We are very concerned as we need to offer OTA updates to customers units and understood that the CM3 could always be recovered via the bootloader.

Is the Bootloader "hardcoded" into the CPU or can it get "updated" during the software load?

[gsh]

It is impossible to brick it by putting anything on the eMMC since the contents are not read if you've got the uUSB plugged in (and the jumper in the EN position). It is of course possible that the device has been damaged from an ESD or other issue.

Other possibility is that the CMIO board is the problem, but I assume this is not a problem if you switch the CM3 back out.

You didn't answer my questions:

1) When you first plug it in and run rpiboot, does it just sit at 'Waiting for BCM2835/6/7' or does it get any further?
2) I assume you are programming on a CMIO board? Are you sure you've got the USB boot jumper in the EN position?
3) Finally can you try using a high quality USB cable? We've noticed some problems with lower quality cables with the USB in device mode.

Can you plug it into a Raspberry Pi instead of plugging into a PC? Then do lsusb to see if it appears

Gordon