I have a strange problem with some Connect ME 9210 modules and want to hear if someone else has experienced a similar problem.
The modules boot normally and I am able to load an updated bootloader (rom.bin) to the modules.
After this the modules are still working and can be found on the dynamic address (auto). I can logon using ftp and also using the netosprog application will load the real application (image.bin).
The strange thing is that it does not react on the received image.bin file. Normally the modules will program the application to flash and then restart.
Nothing happens after image.bin is successfully transferred. Both netosprog and manual ftp transfer reports a successful transfer of the image.bin.
I know nothing is wrong with either my rom.bin or my image.bin since a large number of other modules has been loaded successfully with the save files and using the same procedure.
I have of course retried several times and also loaded other modules in between the retries. But still these modules do not accept the image.bin file.
I have tried to use telnet trace but I do not see anything helpful. Can anyone recognize this problem?
Ad 1) It is some time ago, but as I remember it was some initialization of I/O that required a new BSP. There was a problem with SPI in the one that comes in the modules. It is a comy of the included with just a few changes.
Ad 2) I have not tried another; since the one I am using have been working in 400 other modules. But I will do that…
Ad 3) I have never been able to find any description of this emergency recovery. Can you give me a hint? If it was included in the shipped BSP source, I think it is still there.
/Thomas
- Yes its with the shipped image by default.
You should take a look at the below pages.
Digi ESP for NET+OS User Guide > Reference > NET+OS 7.5 API Reference > Hardware/Board Support > Bootloader > Functions > customizeIsImageDownloadForced
Digi ESP for NET+OS User Guide > Reference > NET+OS 7.5 API Reference > Hardware/Board Support > Bootloader > Functions > customizeIsBackupRecoveryImageForced
Digi ESP for NET+OS User Guide > Reference > NET+OS 7.5 API Reference > Hardware/Board Support > Bootloader > Overview.
Check GPIO9 and GPIO13
The bootloader code checks the state of these two GPIO lines to determine whether to perform a forced recovery. When both GPIO9 and GPIO13 are set to 1, no forced recovery is performed. When both GPIO9 and GPIO13 are set to 0, a forced image download recovery is performed. When GPIO9 is set to 0 and GPIO13 is set to 1, a forced execution of the backup recovery image is performed.
So here i suspect either of these two is happening.
The key is that you need a FULL DHCP server on your network. You need to set several DHCP properties that a gateway/router will not have. I personally have used a Windows Server DHCP and Linux DHCP.
If the image is bad (IE, bad checksum) then the module will automatically go out on the network, find the DHCP server, and download the address of the network’s TFTP server and the name of the image file on that TFTP server, then automatically update itself.
If the image is good but just doesn’t work, you can trigger this update by toggling a few of the pins.
-Erik
HI there
For me ,i usually load the image using this code:
namespace RE__Test
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
string fileName = "c:/Sample.png";
REImage reImage = REFile.OpenImageFile(fileName);
REFile.SaveImageFile(reImage, "c:/reimage.png", new PNGEncoder());
}
It supports to load image directly.You can also add an image processing program.Most of them offer a free trial package for new users.You can have a try.
Here is another way to recover the unit if you do not have a DHCP server on your network, go to the bottom of this document where it explains serial recovery.
http://www.digi.com/support/kbase/kbaseresultdetl?id=843