Home/Support/Support Forum/Connect ME Plug'n'Play FW configuration
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Connect ME Plug'n'Play FW configuration

0 votes
I have Connect ME DC-ME-01T-C device which I upgraded with latest Plug'n'Play FW POST found on the Digi support pages and called 82000867_H.bin.

Since I'm novice using these devices, I understood after reading user guide, it could be possible to configure these devices e.g. with web browser. However, device doesn't respond on port 80 over HTTP. Only which responds is FTP on port 21. Device discovery SW doesn't find my module. I see in Wireshark analysis how device gets IP address correctly. I'm able to ping it also.

Do I miss something elementary?
Am I only able to configure unit via serial interface?
asked Apr 6, 2020 in Plug N' Play by phy123 New to the Community (6 points)

Please log in or register to answer this question.

1 Answer

0 votes
Best answer
Part#DC-ME-01T-C the C is the version which you use with NET+OS to customize your software. The plugNPlay version of the ConnectME is Part#DC-ME-01T-S.
If the unit is getting an ipaddress but you can't see it with the Discovery tool, is possible that the unit still has the NET+OS in flash. One way of checking is if you put a serial cable on Console port of ConnectME can you see anything come up on the hyperterminal, you have to give it a few minutes. If you were looking for the PlugNPlay I would purchase this Part#DC-ME-01T-S, the PlugNPlay uses ADDP which is what Discovery Tool uses to find units on the network.
answered Apr 6, 2020 by Campbell Veteran of the Digi Community (916 points)
selected May 4, 2020 by phy123
Thanks Campbell. Your support is appreciated.

Now I was able to solder some wires to utilize serial interface of the unit. I see how it reports me back some information and I can modify the settings as a root.

FW is NET+WORKS v6.3 ram-based FTP server application dated 2004. That sounds logical why it only responds to FTP. If I now upload to the unit latest plug'n'play POST FW (82000867_H.bin) over FTP with filename image.bin, I see how the unit restart after that, but then crashes and prints out some register values I assume. Next restart it starts recovery over TFTP which I force to the same FW. I see how FW is transferred in WireShark and tftpd. But the unit will not start.

If I do the same over TFTP for the latest EOS plug'n'play FW (82000856_F7.bin) instead, I got the unit up again to the same FW having only FTP server. And finally I tried even EOS FW with new treck TCPIP stack (82001116_K6.bin), but the unit will not start.

As a summary, with 82000856_F7.bin I get the unit up and running again, but I'm not sure if it is really flashed with that FW. These different FWs have very different file size, where 82000867_H.bin is only 37816 bytes. Can this be enough to hold some e.g. telnet to serial functionality? I read also there is a bootloader (rom.bin?) which can be replaced. Could it be so that latest FW doesn't co-operate with bootloader?

And yes, after playing for a while with this now, part# -S would be most probably easier, but I found these -C units second hand in reasonable price afford to use in ham radio IoT still guessing have good enough performance for that. that's the reason.
DC-ME-01T-C is a customizable module running Netos.
82000867_H.bin is a firmware for DC-ME-01T-S plug and play module. They are different and cannot be converted to each other.

>Next restart it starts recovery over TFTP which I force to the same FW.
Module's firmware is now corrupt as it expects Netos image and instead, you flashed it with something completely different. You need a netos image.bin for your module to recover over TFTP.
Now, to roll back DC-ME-01T-C is a customizable module, that requires software development. I assume this is not what you need. It sounds like you are looking for the plug-and-play module with pre-compiled firmware that you only configure via the web interface.
you are looking for DC-ME4-01T-S (note -S).
Also if you are just starting your development, I would strongly recommend considering DC-ME-Y402-S instead:
Same form factor but newer and faster CPU.
Thanks LeonidM, your comment clearly clarifies for me the differences. I had understood there is different FWs and thought maybe those are compatible from HW point of view, which isn't the case then.
Yes, -S would have been easier for me because it seems that my hobby project starts swelling with -C module. On the other hand, I should have full flexibility with -C module and netos. Performance will not be critical in my application, just few measurement values every now and then.
you should start with -S module and see if it can fit your purpose. If not then go with -C.
unfortunately -C module cannot be converted to -S
Thanks LeonidM,
To develop SW for -C module, do you know if I need development kit for that? With other words, is the inc-files, compiler and linker only shipped with dev kit. I found some sample application source on the support page, but nothing yet how to compile the source code.
thanks. I bought one, compiled net+os 7.5 ssh sample project, uploaded the FW to my net+os 6.x device. I think I got all the parameters correctly set...Now the device responds over serial line just ZR when booting up, then nothing more happens. I didn't find what does this mean.
Are you running a netos sample app on a module with JTAG using a development kit? If not please do that first and see if it works for you.
unfortunately I'm not able to do debug with JTAG. My ME device is without JTAG. dev kit was shipped with JTAG ME9210 but kit itself was missing JTAG interface due to I found it second hand. on the other hand I have quite many ME device without JTAG. I would just need to understand if they are recoverable. or I need to find a JTAG interface supported by DigiESP.
Recovery instructions are here:
Not sure if your version of the bootloader supports it.

>thanks. I bought one, compiled net+os 7.5 ssh sample project, uploaded the FW to my net+os 6.x device. I think I got all the parameters correctly set...

How exactly did you program? What did you change in the app? What do you mean by "all the parameters correctly set"?
I would start with Netos FTP server app. Also build in release mode and program rom.bin so you have the latest bootloader.
Thanks LeonidM trying help me out with this.

Yes, I have seen those creeping CCCs before so at least module had a working bootloader once upon a time.

If pins 18 and 20 are not grounded I get ZR, nothing more. If I ground these pins, I get message below (you see also the ZR from previous boot when pins where not grounded):

Start recovery...

Abort Exception

Link Register :00211654
Stack Pointer :04485BE8
Current program status Register :200000D7
Program Counter :00000000
R00:4E393939    R01:00000000
R02:4E393939    R03:00224E84
R04:00000000    R05:0042744C
R06:00000000    R07:00427444
R08:00000000    R09:00225288
R10:00224E7C    R11:00488B78

Abort exception happens immediately and I don't see more activity either ethernet or serial interfaces.

DigiESP new sample project selection opens a wizard where I can set NET+OS version (7.5), HW module type (Connect ME) and debugger type (Software). These are the parameters I mean, sorry for unclarity. I changed to release and build the project without errors. I found in project properties a flash memory map settings where application image size needed to adjust to fit image.bin release. I increased the app image size respectively. I rebuild the project. Then I uploaded over ftp this image.bin. After that the above serial outputs came up.

OK JTAG modules. I would need supported JTAG interface also to connect my PC.
Does it look like bootloader recovery starts than crashes for some reason? Does it happen with and without an Ethernet cable connected?
for JTAG, if you got this kit https://www.digi.com/products/models/dc-me-9210-net
You already have everything you need.
What is your ultimate goal? If you just starting a new development I again strongly advise going with newer and faster:
Yes, that's correct. When boot crashes, the serial output data looks the same with or without ethernet cable connected. Pins 18 and 20 are grounded.

I have got all this stuff second hand and unfortunately I didn't get JTAG debugger. I though it would not be necessary either.

My goal is to learn these devices and make simple headless PoE measurement devices as hobby basis, not commercial. This old module certainly works fine for that.

In DigiESP, when selecting Connect ME in new sample project wizard, I can select software debugger. Is it true if I would have ME JTAG module, I could debug it without JTAG debugger hardware, like via jumpstart kit 2nd serial interface?
1) DC-ME-01T-C is bricked at this point. Please open a support case by sending an email to tech.support@digi.com and provide the MAC address of the module. If it is still under warranty I will authorize an RMA
2) There is no practical way to debug without JTAG
3) I strongly suggest buying this kit https://www.digistore.com/DC_ME_9210_NET_p/dc-me-9210-net.htm
thanks LeonidM.

Because I have the jumpstart kit without JTAG debugger HW, can I complete it with just JTAG debugger HW?

Link to DG-ACC-JLNK on this page is broken https://www.digi.com/support/knowledge-base/what-is-the-part-number-for-the-digi-jtag-link-usb

what I understand that is the JTAG debugger shipped with dc-me-9210-net dev kit.
The kit comes with Segger J-link https://www.segger.com/products/debug-probes/j-link/models/other-j-links/j-link-oem-versions/
But I think if you buy their cheapest debugger today it is twice more expensive then the entire kit.
Again, your best option is to buy the kit.
Thanks LeonidM.

ok, kit I have, but no debugger HW. Is that true I cannot even buy debugger HW as a spare part?

If I compile the FTP server file system sample project according to help in DigiESP and then look into the first lines in image.elf it looks like following independently if I build debug or release configuration

C:\Users\petri\My Documents\Digi_ESP\workspace_75\FTP Server File System Sample\Release\image.elf
architecture: UNKNOWN!, flags 0x00000112:
start address 0x00004000

It looks like suspectable for me that architecture is unknown even when I set in DigiESP new sample project wizard device to Connect ME. Could you confirm if this setting is correct? I would want to make sure this is right before uploading image to module.
>ok, kit I have, but no debugger HW. Is that true I cannot even buy debugger HW as a spare part?
Digi does not sell a JTAG debugger separately as it would violate our agreement with SEGGER
You can buy J-link directly from Segger https://www.segger.com/products/debug-probes/j-link/models/j-link-base/
This one will probably work, but we cannot guarantee it. IT costs $378, while the entire kit from us including the debugger is under $200

Download and use file utility for windows:

C:\Downloads\file-windows-20170108>file image.elf
image.elf: ELF 32-bit MSB executable, ARM, version 1 (ARM), statically linked, not stripped

Thanks LeonidM.
Maybe there is something regarding the kit I don't understand. When I check the content of this kit linked above, https://www.digistore.com/DC_ME_9210_NET_p/dc-me-9210-net.htm, that is the kit I have, I can't see it contains the JTAG debugger. In my kit I have exactly the same content as in that kit. Can you advice again?

Does this kit support newer modules given here above, like dc-me-y401-c and dc-me-y402-c?
Yes, the kit has JTAG debugger and supports new and old modules both ME and ME9210 and also WiME and WiME9210
The info on the page https://www.digistore.com/DC_ME_9210_NET_p/dc-me-9210-net.htm is not correct, by not listing JTAG. They have copied it from a Linux kit. I will have it corrected.
Debugger and ME JTAG module received. Now all works smoothly with ME JTAG module. Thanks LeonidM for your support.
you are welcome! if your question is answered, please click on the check-box button to select the answer and it will mark question a resolved.