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?
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.
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. https://www.digi.com/products/embedded-systems/system-on-modules/digiconnectme#partnumbers
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: https://www.digi.com/products/embedded-systems/system-on-modules/digiconnectme9210#partnumbers
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.
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.
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.
>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.
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):
ZR
Start recovery…
TFTP…
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
R12:00427444
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.
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?
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
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:
EXEC_P, HAS_SYMS, D_PAGED
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.