2016-12-18 06:11 AM
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?
2016-12-19 02:36 AM
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.
2016-12-19 02:49 AM
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 ...).
2016-12-19 03:37 AM
... 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 ...
2016-12-19 04:10 AM
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).
2016-12-19 04:20 AM
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!
2016-12-19 04:23 AM
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
2016-12-19 04:23 AM
One of the security modes permanently disables the JTAG/SWD interface.
2016-12-19 07:47 AM
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.
2016-12-19 08:32 AM
'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.