Mana SE led D4 blinking [Solved]

[nehal]

I upgraded to Mana SE board for better pwm control. I hardly experimented on few images and after that the board stopped working. It's led D4. It's solid when working normally. Now it just blinks continuously after connecting to power. Nothing happens. I contacted banggood for this issue. Has anyone encountered similar issue with Mana SE?
----
Solution that worked for me:
Please go through thread if you have similar issue. Removing 16V capacitor worked. I will replace it though.

[Stonemull]

google found this thread here http://benboxlaser.us/index.php?topic=2022.0

I don't think anyone has ever bothered to find out what D4 is connected to, if you trace it back to see where it connects it would help.

If it is a power led then you have a supply issue, if it is a bootloader LED then you may need a firmware reload or the micro is rebooting continuously,

[Zax]

I think it's corrupt, you'll need to reload it and that probably means via the ICSP but you could try flashing it via software first.

If you don't have a clue what I'm talking about, get a new Nano (or Mana SE board) and replace it.

FYI: I use an Uno as a programmer but you can buy dedicated AVR programmer for a few bucks.

[nehal]

I have tried to reload the firmware through T2. It was successful, without any errors. But the issue remains. Also not a power supply issue. Tried with L7 board.

[Zax]

Flash it with a different firmware, say 0.9g (the J-Tech firmware) and then go back to 1.1e. That may work.

[Stonemull]

Perhaps re-upload the grbl parameters too, maybe the eeprom values are out of whack, they do not get erased with a reprogram.

I have crashed grbl quite a few times now.

laser control mode .. reset grbl parameters or send default parameters (I am not sure what the difference is .. Zax ?)

[Zax]

Send Default Parameters uploads the $ values to Grbl 0.8 and above.

Reset Grbl Parameters is used with firmware I have compiled and sends $RST=$ which returns everything back to my defaults (same as above but much more efficient).

You didn't ask, but Clear Grbl Positions sends $RST=# which clears all stored offsets (that you get if you home machine without home switches).

[nehal]

I will try your suggestions, zax and stonemull. I am out of town for few days. I will post when I get back.

[Stonemull]

I did find there are things that can corrupt the eeprom values, running too fast.
That sounds like they are not doing a good job of handling interrupts, typically if modifing an eeprom value you should halt interrupts for the duration, not doing so can cause this type of issue.
However that only happens if you write eeprom, I have no idea why grbl would be doing that during a run, so I suspect the problem is at too fast a setting, grbl is being ibterrupted during an interrupt process and ens up with a stack overflow, this could do anything and also reboot the device.
So definately worth checking eeprom values if experiencing eratic behavior, if you even can, depending on when interrupts are enabled you may not eben be able to get it to run.. continuous rebooting.

https://github.com/gnea/grbl/issues/142

[nehal]

I have tried the suggestions. Flashed firmware to older version, then flashed again to latest. Took nano out and replaced with the one from L7 board. The problem remains same. I think it's hardware related.

[Stonemull]

you do not need the mana nano plugged into the board to test it, the usb will power it and grbl will run with the nano sitting on the end of a usb cable, give that a go.

[nehal]

Right. Tried that too. No difference. Tried with the nano that came with L7 board. So I think no problem with nano.

[nehal]

Came across this thread.
http://forum.eleksmaker.com/topic/89/resolved-everything-stopped-working-blue-power-light-flashing-video
So, may be 16v capacitor is the problem?

[Stonemull]

if the nano is not plugged into the board then it is unlikely a faulty cap on another piece of unpowered hardware is the issue

[nehal]

No, not while unplugged. But while nano is plugged and powered on.