I’ve got a problem with a Connect ME -c module.

I can’t discover it with the Device discover tool in my ESP.
I’ve notice that my module has the green and yellow LED alway ON.

I try to reset it using the pin 20 to ground, but the module still can’t be discover.

I wonder what does it mean when the 2 LED are ON ?

Thanks for your help

Device discovery won’t find a -C ME. Nor will grounding pin 20 reset it back to factory defaults. It sounds like you’ve been working with -S MEs and switched to a -C.

what are you trying to do?

I’ve done an application on a Connect ME -C JTAG module using a development board. The application is working fine.

Then, I’ve tried to load my application in 2 modules Connect ME -C using NetOsprog
1 module is working fine. But the other module doesn’t work. I can’t discover it and when I power the module , the LEDs (green and yellow) are permantly ON.

I’ve tried to reset it with pin 20 but nothing append. Maybe the module is just broken !

Put it into your development board. Ground both 18 and 20 (check your dev board for the right jumpers), and see if you get a prompt at 9600N81 out of the serial port. Should say something like “Starting TFTP Recovery”. If you have a DHCP/TFTP server such as TFTPD32 you can set it up to flash a good image (sometimes difficult to set up, but fast once working), or you can just wait and it will switch to serial recovery, and you’ll see a string of ‘C’ characters. Use your terminal program (TeraTerm is a good one) to send it the image.bin file using XModem. This is slow, but easier to do than set up TFTP.

I’ve tried what you said, but couldn’t load the image.bin.
I used Teraterm, when the ‘C’ char starts, I try to transfert with XMODEM but it stays on the first packet and doesn’t load…

Since you aren’t using a -S or a 9210 ME daworm’s idea won’t work. Sorry, but your ME is bricked. I have piles of them like that. This is often caused by:

  1. Defining serial port 2 on the JTAG and not shutting it off before loading it on a non-JTAG module (pre NetOS 7.x).
  2. Not waiting for the program to write completely before rebooting the module (most common). After NetOSProg finishes, always wait for the reboot. It takes anywhere from 5 seconds to 15 minutes, depending on the ME’s mood. (I know that sounds funny, but it is true.)
  3. Assuming something is present in the file system when it isn’t. I once had the program looking for a file that I had loaded manually and it locked up without it.
  4. Static charge. A static shock, especially during programming, really messes up the ME’s memory.

Of course the common programming mistakes are possible too. Like infinate loops.

If it is a glitch after boot, one thing you can do is set the ME to return after an error, since most errors are simple stack crashes and the like that usually don’t effect long term operation. There used to be a blink code when an ME crashed, but that hasn’t worked properly since NetOS 6.x.