How to revive a dead MCU in-circuit?

[Mark Williamson]

Posted on December 18, 2016 at 15:11

Hello all!  How's this for my very first question

I purchased a 3d Printer on clearance with a tag that says Does not Start up.  No warranty.  I was ok with that.  As I'm a developer and a hardware hacker I knew I was buying a project not a printer.  I have experience with Atmel, wrote my own firmware for a Cricut cutting machine, so I'm comfortable here.

The situation I believe is that the store had upgraded the firmware on this machine but used the wrong firmware.  There is much discussion about this situation on the internet from this particular brand of printers. Overall, the quality of the printer is great.  So now the problem.

The images show that the MCU is an STM32F407ZTG6.  I can see clearly that it has SWD header yay.  So I connected the STLink board from my Nucleo to it, removing the jumpers so that I can use it to program an external device, connected the 3.3v power pad on the 3D Printer's board to the 3v3 header on the Nucleo, and I can tell the board has power.  However, STLink does not see the target.  Anyone have some ideas to help revive this guy?

[Jaroslav BECKA]

Posted on December 19, 2016 at 11:36

Hello Mark,

the best way to verify the connection is to use the ST-Link Utility tool.

If the target is not visible it could mean that the microcontroller is in low-power mode or the PA13 and PA14 pins were

reconfigured from their default configuration (alternate function - SWD debug pins).

Try to enable the 'connect under reset' option either in the ST-Link Utility or in your IDE.

This usually helps to solve such issues.

[Steven Valsesia]

Posted on March 17, 2017 at 13:30

'connect under reset' saved our lifes! Thanks!!

[AvaTar]

Posted on December 19, 2016 at 11:49

For a device like this (the printer, I mean) I would expect most/all debugging obstacles to be enabled. In this case, the ROP feature (readout protection, including JTAG disable).

This might require a mass erase, or even be 'unfixable' (if I remember the max. ROP level correctly ...).

[waclawek.jan]

Posted on December 19, 2016 at 12:23

I'd start with connect under reset (you need to have NRST connected to STLINK too, for this to work) as Jaroslav suggested above, but would not have high expectations. Not only could the chip be locked to Level2 as AvaTar which as said above is basically a 'can't connect', it could also be quite well rock dead - you bought it as 'does not start up', remember?

It is not impossible to exchange the chip for a fresh one of course.

JW

[AvaTar]

Posted on December 19, 2016 at 12:37

... it could also be quite well rock dead - you bought it as 'does not start up', remember?

Correct. The absence of the 3.3V power supply at the MCU would be a clear indication of that.

Presence of the same, OTOH, would not mean much ...

[Kraal]

Posted on December 19, 2016 at 13:10

Hi and welcome to the forum !

connected the 3.3v power pad on the 3D Printer's board to the 3v3 header on the Nucleo, and I can tell the board has power

I don't understand what you mean here, i.e. are you powering the printer 3V3 with the nucleo 3V3, or are you trying to sense the target voltage with the ST-Link section of the nucleo ? If the later, be aware that the Nucleo ST-Link can only sense the nucleo 3V3. If you want to be able to sense the external target voltage, you'll have to fiddle with R9 and R23 (if it is a Nucleo64).

[Seb]

Posted on December 19, 2016 at 13:20

First is to know if the MCU on the application is electrically ok. Use an oscilloscope to check all supply voltages, reset line, boot pin, if using external oscillator that it is running, etc... before desoldering and resoldering a new part. Good luck!

[Tesla DeLorean]

Posted on December 19, 2016 at 13:23

One of the security modes permanently disables the JTAG/SWD interface.

[shingadaddy]

Posted on December 19, 2016 at 16:47

Adding to clive1's well soaked wet blanket here, If you can communicate with it, What would you try and PUT IN IT?

:)

You can check things around it first but if its dead it might not let things function on it that normally would. Oscillators for example.

I didn't look so I have no idea but - If it has legs, just cut it off (Exacto) and clean up the pads. Get out your flux and a good clean tip and have at it.

If It has balls, good luck with that. 

[Mark Williamson]

Posted on December 19, 2016 at 17:22

One part of me suspected the disabling of the SWD interface, but the other says why would they put a header on the board clearly marked as SWD if they disabled it...

Here is what I have thus far:

Connected STLink board from the NucleoF411 to the printer's motherboard.

VDD, SWCLK, SWIO, GND  > STM32F407 pins. Remove jumpers on STLink to indicate external target.

There is a pad labeled 3v3 on the target board. Connected that to 3v3 out from nucleo.

Powered STLink board from USB port

Attempt connection from STLINK, no go.  At this point STLink goes legs up and have to remove USB and reconnect.  Attempted connect under reset , same result.

I ordered a new chip from Mouser.  Looks like USPS ate it.  Have to get another

:(

I'm seriously considering just getting the ST 3d printer board   Since this printer is all closed source anyway..

[Tesla DeLorean]

Posted on December 19, 2016 at 17:28

You shouldn't need to connect VDD, especially if they differ (ie 3V vs 3.3V), the stand-alone ST-LINK pod needs a Target Voltage for it's buffers, the one on the NUCLEO/DISCO board lacks those, and connects directly to the CPU.

Other thoughts would be to see if the chip is alive, and if the System Loader works. Pulling BOOT0 high might permit connectivity via the DFU mode (comes up on the PC as an STM32 DFU device), or connectivity via USART1, or perhaps USART3, where an 0x7F byte sent at 9600 8E1 (Even Parity) should respond with an 0x79 byte. On the power side one could look at the state of the NRST pin and for 1.25V on the VCAP1/VCAP2 pins.

[shingadaddy]

Posted on December 19, 2016 at 17:32

'One part of me suspected the disabling of the SWD interface, but the other says why would they put a header on the board clearly marked as SWD if they disabled it...'

Seems a little odd to me too being it's a PRINTER and one might suspect a BUNCH of them in the production flow.

Maybe not enough though , where the option of getting them pre-nailed with the binary code before assembly didn't pan out. Must have some individual (or more I guess) manually programming every one! Or just watching a machine do it.

[Tesla DeLorean]

Posted on December 19, 2016 at 17:45

Well the developers tend to like debugging on complete/functional hardware, and production could use it for boundary scan and programming. Locking the chip down makes sense for a lot of commercial reasons, and is something the firmware can enable.

Per RM0090

• Level 2: debug/chip read protection disabled

The read protection Level 2 is activated by writing 0xCC to the RDP option byte. When

the read protection Level 2 is set:

– All protections provided by Level 1 are active.

– Booting from RAM or system memory bootloader is no more allowed.

– JTAG, SWV (single-wire viewer), ETM, and boundary scan are disabled.

– User option bytes can no longer be changed.

– When booting from Flash memory, accesses (read, erase and program) to Flash

memory and backup SRAM from user code are allowed.

Memory read protection Level 2 is an irreversible operation. When Level 2 is activated,

the level of protection cannot be decreased to Level 0 or Level 1.

[Mark Williamson]

Posted on December 19, 2016 at 20:14

A bit like the Fuse bits in Atmel 8 bit mcus. 

[shingadaddy]

Posted on December 19, 2016 at 20:09

Yes if the word 'production' has any REAL meaning behind it, most real production shops would know these safeguards and employ them. And then standing behind the 'developer'   -   there's the 'bean counter' that makes you take off all the unnecessary *hardware* to save a penny per unit. But here IS a CONNECTOR!  THIS subject- I suspect maybe the 3D printer here is pretty wet behind the ears and 'Production' might have been a first run of JUST enough run to call - 'PRODUCTION'   Kind of why I said- - Just cut it off.   :-).

Not that I approve but, some of my production runs start with - ' Oh look that worked.... SHIP IT! '

Oh how nice it would be to have time to play.

[dale]

Posted on December 19, 2016 at 23:21

Mark,

I did the exact same thing as you.  I mean the *exact* same thing.  I bought the same printer as an 'open box, no warranty, no return' item for about half price.  The difference is that my printer booted up but had a runaway extruder heater circuit.  I swapped out the shorted MOSFET and everything was good to go.

I'm actually printing out a case for my STM32F072-Discovery board right now, or I'd flip the printer on its end and have a go at it.  I traced the SWCLK/SWDIO pins to the the external connector board, but didn't even notice the 3 pin connector right by the chip.  Thanks for pointing that one out to me!

Do you get any joy at all when you power on the printer?  Does the LCD light up?  Does it play the little song?  Anything?

Another thing that might prove useful:  The 'built-in' SD card has a subdirectory called 'sys' that contains a file called 'dreamer.bin'.  It does *not* look like a proper binary image to me (first vector does not look like a stack pointer address, etc.) so it might be encrypted in some manner.  I can send you mine if you think it might help.  I have not even thought about 'upgrading' the firmware on this printer.  This is no Arduino.  

:)

Good luck with your resurrection.  The printer is worth fixing.  Even if you have to buy a new main-board (~$80-$90, depending on source).

[Mark Williamson]

Posted on December 20, 2016 at 01:22

All the led's come on the board and the driver board   But no chirp from windows.  What's your revision code on the mainboard?

[dale]

Posted on December 20, 2016 at 01:29

It appears to be the same as yours FlashForge CoreBoard REV J.  See attached photo.