ftp and burn rom.bin; then what to do?

Embedded Devices NET+OS
1

Hi,

I am a novice.

I have this type-C digi connect me(part no: 50000878-03) without the JTag.

  • I plug it into my development board and the terminal showed the “RAM based FTP Server ready”.

  • I saw on the terminal the version of the NET+WORK Version was 6.0; thus I try to upgrade the firmware to NET+WORK Version 6.3 (which come with my development board).

  • I follow the step4 on “NET+Works with GNU Tools Programmer’s Guide” page 75 to 76 and burn the “rom.bin” at “Digi Connect Customization Kit\factory_defaults\Connect_ME”.

  • The terminal show
    FTP: Flash download complete.
    Resetting system in 10 seconds

  • but then nothing happened. I wait about 30 seconds then decided to turn power off and on.

  • Well, nothing ever show on the terminal. What should I do ? :frowning:

Can someone tell me how to recover this digi connect me without jtag?

Henri

2

Hi Cameron!

First, I think the DCME is the smartest solution available in that kind. We used already over 100 units and the number will increas quite quickly. But to be honest, the picture I have gets a bit cloudy…

I have so far the same situation with one of my modules as henrichen. Due to some reason we got for one batch -C instead of -S modules. To be more precise, out board maker got them and soldered them to our boards. The last batch of 50 pieces now had to be converted from -C to -S which was so far successful. On one module I did the same mistake as henrichen… :frowning:

In general I would like to know if the module is really dead and the flash has to be changed physically. I cannot beleive that! How is the production of such a module done? As I am a hardware engineer who has developed many flash based embedded systems already, there is ALWAYS a possibility to do a initial software download to such a device when there is nothing on it at all or the software gets corrupt by any reason. I do not really think, that the manufacturer preloads the flash before assembling.

How is this in case of the DCME? There are the pins 17 to 20 or even others. Is there a possibility to recover the flash contents or not. Can you tell us some more details on the usage of the pins?

Ok, maybe I ask you for some confidential information but in my opinion, knowledge of this does not change the procuct’s capabilities, but even increases the attractiveness of it.

That would be a great help!

Thanks in advance,

Bernhard

3

BTW, the rom.bin is the file 82000867_A.bin that I renamed it to be used by the ftp server.

henri

4

Hello Henri,

It is unfortunate that I must inform you that this module is dead and is not recoverable by yourself. The only way to recover this module would be to physically replace the flash part.

The rom.bin that you downloaded, which I assume was produced within the application space is not a boot loader image but rather is a version of the application image which is meant to be stored in and executed directly from flash. The standard operating mode of a NET+OS application is to store the image in flash (ROM) but copy and execute it from RAM.

Can you provide me with the specific regarding the document you are referring to? I assume that you are looking at one of our PDF documents, right? Look at the very last page of that document and give me the part number and revision letter printed below the UDC code.

I will have to have someone review this document for errors and get it corrected.

In NET+OS 6.3 the boot loader file (rom.bin) is built during the BSP make process and is created in the src/bsp/platforms/$(PLATFORM)/ directory. Within the application space, i.e. src/apps/template/32b/, when you buld an application two .bin files are produced, rom.bin and image.bin. the image.bin file is your application image and is the file you should be programming into the flash of the target device.

To avoid the possibility of this confusion in the future I suggest that you edit your applciation’s makefile and change the variable BUILD_ROM_IMAGE from the default value of 1 to a 0. This will stop the make process from makeing this ROM only applciation image.

If you have need for further assistance on regarding this issue please contact support directly either by phone +1 952 9213456 or via our online support request form at http://www.digi.com/support/eservice/eservicelogin.jsp.

Cameron

5

Hi Cameron,

Thanks for the reply.

The document part number: PN:(1P) 90000725 A
I refer the section “Restoring the contents of flash ROM” at chapter 5 “Troubleshooting”.

The rom.bin is actually the POST firmware that came with the Digi Connect Customization Kit. That is, the file 82000867_A.bin inside directory \Digi Connect Customization Kit\factory_defaults\Connect_ME

I thought I could burn the customization kit firmware into this new type-c connect-me this way. Looks I made a wrong assumption.

Just one more question reguarding my application: If I changed the bsp.h for my application, would that change be included in the image.bin? I assume the program flow would be as following:

  1. The bootloader checks whether there exists an image.bin?
  2. Yes, copy it to ram and run it.
  3. No, start the Ram ftp server.

Is that correct?

sincerely yours,

Henri Chen

6

Hi Cameron!

I think you have overlooked on my post. Please can you check it?

Thanks in advance!

Best regards,

Bernhard

7

Hi everyone,
I would also be very interested in that information, it could save us some money…

I had that problem, too, for several times, but luckily in most cases with a jtag module, so it could be revived. (well, one module was not and so it was lost)

It seems, that after uploading any of the *rom files and closing the ftp session you have to wait quite a long time (up to a minute) until the module has finished its internal flash-writing and reboot. If I cut off the power earlier, the writing into to flash seems not to be finished -> module gone. On one occasion, the module already answered to a ping but after a power cut off it was dead.

How long do I have to wait after ftp-bye? And what to do if I have not waited long enough? :slight_smile:

Thanks & best regards,
ADent

8

Hello Bernhard,

We are always happy to hear from a happy customer. We are also happy to hear from un-happy customer, of course, as a customer with a problem or question is what keeps us employed. The day does run better, however, when the stress-factor is low.

I have not overlooked your post. This forum is not intended to be a mechanism for accessing Digi support services; it’s intent is for other persons using Digi products to help each other. While the support staff do, on occasion, read and respond posts, this is not a guarantee; re: the message at the top of the following page: http://www.digi.com/support/forum/.

If you are in need for support services you should contact us directly either by phone, +1 (952) 912-3456, or via the online support request form, http://www.digi.com/support/eservice/eservicelogin.jsp.

Regarding this thread and your post, in particular…

Pin 17-19 are reserved for Digi manufacturing purposes, and as such are intentionally left undefined within the documentation. I can assure you, however, that these pins do NOT provide any mechanism by which one would be able to program/reprogram the unit’s flash.

Quite honestly your post does not provided enough information for me to determine if the units could be recovered by any means short of an RMA.

Please contact support by one of the above indicates mechanisms and a member of our support staff can begin working your issue, in-depth.

Cameron

9

Hi Bernhard,

The DIGI support sent me some month ago this exemple of “rom.bin” that I load by default in every of my DIGI Connect. After download, it allow you to launch a little serial menu when you set the /RESET pin at start-up. This menu propose to recover the firmware (“image.bin”) via TFTP.

It is very usefull, because sometimes your DIGI is faulty (bugged programm, wrong image in flash) and there is no way to recover it. I recommand you to see it (but I am afraid it is for NET0S 6.0: it need to be ported to NETOS 6.3).

Moreover I use a second PIN at the start of my main programm to launch the FTP server and to restore all the default parameters : usefull if you lost the IP parameters, or if some wrong param prevent the device to work well.

Paul