• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 31 subscribers
  • Views 3334 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.

TM4C129XNCZAD: Ethernet Bootloader Stuck in PacketTransmit

Robert Preissl
Prodigy 90 points
Part Number: TM4C129XNCZAD


Hello!

For a custom TM4C129XNCZAD board I have implemented a (flash based) ethernet bootloader.

Things work out fine for most of the time and I can program a new binary just fine. This process works out around 4 or 5 times in a row and then when trying again the "emac flash" bootloader is stuck and no new binary can be transferred. From debugging and looking at the server I think the bootloader is stuck in some very early stage and does not even send a BOOTP_Request.

I then need to power cycle the device and then bootloading works fine again.

some details:

when debugging in Code Composer I can see that the bootloader is stuck in bl_emac.c in a function called "PacketTransmit". in more detail, it is stuck in this while loop

    while(g_psTxDescriptor[g_ui32TxDescIndex].ui32CtrlStatus & DES0_TX_CTRL_OWN) {}

 

The status on the server side (the side sending the magic packet) is that it never got a BOOTP_Request from the tiva since it tries to keep sending the magic packet.

 

Any help on how to debug / fix this issue would be great since power cycling is not an easy option.

 

Thanks,

Robert

  • 0
    TI__Guru**** 191906 points
    Hi Robert,

    Is this the same flash based ethernet bootloader example from TivaWare libary or is your own or modified from TivaWare?

    It seems like the EMAC is still owning the TX descriptor which means the packet transmission is not complete yet. Sorry, I'm not an expert in Ethernet. This is how much I can see so far.
  • 0 in reply to Charles Tsai
    Prodigy 90 points
    Hello Charles,

    Yes, it is the bootloader from the TivaWare library.

    Robert
  • 0 in reply to Robert Preissl
    Prodigy 90 points
    Hello,

    Not sure if this will help, but the value of

    g_psTxDescriptor[g_ui32TxDescIndex].ui32CtrlStatus

    is F0D00000. (where g_ui32TxDescIndex is 0)

    Appreciate any help.

    Thank you.

    Robert
  • 0 in reply to Robert Preissl
    Guru 55923 points
    Hi Robert,

    Curious is your PC and launch pad connected to local switch on your desk?

    Noticed same issue in past with Linksys switch ports extending the collision domain might at times block a broadcast between switch ports, hub ports can not block. That is one reason for corporate upgrades from hubs to switches in effort to stop broadcast storms on the network from a bad Ethernet or embedded virus on PC attempting a DOS network attack.
  • 0 in reply to Genatco
    TI__Guru**** 191906 points
    Thanks BP101 for providing hints. I will also suggest to run the identical code on the launchpad and see if such failure can be reproduced in the same network.
  • 0 in reply to Charles Tsai
    Guru 55923 points

    Funny thing right after my comment had the very same thought but for reason custom PCB Ethernet differential pair layout is somewhat critical. Recommend for TM4c129x transformer TCT/RCT center tap decoupling caps 0.1uf or greater depending on plane or trace connection (1uf or greater), seemingly relative to +3v3 pull up noise level. SPMA056–October 2013

  • 0 in reply to Genatco
    Prodigy 90 points

    Hello BP101,

    No switch or hub connected between my PC and the Tiva. I have the Tiva launchpad directly connected to my computer.

    Robert

  • 0 in reply to Robert Preissl
    Prodigy 90 points
    Is there any way (in a situation where I am stuck too long) to free up ownership of the TX descriptor? and free all necessary buffers / descriptors?
  • 0 in reply to Robert Preissl
    Guru 55923 points

    Robert Preissl said:
    I have the Tiva launchpad directly connected to my computer.

    More specifically with a crossover cable as straight through cable will not work. Recall had grown the very same issue you report of TX descriptor OWN bit hang. Boot loader client was past working with a cross over cable and while(1) loop with a interrupt call ( (*((void (*)(void))(*(uint32_t *)0x2c)))(); After removing while loop test and directly invoking the function it stared to hang on the OWN bit for what ever reason.

  • 0 in reply to Genatco
    Prodigy 90 points
    FYI, I have a hacky (and of course not super satisfying) solution to this: If I am stuck for more than 10 seconds in that PacketTransmit while loop, I call EnetReconfig.
    This seems to be working so far fine. I can only hope that I will not get stuck during the TFTP phase.
  • 0 in reply to Robert Preissl
    Guru 55923 points

    It must be something to do with the velocity of execution timing after NVIC  commands and invoking the BootP semaphore since it never hung when app punched into semaphore handler. The other thing is application loop is disabling NVIC interrupts just prior to entering INT 0x2c like below but without the while(1) loop Boolean switch being set when the OWM bit hangs in TXD.

    //
// Disable all processor interrupts.  Instead of disabling them
// one at a time (and possibly missing an interrupt if new sources
// are added), a direct write to NVIC is done to disable all
// peripheral interrupts.
//
   HWREG(NVIC_DIS0) = 0xffffffff;
   HWREG(NVIC_DIS1) = 0xffffffff;

//
// Clear any active interrupts.  If the boot loader uses
// any interrupts, they will therefore respond as expected.
//
   HWREG(NVIC_APINT) = (NVIC_APINT_VECTKEY |
                     NVIC_APINT_VECT_CLR_ACT);

//
// Return control to the boot loader.  This is a call to the SVC
// handler in the boot loader.
//
   (*((void (*)(void))(*(uint32_t *)0x2c)))(); //0x2c