• State Resolved
  • Locked Locked
  • Replies 19 replies
  • Subscribers 32 subscribers
  • Views 2033 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problems with using ROM Ethernet bootloader

Jeff McDevitt
Expert 1775 points

Other Parts Discussed in Thread: TM4C129XNCZAD, TM4C1294NCPDT, EK-TM4C1294XL

After overcoming several hurdles, I am able to update my custom board using the ROM Ethernet bootloader via LMFlash. If I start with a blank part (erased using LM Flash and the JTAG interface) then the part reboots after the update is done (I have an LED test early in the code). If I try to update the part with the code already programmed the part is not reset after the update. If i go back to the JTAG interface I can verify the flash against the file.

I am using a tm4c129xnczad production part.

Any suggestions?

 

Thanks,

Jeff

  • 0
    TI__Guru**** 244450 points
    Hello Jeff

    The use of the ROM Ethernet Boot Loader on a flashed part requires the use of BOOTCFG register setting. Is that being done?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1775 points
    Amit,

    Since I have no idea as to what you are talking about I am going to say no. :~) Can you point me to a doc that defines what I need to do?

    Thanks
  • 0 in reply to Jeff McDevitt
    TI__Guru**** 244450 points
    Hello Jeff,

    In the data sheet for TM4C129XNCZAD, Page 707, Register 68. This pin is required to be configured to be able to detect a Pin Level as indicator of going back to ROM Boot Loader when the part is reset.

    This register must be committed (not just written) the process for which is also specified in the Register Section for BOOTCFG.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1775 points
    Wow - that is quite involved. I am porting from a Stellaris design which I am able to update without doing anything with the BOOTCFG register. It appears that I got lucky with the default IO pin.

    Thanks for the quick replies.
  • 0 in reply to Jeff McDevitt
    Expert 1775 points

    Amit - I have been thinking more about this and have a few more questions.

    1) has the overall Tiva bootloader implementation changed significantly from the Stellaris parts?
    2) What happens at the end of the ROM_UpdateEMAC code? Is a software reset done?

    Here is what I do on Stellaris micros that works great:

    Initial program load is done by Contract Mfg. This program has code to call ROM_UpdateEMAC upon receiving a specific command.
    I have a Windows test program that I can run any time to initiate an update via a command sent over the Ethernet.
    The device is updated and somehow reboots (done by the ROM_UpdateEMAC code?) and executes the new code.
    I have not touched the BOOTCFG register at any time.

    This same process does not work for the Tiva part - it does not reboot at the end of the update. I guess it would be more accurate to say that my code does not execute after the update.

    What am I missing?

    Thanks,
    Jeff

  • 0 in reply to Jeff McDevitt
    TI__Guru**** 244450 points
    Hello Jeff,

    1. Yes. the boot loader has changed a lot from the Stellaris part. While the boot protocol still remains the same, there are other checks that have been added.
    2. The ROM now evaluates the requirement for the Emac Boot Loader based on the BOOTCFG

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1775 points

    Amit,

    I am still struggling with this. It seems that if I use the default values for BOOTCFG (in other words I don't even attempt to read or modify the value) then after programming, whether it be a blank or previously programmed part, there should be a non 0xFFFF:FFFF value at flash address 0x0000.0004 and the part should boot from flash. I am seeing this behavior only if the part is previously blank. I am not sure what is happening after I program a previously programmed part - all I know is that my code is not executing. My code does, however, execute after power-cycling or using RST.

    What am I missing?

    Thanks,

    Jeff

  • 0 in reply to Jeff McDevitt
    TI__Guru**** 244450 points

    Hello Jeff,

    Without the BOOTCFG registers programmed, the flash image will execute only when the Flash is all 0xFFFF.FFFF. On the next RST or Power Cycle, the code will execute w/o ROM Boot Loaders being invoked.

    When the BOOTCFG is configured to monitor a Pad-Pin, the ROM will evaluate the condition on a RST or Power Cycle and if true will execute the Flash Erase when a new image is received. Else if evaluated as false, it will execute the last image at 0x0.

    This is completely inline with what you are seeing, unless I am misinterpreting it.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Expert 1775 points

    Amit,

    You said "Without the BOOTCFG registers programmed, the flash image will execute only when the Flash is all 0xFFFF.FFFF".

    If the flash image is all FFFFs, then it is blank and there is no code to execute.  My understanding, based on page 234 of the June 18, 2014 version of the SPMS444B data sheet, is that if flash address 0x0000.0004 is NOT 0xFFFF.FFFF (indicating that it is not blank) then code will execute from FLASH.

    I am not changing the BOOTCFG register so the default behavior (based on page 707) is what i mentioned above.

    What happens at the end of the ROM_UpdateEMAC function? Is the flash address of 0x0000.0004 re-read? Or is a reset done using the previous value of flash address 0x0000.0004. What I am seeing leads me to believe that at the end of ROM_UpdateEMAC a reset of sorts is done but it is using the old value of flash register 0x0000.0004 instead of re-reading it.

    Thanks,

    Jeff

  • 0 in reply to Amit Ashara
    Guru 56418 points

    Dear Amit,
    Some time ago you stated the TM4C1294NCPDT shipped with experimental Rev1 silicon chips on EK-TM4C1294XL Launch pad would be replaced by TI when released.
     Mouser has made no effort to do any such thing. Memory recalls CCS5.4 was jumping to flash address 0xffff.fffe upon a reset entering JATG debug when flash is programmed with a Tivaware Boot Loader 0x0000.0000, BOOTCFG register set accordingly. Worst of all PWM0 Gen0 interrupt errata still plague the experimental Rev1 chips. We did a work around for testing but PWM centering is effected due to Gen0 interrupt errata.

    Please advise what is to be done with this TM4C broken launch pad with an experimental chip?

    Looking over the old thread it appears we were writing the Tiva BL to start address 0x0000,0000 just as it was in Stellarisware. Seem to recall trying to also specify an offset 0x0000.0004 as the Tiva BL start address but with no success. Has been very long time ago so will try this again in AM.

    Old thread:http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/336995

    Amit many thanks!

  • 0 in reply to Jeff McDevitt
    TI__Guru**** 244450 points
    Hello Jeff,

    Apologies. Yes you are right. It will execute the Flash Image only if the address is "NOT" 0xFFFF.FFFF. After the end of the ROM_UpdateEMAC, a reset is done which must cause the ROM to re-read the new value of the Flash Image at 0x0000.0004

    If that is not the case then it needs to be checked by us as to why the new image is not getting executed, which however in your case does get executed only and only if a Reset or Power Cycle is done. Alternatively, if the RESET command is not issued by the BOOTP server, then the same effect will be seen.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1775 points

    Amit,

    Do you have a way to test this? Or can I use the debugger to see why my new code is not being executed? I use CCS 6.X.

    Thanks,

    Jeff

  • 0 in reply to Jeff McDevitt
    TI__Guru**** 244450 points
    Hello Jeff,

    You can use the debugger but please make sure that the Debugger is already connected and device is in run state before the Application is downloaded. Once the download is complete you can take a snapshot of the CPU registers. That will help us in figuring what is the state of the CPU.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1775 points

    Amit,

    The code is ending up in the FaultISR( )  handler.

    Jeff

  • 0 in reply to Jeff McDevitt
    TI__Guru**** 244450 points
    Hello Jeff,

    Looking at the CPU registers it seems (could you check the FAULTSTAT and FAULTADDR registers in NVIC) that the fault is for the Address 0x40067000 which is GPIO Port R.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1775 points

    Amit,

    Here are the FAULTSTAT and FAULTADDR registers.

    Jeff

  • 0 in reply to Jeff McDevitt
    TI__Guru**** 244450 points
    Hello Jeff,

    IMPRECISE Bus faults are a little difficult to debug. There is an application note for CM3 which was written and does help in the debug as it requires the dissasmebly to the faulty STR opcode.

    http://www.ti.com/lit/pdf/spma043

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 1775 points
    Amit,

    I was able to determine that I had a race condition in my code. I am using Timer0 to blink an LED and I was enabling the timer before enabling the port for the LED. For some reason it only failed after updating the code using ROM_UpdateEMAC. It was a long road to get there but the problem is solved.

    Thanks for all of the help!

    Jeff
  • 0 in reply to Jeff McDevitt
    TI__Guru**** 244450 points
    Hello Jeff,

    Might you want to give a "Verified Answer" to yourself since you did most of the work...

    Regards
    Amit