flash me9210 timeout

Embedded Devices Linux
,
1

Recent deliveries of the ME9210 cannot be flashed using DigiEL 5.7.2 or any earlier version. It always reports ‘Timeout’ This has been raised before, but is unresolved. The installed Linux is 2.6.35.14-del-5.7.0.

Tracing the packets, the flash image is transferred using ftp ‘STOR’ to /tmp/ and is received OK. ftp quits and telnet starts but 100ms later exits without performing any action to write the uploaded file. This appears to be a premature exit since closing the flash dialog also issues an exit command.

If you manually telnet to the ME9210, the uploaded image can be seen. However, the system is very unresponsive. any command such as ls, top, or ps takes several seconds to respond. It remains unresponsive until rebooted.

If I kill the dropbear, syslogd and httpd before attempting the flash update, the telnet gets further than a simple ‘exit’ It appears to argue about echo, go ahead and window size, and then exits. It still does not allow the flash to update.

Notably - the timeout parameter has no effect, since the timeout message appears as a result of the telnet session exiting.

All this has been tested on a clean install of DigiESP 5.7.0 DVD updated to 5.7.2.

2

what images are you running off? stock images? Are you able to update via u-boot/tftp?
if you reboot and then telnet or ssh, is shell responsive?

3

Unfortunately, the answers and questions raised have not resolved the problem. Out local distributor Solid Sate Supplies has been unable to assist

Just to answer your question about responsiveness, yes,after the timeout message, telnet into a shell is very slow to respond. Rebooting restores a normal response. Perhaps the problem is with the vsftpd on the module which is obviously still running but perhaps is causing the problem. I will try killing this process. telnet could also be responsible, and since these are both part of the rootfs, rather than the kernel, they presumably may have been changed much later than the kernel date/time stamp. Also rootfs changes are much more ‘manual’ so it is easy to break something. I believe the rootfs uses prebuilt binaries, unlike the kernel.

Put simply - take a new clean install of version 5.7.0 Digi ESP. accept the package manager updates to 5.7.1 and then 5.7.2 as you previously said was necessary.

Create a Uboot/kernel/rootfs project and just accept the defaults. Configure the NFS/TFTPBOOT directories. Install the resultant image and then try to flash using the GUI. It fails after downloading the image with a timeout message. However, it will dboot from this tftp image.

After the kernel file has ftp downloaded to the /tmp direcory, it is possible to telnet into the module and run the flash_update filename partition succesfully. The module will then boot this from flash. The problem is therefore with the GUI section of the IDE, which is presumably invoking the same software, but the module is not responding as expected.

I have provided a lot of detail. Everything is stock, with no attempt to change parameters. It is clear that after the ftp download, the module is in a state where it responds so slowly that the GUI application times out.

I was prepared to buy a complete new development board and install it onto a virgin PC to repeat the test, but no hardware was available - since the JumpStart kit appears to be EOL. I also suspect that the JTAG version supplied with the baJumpstart kit may have a different version of Linux loaded.

Since manually running flash_update allows us to continue to use the module, we can proceed, but I am unhappy that the loaded version of Linux has been changed, obviously without proper testing with the ESP. This change appears to have taken place some time in 2014.

I provided details of the serial numbers of units which would flash, and those which wouldn’t, but Solid State Supplies could not reconcile these with changes made by Digi.

I suspect these changes are to do with ‘Discovery’ and iDigi but this does not apply to the Digi ESP which does not use windows. I was asked to run the discovery application, but this request indicates the unfamiliarity with the Digi ESP system that our local distributor has.

Hope this helps to resolve the problem
John Newell

4

nobody else have reported this problem. I am using this module with DEL 5.7.2 myself and i am able to update flash.
You can reflash module with JTAG using images generated by DEL 5.7.2 and see if you can reproduce the issue.

5

The module is a production module without JTAG. The problem is serial number dependent, so you may be able to flash a unit with your system and a particular module. What about sending me a module that you can flash - or I can send you one that does not flash. You can then try it, and if it flashes, then the problem is firmly in our court. If not, then you can investigate why not.
John

6

sure, please open an RMA request with S/N of the module and mention my name in the case by sending email to Tech.Support@digi.com

7

Solid State Supplies are now looking into this and have a unit which if they cannot flash they will return to you. If they can flash ( via the ESP GUI, not from U-Boot), then I will try to identify what the differences are between their system and mine.

Repeated testing confirms that connecting to the wsftp server from any ftp client leaves the unit in a very unresponsive state. The command ‘time ps’ which should execute in less than a second has been observed to take 32 seconds!
John