ROM_UpdateEMAC, available on TM4C129ENCPDT?

Hello Mike

Yes, you do have a chip that supports Ethernet Boot in ROM. However before using the same I do want to confirm

1. What all defines have you kept in the compilation of the files?

Regards

Amit

Hi Amit:

I have symbol TARGET_IS_TM4C129_RA1 defined in CCS.

-- Mike

I'm using the TI v5.1.6 compiler.

In the CCS General/Main/Device/Variant tab, I have selected Tiva TM4C129ENCPDT.

In the CCS Build/ARM Compiler/Advanced Options/Predefined Symbols I have these:

PART_TM4C129ENCPDT

TARGET_IS_TM4C129_RA1

ccs

TIVAWARE

_INCLUDE_NIMU_CODE

-- Mike

Hello Mike,

That is what I also observed with my Connected LaunchPad... Glad to hear that it is working. It is also great when forum members (other than me) put a full list of steps so that the forum works as a knowledge base for users coming for the first time but with the same issue. Could you add the steps 1-2-3...

Regards

Amit

Hi Amit:

Well, it is "working" in the sense that my firmware is able to call into the ROM routine, but it's not working in general.

I wrote a simple BOOTP responder to return an IP address to the Tiva.

Here's what I do:

a)  On the Tiva, call ROM_UpdateEMAC(clock).

b)  My BOOTP responder is listening to port 67.  It returns a UDP packet containing the new IP address to port 68.

c)  Using Wireshark, I watch the Tiva do step (a) again and again, with increasingly long sleep intervals between BOOTP requests, so apparently the Tiva is discarding my response packet.

I've checked the inbound and outbound packet formats with Wireshark and the BOOTP request packet received from the Tiva is okay.  Also, the BOOTP reply packet I'm sending to the Tiva is formatted properly.

According to TI's documentation, the Tiva should adopt the IP address and then issue requests to a TFTP server, asking for blocks of the firmware image to program into flash.  I think that many BOOTP clients perform another step first, namely using ARP to see whether any other stations are using the new IP address, but I don't see this reflected in TI's documentation.

I'm using the NDK stack before calling the ROM routine.  Is there something else I have to do to get the code to receive my reply packet?

Here's what the code is doing, modeled after what I found with Google:

    HWREG(NVIC_DIS0) = 0xffffffff;

    HWREG(NVIC_DIS1) = 0xffffffff;

    HWREG(NVIC_DIS2) = 0xffffffff;

    HWREG(NVIC_DIS3) = 0xffffffff;

    HWREG(NVIC_DIS4) = 0xffffffff;

   SysTickIntDisable();

   SysTickDisable();

   ROM_UpdateEMAC(ui32SysClock);

If you don't see anything wrong with this scheme, could you forward this e-mail to somebody within the organization who is responsible for the BOOTP functionality?

Thanks -- Mike

Hello Mike,

I would need some more information here like which BOOTP server are you using, Operating System, so that I can recreate the setup.

Regards

Amit

Hi Amit:

I've tried using LMFlash.  This didn't work either.  I saw some documentation about it, saying that it sends magic packets to the Tiva when connecting.  I don't believe the ROM_;UpdateEMAC function is expecting to receive these, as it starts sending BOOTP requests as soon as my code on the Tiva branches to it.

Here's a screen shot of the BOOTP request coming from the Tiva:

And here's the reply coming from our BOOTP server: 

I compared the request and reply parameters and they seem to be okay.  Wireshark doesn't complain about either packet.  I'm trying to assign IP address 10.0.0.1 to the Tiva, but I've also tried to assign an IP address in the same subnet with the same disappointing result; the Tiva never adopts the given IP address.

I looked at the source code for TI's boot loader and I see that it expects to receive a BOOTP reply with the same transaction ID and MAC address as contained in the request packet.  These are the same in my response, as you can see above.  Of course there might not be any correlation between the boot loader source code and the ROM_UpdateEMAC function; I don't know.

I'm wondering whether the ROM function really does have to be called when the lwIP stack is in use, for some reason.  As I mentioned earlier, we're using NDK.

-- Mike

Hello Mike,

The Magic Packet has a call back function that should be used to invoke the ROM_UpdateEMAC. This is a part of the Flash Based EMAC Boot Loader example on the DK-TM4C129. That ways when a magic packet is recieved by TIVA it knows that a Firmware update has to be done

Regards

Amit

After considerable head scratching, I abandoned my attempt to use the ROM-based update function.

AFAIK the ROM code is not publically documented, and I could not find any source corresponding to it, so I could only try to use it by sending various packets back to the Tiva and observing the result with a network analyzer.

I tried using the LMFlash utility. Originally that would not run because my Windows 7 firewall was blocking it, but I told Windows that it could use the BOOTP and TFTP ports.  Then it would run, but would just hang.

Finally I just gave up and wrote my own bootstrap loader for the Tiva and used a bash script running under Linux to send the new firmware image to the board.  This is working fine.